Pattern Gaps

[Bug Importer]

When filling with patterns, gaps appear. When you drag the
size of a box, say, with a pattern in it, the gap will move as
well... it can be a horizontal or vertical gap. See the
attachment for how this looks.

[Buliabyak-users (buliabyak-users)]

Now, thanks to Fred's new rendering code, there are no gaps
at normal zoom levels, but there are larger gaps at high
zooms. Still this is an improvement over what we had before.

[Buliabyak-users (buliabyak-users)]

More examples are in the duplicate bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1100365&group_id=93438&atid=604306

[Corydodt-users (corydodt-users)]

Still seeing this one. Is there any plan to fix it? Is it
waiting for something or someone? Would a failing test
help? What can be done to help and to speed this along.

[Mental-users (mental-users)]

This is basically an issue of rounding error in the pattern
rendering code. Occasionally it's advancing one too many
pixels between tiles.

[Lucychili-users (lucychili-users)]

Duplicates

980785 Pattern Gaps
1481545 Renderer: Scaling Pattern - Breaks Appear

Not the same bug but also on patterns:
981044 undoing pattern knot drags does not update knots
1208874 pattern fills do not export to ps or eps
1238314 Clones in patterns behave badly - now spiral shapes only
1246362 clones in patterns not updated when original edited
1325279 compositing bug of pattern with semitransparent bitmap
1467137 Shrinking a pattern causes lock-up
1487555 Incomplete pattern coverage with overflowing pattern

[Marc Carson (baggageclaim)]

Originator: NO

Just wanted to chime in and say this is a desired bugfix.

[Luciash (luciash)]

Originator: NO

unfortunatelly the bug still appears when rotating the pattern in 0.45 :(
see http://www.imagefilez.com/out.php/i104474_sshot73.png

[Jpatokal (jpatokal)]

Originator: NO

I'm getting this too (0.45.1) and it basically makes patterns completely
useless, as the gaps are painfully visible in exported bitmaps as well if
the background is non-white. See new attachments:
pattern-fill-bug.{svg,png}. This has been open for three years now, are
there any workarounds?

[Jpatokal (jpatokal)]

Originator: NO

Oops, looks like I can't add attachments? Try these then:

http://contentshare.sg/inkscape/pattern-fill-bug.png
http://contentshare.sg/inkscape/pattern-fill-bug.svg

[Amphi-users (amphi-users)]

Originator: NO

>This has been open for three years now, are there any workarounds?

You can try Batik. It's the most accurate renderer I know.

[Marc Carson (baggageclaim)]

Originator: NO

>You can try Batik. It's the most accurate renderer I know.

What does that mean? How can we try Batik - is there some sort of Inkscape
plugin, or what?

[Amphi-users (amphi-users)]

Originator: NO

>What does that mean? How can we try Batik - is there some sort of
Inkscape
>plugin, or what?

Batik is an Apache project:
http://xmlgraphics.apache.org/batik/

It's a sorta massive (and very feature complete) SVG rendering lib written
in Java. It also comes with a small demo application, which can
render/export stuff.

There is no Inkscape plugin yet, but it's already on my todo list.

[kolala (howk-tomo)]

What I usally do as a workarround is.

Fill the object or text with the desired pattern.
set a custom background of the obj. or tekst by duplicating it and moving it to the back of the tekst.
note. background can also be a part of the previous created pattern.

However this approach make take some time if the patterns get more complex.

[Mark Duncan (eattheapple)]

Ubuntu 8.10: bug still exists.

[lcarls (luizcarlos-campos)]

Hello,

I started using Inkscape recently, it has been a quite useful tool.

But this bug is shameful. Really, how can it be sitting there for 3 years?! Inkscape has a huge importance for a number of projects around the world, so it seems to me that the developers' priorities can only be twisted when a bug as relevant as this just dusts there. It makes something as basic as patterns utterly useless!

I'm using 0.46, the bug is completely noticeable at normal zoom levels, so the 2004 comment up there doesn't make much sense, it's an in-your-face bug.

Please, move the Importance setting in this bug from Medium to High. (Yesterday)

Thanks

[lcarls (luizcarlos-campos)]

PS: I stand corrected, can it be truth that this bug is really 4 1/2 years old? Duplicate #169118 just turned 1 year old. The 2006 duplicate #1539029 seems to have been deleted.

[Yann Papouin (yann-papouin)]

As it affect both canvas and PNG rendering I'm posting here a svg file and png references + canvas snapshot

[Yann Papouin (yann-papouin)]

1:1 pattern

[Yann Papouin (yann-papouin)]

resized pattern png rendering

[Yann Papouin (yann-papouin)]

Snapshot

[Kjohrf (kjohrf)]

Sigh. Just found this bug, too. Wish some of these basic but terribly annoying bugs could be fixed before so many mre new features are added to Inkscape.

[Antonio Roberts (hellocatfood)]

Affects me too

[Diederik van Lierop (mail-diedenrezi)]

Workaround:

1) dimension the objects which are to become a pattern in integer multiples of pixels
2) align them to a grid with 1x1 pixel spacing
-> now anti-aliasing has been avoided, next:
3) do not rotate the pattern.

