Incomplete pattern coverage with overflowing pattern

[Martin von Gagern]

This is not bug 980785 about pattern gaps.

I have a pattern formed from irregularly shaped objects
that cover more than one pattern cell. As I wanted to
avoid any issues with gaps, I simply included the whole
stroke and set overflow="visible" in my svg code. I
could reproduce the problem with some simpler example
than where I originally encountered the issue.

However, Inkskape 0.43 seems to be doing something
wrong. The pattern does not look completely regular,
there are some places uncovered that should be covered
by part of the pattern.

To me it looks like the repitition of the pattern stops
somewhat early. The missing parts most likely would
have been covered by a copy of the theme that had its
cell (as defined by width and height) outside the
object that is to be filled.

Looking at the spec, overflow="visible" is explicitely
mentioned, and it is also said that a pattern should be
handled as an infinite tiling of the plane. Therefore
as far as I understand things, no program should make
any assumptions about the bounding box of the pattern
content, but instead calculate this bounding box and
use this value to determine what copies of the theme
are needed.

Looking at other apps. My firefox completely seems to
completely ignore the overflow="visible" setting.
svgdisplay from kde displays the pattern correctly.

[Martin von Gagern (gagern)]

I created and attached a screenshot with different
applications showing the attached testcase.

In the top left is svgdisplay from KDE. The rendering looks
correct, that is how I would expect it to look.
In the bottom right is mozilla firefox, the rendering there
completely broken, as overflow="visible" is not honored.

The other two windows are inkscape 0.43. The top right
version is the original window, where several redraws have
already occured due to partial obscured window. The window
in the bottom left corner is a new window opened just before
the screenshot was taken. So this is how the thing looks
immediately after opening the file.

[Rwst (rwst)]

cannot reproduce with svn. I get an empty rectangle with
blue stroke. does someone have an explanation?

[Molumen (molumen)]

RSWT, Confirmed here: 0.44devel on winxp gives the same
result as you described, an empty rectangle with blue
border. By the way, firefix 1.5.3 shows it the same way.

In 0.43-2 (final Windows) the behaviour of the pattern is
quite strange, it seems to weirdly interact with the page's
border.

Also, the W3C valisator finds one error in the file (http://
jiggles.w3.org/svgvalidator/)

[Martin von Gagern (gagern)]

Those with different but still incorrect results, could you
attach screenshots of what things look like for you?

Interaction with the page border might be because there the
cell assigned to the pattern (where it would have been
clipped if overflow was not set to visible) already is
outside the pattern filled rectangle, while some part of the
pattern theme would still be inside. That fits my proposed
explanation above even better than the results I get.

When first I encountered this bug, it was with some much
more complex pattern, and usually happened mainly near the
border. I was a bit surprised myself that the errors with
the simple testcase seem to cover most of the area.

The validation error was due to the fact that the validator
only speaks SVG 1.0, but my file was SVG 1.1. I changed that
since I don't really use any 1.1 features, now the sample
validates just fine. Which is not saying much, I fear.

[nightrow (jb-benoit)]

Thank you for taking the time to report this bug and helping to make Inkscape better. You reported this bug a long while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Inkscape release? Thanks in advance.

[Martin von Gagern (gagern)]

The original testcases are affected by bug 168024 which makes them difficult to use. The first testcase seems to be missing here in this bug database altogether.
I rewrote the testcase to not use viewBox, and gave it a try in inkscape 0.45.1. Things seem to be a bit more robust, the file opens all right. However when I resize the window, I still get white areas where none should be from time to time. Open the attached testcase and try for yourself.

[Martin von Gagern (gagern)]

This screenshot of inkscape 0.45.1 demonstrates the bug is still an issue. This was after I enlarged the window vertically.
You will notice that in the row of white triangles, one triangle is correctly filled. This one was hidden by another window and got redrawn independently.

[John Cliff (johncliff)]

Confirmed that the test case still misbehaves in SVN. Renders a rectangle containing a pattern with Red diamonds seperated by blue lines on load, if you move it about tho white areas appear in the diamonds.

[su_v (suv-lp)]

partly reproduced with Inkscape 0.46+devel r22575 on OS X 10.5.8

both files 'overflow10.svg' and 'overflow_v2b.svg' are displayed more or less correctly in Inkscape (some issues with the renderer omitting a few partial fillings, depending on zoom levels and redrawn after scrolling) and are exported to bitmap without any flaws. Exporting as Cairo PNG however is broken and looks like the still broken rendering in Firefox 3.5.5.

[su_v (suv-lp)]

correction: I overlooked the omission of the clipped red fills (top row) in the bitmap export.

[ScislaC (scislac)]

Cannot reproduce with Inkscape trunk (still reproduced with 0.48.x). Closing this report, if you feel this was closed in error, please re-open the report and explain why.