Imported pattern fill disappers while transforming (regression)

[dopelover]

I have started to work with pattern fills recently and experienced some strange and annoying beahaviour during transforming objects filled with one pattern. In an attached file there is a rectangle filled with a pattern. Try to transform it and see what happens. It dissappears and isnt redrawn after zoomming in or out. This problem occures only with Crosses_1 pattern. This pattern is imported from Adobe Illustrator (svg comes from AI).

The problem is a regression. Inkscape 0.48.2.1 isn't affected by this problem.

I use Inkscape 0.48+devel r11077 on Windows XP

[su_v (suv-lp)]

On Mac OS X 10.5.8 (32bit) and OS X 10.7.2 (64bit):
- Not reproduced with Inkscape 0.48.2 and 0.48.3.1
- Not reproduced with Inkscape 0.48+devel r10325 (last revision with old renderer)
- Reproduced with trunk on both systems, with cairo 1.10.2 as well as cairo 1.11.2 and cairo master:
Inkscape 0.48+devel r10330 (as well as the latest revision of the original cairo-rendering branch) doesn't render the pattern fill at all
Inkscape 0.48+devel r11077 initially renders the pattern fill, but as reported it disappears after transforming the pattern-filled object (e.g. scaling it with the select tool).

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 11649.

The imported pattern is not in the defs section. When the pattern is applied to the rectangle for the first time, the rectangle fill is linked to the pattern directly. Then when you move the rectangle, Inkscape creates an extra pattern linked to the crosses, and the rectangle fill is linked to the new pattern (that's how patterns created in Inkscape work). But unfortunately, the intermediate pattern doesn't seem to find the crosses.

Workaround: select the group imported from AI (your pattern shape) and convert it to pattern with Alt+I. The imported pattern is then correctly located in the defs and can be used as the stock patterns.

[Diederik van Lierop (mail-diedenrezi)]

JazzyNico's analysis is correct; the pattern is not in the defs, which is unusual; I'll have a look at the SVG specs to see if this is allowed; if it is then Inkscape should handle such a file properly, if it isn't then the file should be imported properly.

But I wonder, who put the pattern outside the defs? Was it Inkscape itself when importing, or was it AI? Do you have the original AI file? The file that has been attached has been saved by Inkscape.

[Diederik van Lierop (mail-diedenrezi)]

Apparently it's merely recommended to store patterns in the defs section, see www.w3.org/TR/SVG11/struct.html#Head. So it looks like the attached SVG file is valid, and that Inkscape should be able to handle this...

[Diederik van Lierop (mail-diedenrezi)]

I've added a simplified file, showing the same behaviour; might be easier to debug

Looks like something wierd is going on; the svg looks perfectly valid, but once a transformation is applied the pattern disappears

[Diederik van Lierop (mail-diedenrezi)]

I've been able to pin-point the bug, now we only need a solution ;-)

The imported pattern has a view box, whereas the stock pattern hasn't. As soon as the object with the pattern is moved, an extra pattern is inserted into the chain of references, in order to handle the transformation. So far so good. In sp-pattern though, the viewbox is being calculated, and this breaks as soon as the extra pattern is added. The relevant code is in sp-pattern.cpp

// viewBox to pattern server
    Geom::Affine vb2ps = Geom::identity();
    if (pat->viewBox_set) {
        Geom::Rect vb = *pattern_viewBox(pat);
        gdouble tmp_x = pattern_width (pat) / vb.width();
        gdouble tmp_y = pattern_height (pat) / vb.height();

        // FIXME: preserveAspectRatio must be taken into account here too!
        vb2ps = Geom::Affine(tmp_x, 0.0, 0.0, tmp_y, pattern_x(pat) - vb.left() * tmp_x, pattern_y(pat) - vb.top() * tmp_y);
    }

When I force the vb2ps variable to keep it's initial value, i.e. the value before the transformation of the object, then the pattern remains visible, even after translating the object. When I allow the code above to execute normally though, the pattern disappears after the transformation!

[Diederik van Lierop (mail-diedenrezi)]

This bug might have been fixed as of rev. 12519. I'm not completely sure if this fix is ideal though, see the copy below of my post to the developers mailing list:

Hi devs,

I might just have fixed this blocker bug: https://bugs.launchpad.net/inkscape/+bug/953992; well at least the problem cannot be reproduced and I haven't noticed any new regressions, but I am not sure if this fix is correct. Let me try to explain:

When a pattern is imported, e.g. from Adobe Illustrator, then it might have a view box set. This is just fine, as this viewbox is accounted for by Inkscape. Now when an object that uses this pattern is moved, a new pattern is introduced to account for the translation. So we now have:
     object -> mother pattern (with transform) -> child pattern (as imported)

The child pattern has a view box set, but the current code only considered the viewbox of the newly introduced mother pattern... which didn't have a viewbox set. This is why the pattern wasn't drawn. I've modified the code to consider the viewbox of the child pattern instead. This works for the files attached to the bug report, and doesn't seem to break anything. However, isn't this all a bit too fragile? What if both the mother pattern and child pattern have a view box set? Is there a teeny-tiny wibbly-wobbly subset of documents in which this can actually occur? ;-).

BTW, our stock patterns do not have a viewbox, and neither do patterns generated from objects. This is why this bug was only visible for imported patterns. Also, this bug was introduced when moving to the new cairo rendered in which a significant part of pattern rendering code (in sp-pattern.cpp) was modified.

Thanks,

Diederik

[su_v (suv-lp)]

Additional regression with r13111 (not reproduced with r13110):
The pattern already fails to render visibly on load (as opposed to disappearing only after transforming the pattern-filled object).

[su_v (suv-lp)]

Initial rendering of the pattern fill restored with the changes in r13120.

[ScislaC (scislac)]

The pattern still disappears on transform in 0.91.x, but it works as expected in trunk. It would be nice if it could be backported to 0.91.x, but tracking it down might be challenging with all of the changes made in experimental.

[Diederik van Lierop (mail-diedenrezi)]

I've unassigned myself because I won't have time to work on this any time soon, sorry!