Pattern fill with default stripes not rendered correctly, not exported to png

Asked by Hachmann on 2015-06-14

Hi again,

while creating a document for my next workshop, I noticed that 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 (even the hatch LPE... which surprised me).
A striped vector pattern (created by object to path) exports correctly.

I found a lot of reports about missing patterns in pdfs and eps files, but none for pngs.
Is this problem known?

And one more pattern question:
The handles for modifying a pattern are often very far away from the object (if the page is large), and seem to appear in random places outside the page.
Sometimes, they are so far away that I cannot see the object when I try to modify the pattern...
Is there a workaround for this?
I guess this is known. Is it tracked somewhere?

(Inkscape 0.91 from Ubuntu repos on LM 17.1)

Thank you,
 regards,
 Maren

Question information

Language:
English Edit question
Status:
Solved
For:
Inkscape Edit question
Assignee:
No assignee Edit question
Solved by:
su_v
Solved:
2015-06-16
Last query:
2015-06-16
Last reply:
2015-06-16
Hachmann (marenhachmann) said : #1

Small correction: The custom fill is also affected, only the zoom levels are different...

su_v (suv-lp) said : #2

On 2015-06-15 24:26 (+0200), Hachmann wrote:
> while creating a document for my next workshop, I noticed that 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.

Could you upload a test case (Inkscape SVG file) and share the link, please?

> The file shows up (and zooms) correctly in Firefox (even the hatch
> LPE... which surprised me). A striped vector pattern (created by
> object to path) exports correctly.

Why would it surprise you that path effects show up in other SVG
renderers? Inkscape stores the 'd' path data of the computed result of
the path effect in the SVG file, so for other SVG rendererd objects with
path effects look just like other (regular, static) paths. I guess that
in this paragraph "A striped vector pattern" refers to the hatch LPE
(regular patterns cannot be "converted to path").

> I found a lot of reports about missing patterns in pdfs and eps
> files, but none for pngs. Is this problem known?

Could be a regression (haven't searched yet, nor attempted to reproduce).

> And one more pattern question: The handles for modifying a pattern
> are often very far away from the object (if the page is large), and
> seem to appear in random places outside the page. Sometimes, they are
> so far away that I cannot see the object when I try to modify the
> pattern... Is there a workaround for this? I guess this is known. Is
> it tracked somewhere?

Probably reported multiple times (I didn't search yet) - at least it is
so well known that it is mentioned in the manual:

<quote>
The handles will appear on the original objects that defined the
Pattern, or the former location of those objects if they have been moved
or deleted (unless the Pattern has been previously adjusted). In the
case of built-on Patterns they will appear in the upper-left corner of
the canvas.
</quote>
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Attributes-Fill-Stroke.html#Attributes-Patterns-Adjusting

Hachmann (marenhachmann) said : #3

Hi suv,

thank you for your answer.

I've uploaded two versions of the file:
- minimal test case, with a few screenshots and one exported png at 500dpi
http://staging.inkscape.org/en/gallery/item/21/

- original file (not finished ;) ) - I experience a lot of crashes with this one... It even crashed upon document resizing, but not reproducibly... Just in case you're interested, but it's probably not helpful.
http://staging.inkscape.org/en/gallery/item/22/

That the LPE shows up in the browser did surprise me, because I didn't know ;) - but I like it. I rarely use LPEs, so I never tried it out. Thanks for the explanation.

The 'striped vector pattern' is actually an 'object to pattern' (not *path*, sorry, it's late!!!) pattern made from a green line. I did not mean the hatch LPE, although there is one in the document.

Yes, I think I moved the objects at some time during the creation of the document. But the built-in pattern's handles really do not appear at the upper left corner... at least not the current one. I've changed the document size a few times, and saved in between...
So it seems there's no workaround for my current document.

Thanks for the info, suv!

Regards,
 Maren

Best su_v (suv-lp) said : #4

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.

Could you file a bug report about this please?

Hachmann (marenhachmann) said : #5

Yep. Thank you very much for looking into this!
(I always wonder how you do all those tests for different versions so amazingly fast :) - you probably have a full zoo of automatization tools)

Hachmann (marenhachmann) said : #6

Thanks ~suv, that solved my question.