Pattern fills not rendered / exported correctly, depending on resolution/zoom

[Hachmann]

The default stripes 1:1 pattern I applied to a (circular) path does not render correctly, depending on the zoom level (at 417%, only the upper half of the object is filled, at 428% just a tiny stripe at the top has the pattern, and from 459% upwards the pattern doesn't show at all).

Second observation: png export of this object gives an empty circle without any pattern, depending on the selected resolution. At 350dpi, there's a fill pattern in the exported file, at 380dpi, I get a partially filled object, and at 400dpi, it's empty.

The file shows up (and zooms) correctly in Firefox.
A striped vector pattern (created by object to pattern) exports correctly at that resolution, but at a higher one, it also fails to show up.

(Inkscape 0.91 from Ubuntu repos on LM 17.1)

Quoting ~suv (answer to original question: https://answers.launchpad.net/inkscape/+question/268146)

"The disappearing pattern paint seems to be a regression with the new cairo-based renderer (>= r10326) - AFAICT it is directly related to the distance of the pattern handles to the object with the pattern paint: if the handles are closer to the object, one can zoom in closer with the pattern fill still rendered visible. If the handles are far away, the pattern disappears when zooming in on the shape closely."

[Alvin Penner (apenner)]

confirmed on Windows 7, 32 bit, Inkscape 0.91 r13725 (Jan 30 2015)
confirmed on Windows XP, Inkscape r14129

[Diederik van Lierop (mail-diedenrezi)]

Wouldn't this qualify as a blocker? It's annoying as ....

[ScislaC (scislac)]

Diederik: It is a blocker indeed and has been tagged as such. Confirmed w/ r14957.

[Jabiertxof (jabiertxof)]

¿Could any one attach a SVG with a example path with the problem? ¿I couldent reproduce it at this percents, maybe is related to original path size/positions?

Debian testing current trunk -need to switch to 0.92 branch...

[Hachmann (marenhachmann)]

@Jabier: There is an SVG in the attached zip file - do you mean that you couldn't reproduce with that SVG file?

[Jabiertxof (jabiertxof)]

Sorry, in a fast view, I think all are PNG.
I try it tonight.

[Shlomi Fish (shlomif-gmail)]

I've been trimming the problematic .svg from the .zip file here: https://github.com/shlomif/inkscape-lp-bug-1465753--investigation . Now I want to convert away from the matrix transformation of the problematic pattern.

[jazzynico (jazzynico)]

Partially fixed in lp:inkscape/0.92.x rev. 15074 and lp:inkscape rev. 15108.

[Tavmjong Bah (tavmjong-free)]

The problem appears to be with the Cairo library. It doesn't like large numbers in the pattern transformation matrix.

I've checked code into both 0.92.x and trunk that translates the pattern by multiples of width and height so that the translation part of the Cairo transformation matrix is smaller. This isn't a complete fix as large numbers in the scaling/rotating/skewing part could still cause problems.

Please verify that the code functions properly.

[Hachmann (marenhachmann)]

Tav, I just openend the file in the zip with current Inkscape trunk from ppa (4 Oct 2016). The pattern in the circle still isn't rendered when I zoom in to more than 197%, and the pattern in the rectangle vanishes when I zoom in to 2234%. The exported PNG image still looks the same.

Is this to be expected for the partial fix? Maybe it only works with new files? Or the numbers are too large for scaling/skewing/rotating?

[Tavmjong Bah (tavmjong-free)]

The fix should work on any file but there is a limit to what it can do. There are several problems with the test file:

1. The 'layer' group has a large transform: translate(-305.83682,1665.2239). "Ungrouping" the layer fixes the rendering. (One can select the layer group using the XML dialog.)

2. The pattern also has a large skew and transform: matrix(-1.9118163,2.0772814,-30.728658,-28.280978,4.2828915,-3290.4158). In this case, the skew seems to be causing the trouble. Dragging the square pattern handle towards the circle handle reduces the skew (without changing the rendering). To see the pattern handles, using the node tool, select the circle and zoom out to 25% or more. The handles are quite a bit above the drawing.

[Hachmann (marenhachmann)]

Okay, thanks for the explanation, Tav.

Is there a report that keeps track of the (still existing, but mitigated) problem?

[Hachmann (marenhachmann)]

(should this be reported in Cairo, then?)

[Jane's Conference (janesconference)]

This is not fixed. It still happens to me in 0.92.0 r15299.
Is there a bug that tracks the still existing problem?

[Hachmann (marenhachmann)]

@Jane's Conference: I think there isn't on yet for the remainder of the issue here. Would you like to make one?

[christophe (noscollections)]

I've got the problem on win 10 64b 0.92.1 R15371
also on win7 64b 0.92.1
export to png has the problem
How open a new issue ?

[Hachmann (marenhachmann)]

@christophe: visit https://bugs.launchpad.net/inkscape/+filebug (also link to this bug report, so developers can profit from the observations already made in this thread)

[Hachmann (marenhachmann)]

More people complaining about this issue:
https://www.inkscape-forum.de/index.php?p=/discussion/comment/50869#Comment_50869

[Hachmann (marenhachmann)]

Just setting back to 'confirmed', because we're still getting complaints about it, e.g. http://www.inkscapeforum.com/viewtopic.php?f=5&t=34730

[Hachmann (marenhachmann)]

The user was using 0.92.3 to create the file, but it doesn't display properly in 0.92.4.

[Jonathan Hofinger (jhofinger)]

Hi, this issue has been reported to GitLab, so closing it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inkscape/issues/927
Closed by: https://gitlab.com/jhofinger