I'm not sure if this is easily explained by calling this rounding bugs, it might be more complicated than that and simply inherent to the way things are currently handled by the renderer. I had a look at the relevant part of the source code (sp_pat_fill and sp_pattern_painter_new), but it's quite difficult to grasp what's going on. If I'm correct then the pattern is simply stamped over the object to be filled until the full area has been covered. So while steps 1) and 2) will work for orthogonal patterns, this will never get a perfect fill when rotating. Rounding errors are inevitable and cannot be avoided. We could only fight the symptoms by doing some clever interpolation/filtering/antialiasing or whatever. Or we should increase the pattern half a pixel in size or reduce the pattern pitch by half a pixel, but this would be foul play.

What might help in 3) is if we'd first create a temporary bitmap of e.g. a 3x3 orthogonal pattern (invisible to the user), rotate and transform that bitmap, and then cut a small rectangle (with the size of the original pattern) out of that rotated bitmap and use that small rectangle for stamping.

But IMHO that would be quite a challenge when looking at the state of the source code :-(

[Kjohrf (kjohrf)]

Thanks. So now I have a pattern that is exactly 8 pixels by 8 pixels (default resolution set to 300 dpi, if that matters).
First I repeatedly hit 168014, so it makes it hard to use anyway. But when I can see the pattern, it still has gaps!

[Nathaniel Gray (n8gray-n8gray)]

What Diederik said, but I think you'll need more than 3x3 in general. You need to be able to fill the bounding box of the original pattern rectangle transformed to the new coordinate system. If you imagine a pattern that's 1000px wide and 10px high rotated 45 degrees you'll see that a 3x3 tiling won't work. But it's just basic trig to figure out how big of a box you need.

OTOH, since you know you're tiling the plane can't you just turn off anti-aliasing of the pattern's edges and do what you're doing now?

[David Eccles (gringer) (gringer)]

Just from what people are saying here, I would guess that this problem occurs because a stamping approach is used, rather than a modulus approach -- the pattern is not being treated as something that stretches in all directions to infinity, wrapping around itself.

Here's what probably should happen:

define image(x, y) as the current image location
define pattern(x, y) as the 'pattern coordinate location', pattern(0,0) corresponds to the position at the origin of the pattern (top left, or whatever)
define patternStartX() as the X image coordinate of the pattern origin
define patternWidth() as the width (X) of the pattern
define patternStartY() as the Y image coordinate of the pattern origin
define patternHeight() as the height (Y) of the pattern
define mod(x, y) as the [positive] remainder of x divided by y

image(x,y) = pattern(mod(x - patternStartX(), patternWidth), mod(y - patternStartY(), patternHeight);

Adjustments for scale / rotation would need to be made as well, but I would expect that Inkscape can do that in its sleep.

[David Eccles (gringer) (gringer)]

I noticed that reducing the pattern width and height in Inkscape removed this problem, so had a hunt through 'sp-pattern.cpp' to see what I could change slightly to produce the same effect.

[David Eccles (gringer) (gringer)]

Although that patch seems to solve the problem (in my particular test case), it introduces another issue regarding pattern scaling and positioning. A seamless pattern, as can be created in GIMP by 'filters->map->make seamless', will have a noticeable seam (see attached SVG, where the seam is through the middle of the image). So this fix is just replacing one seam bug (i.e. pattern is too small to fit in pattern block) for another (pattern is too large to fit in pattern block).

Somehow, there needs to be a seamless lookup for displaying the pattern, I've suggested something that may work above, but I'm not quite sure at the moment how to implement that in code.

[Allan Shand (ashand79)]

just found this error when trying to add a carbon fibre pattern.

As far as I can see this problem only happens when the pattern is smaller than the shape that it is being added to. For any newbies like my self a possible workaround in the mean time is to create an image in the gimp or whatever raster graphics program you are using that is bigger than the shape you would like to fill and use the pattern as a gimp pattern and make a patterned "wallpaper" save import in to Inkscape, object to pattern and fill your final object.

I haven't tried this my self yet but it sounds logical. Obviously this could become tedious after a while so I hope this bug is solved soon.

I still think that Inkscape is one of the best free programs I have seen and I thank Heathenx for showing me the Immense creative power that can be unleashed by learning to use 10% of the program.

[Alex S (schmitt-happens)]

cowboy's solution is quite similar to the one here:

http://tucson-labs.com/articles/patterns-with-inkscape/

So in short, there is a workaround but it is pretty tedious and annoying. I think this would be a great feature to have for all sorts of things (I was trying to use it to make fill patterns for geological cross sections, "bricks" for carbonate etc), and I hope this bug is fixed sooner rather than later...
Another annoying thing is that as far as I can see you have to "object to pattern" every time you start a new file. Surely it wouldn't be too difficult to allow the user to "save" custom patterns for use in different files?

[Luca (kovenant)]

It's incredible that after SIX YEARS this bug still exist.

It is also documented in this tutorial :
http://tucson-labs.com/articles/patterns-with-inkscape/

Why it took so much time to fix it?
I'm thinking about switching to illustrator.

Inkscape is a great program, but bug fixes take eons....

[Yann Papouin (yann-papouin)]

@Luca
If you read previous comment, you will see that this bug cannot be fixed easily.
But before spending 860€ for Adobe Illustrator maybe you can fund an Inkscape developper to fix it? It would be more constructive for everyone.

[David Eccles (gringer) (gringer)]

The situation I mentioned previously regarding a modulus simplifies matters too much, because some patterns can extend beyond the bounds of the pattern source (e.g. see bug 167503).

Consider the attached document, where the circle is about 80x80, but the pattern is defined with a size of 30x30. In this case, one copy of the circle will creep into two adjacent pattern start boundaries to the right, and two adjacent start boundaries below, which means it's more difficult to work out what a single result image pixel will look like. I'm starting to see why stamping the image multiple times is necessary.

[Pedro Gauna (lapega)]

The bug repeats in version 0.48.0 r9654, hope someone can fix it...

[bezeek (bezeek)]

Also seeing this problem in 0.48.0 r9654 when editing a hand-written SVG. Patterns reproduce faithfully in browsers, but are littered with narrow gaps in Inkscape. Filling the pattern past its boundaries solves the problem, but is not desirable and can cause ill effects when viewed with other software.

[irongamer (irongamernet)]

Keep running into this pattern problem. It affects png output and bitmap printing. Using Inkscape 0.48.0 r9654

Seems to be a tricky bug.

Screen of bug
http://www.screencast.com/users/irongamer/folders/Jing/media/4e1b121f-75e7-43db-b857-9e9784ff3f3c

[Triadore (marcelocrt)]

This error is very important and annoying. Using Inkscape 0.48.0 r9654

[ScislaC (scislac)]

This was in fact fixed in trunk just yesterday from my testing (our renderer was switched out).

[pRototype (regeir)]

Inkscape 0.48+devel r10300
OS: XP sp2

ScislaC, that fix is not comitted as I can see.
If I import any raster image file and make it to pattern, any objects filled with that pattern will still have pattern gaps.

I post a sample file showing that.

[su_v (suv-lp)]

@pRototype - the fix is in r10326 (not yet available as win32 snapshot build)

[ScislaC (scislac)]

r10341 here and it's fixed with your example pRototype

[pRototype (regeir)]

Can't find newer version on modevia.com

Is it located elsewhere?

[ScislaC (scislac)]

pRototype: I've sent out a mail to see if someone can fix the modevia builds, hopefully one should be available within the next few days.

[Šimánek (jasonsimanek)]

Has this fix been in a officially released version of Inkscape yet? I'm running Inkscape 0.48.3.1 r9886 and the bug is still present.

[su_v (suv-lp)]

Šimánek wrote
> Has this fix been in a officially released version of Inkscape yet?

No.

Note: The bug report contains all necessary details (at the top of the page) to keep yourself informed:
- Bug status: Fix Committed (i.e. not yet released)
- Milestone: 0.49 (i.e. not in 0.48.3.1)

[PomCompot (pomme-compote-launchpad)]

This bug seems corrected, available on the trunk and promised for a 0.49 version (or 0.91 with the new version scheme), but since 2012, there's still no trace of such a version downloadable in a binary format. Latest version available, 0.48.4, is dated december 2012. Did we have any clue on when this bugfix will be available and when the next major version will come?

Just for information, SVG rendering in Firefox doesn't seem affected by this problem.