After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 538841 - Images not rendering with small patterns
Images not rendering with small patterns
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
2.22.x
Other All
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-17 21:03 UTC by fibonacci.prower
Modified: 2017-12-13 17:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description fibonacci.prower 2008-06-17 21:03:33 UTC
Please describe the problem:
If a certain rsvg execution causes a pattern tile to have a (horizontal or vertical) size of less than one pixel in the rendered image, the whole image will fail to render.

Steps to reproduce:
Consider, for example, the following SVG file:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
<defs>
<pattern id="fll" patternUnits="userSpaceOnUse" width="1" height="1">
<rect width="1" height="1" fill="#f00"/>
</pattern>
</defs>
<rect width="100" height="100" fill="url(#fll)" stroke-width="20" stroke="#000"/>
<rect width="50" height="50" fill="#0f0"/>
</svg>

I would expect the filling of the first square to be indistinguishable from a solid red filling - and this is in fact what I get when I render the image at a width of 100 pixels or more (rsvg -w 100 File.svg File.png).
However, when rendering it at a width of less than a 100 pixels (note that this would require a pattern tile to have a width of less than one pixel), all I get is a fully transparent PNG file of the required size.

Actual results:
I get a transparent PNG file.

Expected results:
I would expect a PNG file containing a solid red square with a thick black border, underneath a solid green square.

Does this happen every time?
Yes.

Other information:
Comment 1 fibonacci.prower 2008-07-02 16:00:02 UTC
I have also tested the following file:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
<defs>
<pattern id="fll" patternUnits="userSpaceOnUse" width="1" height="1">
<rect width="1" height="1" fill="#f00"/>
</pattern>
</defs>
<rect width="50" height="50" fill="#0f0"/>
<rect width="100" height="100" fill="url(#fll)" stroke-width="20" stroke="#000"/>
</svg>

At a width of 100 pixels or more, only the red square is visible - which is what I expected. At a width of less than 100 pixels, only the green square is visible - while it should be obscured by the other square.
Somehow it seems to me as if rsvg stopped processing the SVG file right at the red square. However, nothing is printed to stdout or stderr, so I cannot know for sure what's wrong.
Comment 2 Eduard Braun 2014-03-23 00:43:58 UTC
Another example showing the bug when rendered below 148px width:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="740" height="225">
<defs>
  <pattern id="Pattern" x="0" y="0" width="5" height="15" patternUnits="userSpaceOnUse">
    <rect x="0" y="0" width="5" height="15" fill="#31b0ec"/>
    <line x1="0" y1="0" x2="5" y2="0" stroke="#000" stroke-width="3"/>
    <line x1="0" y1="15" x2="5" y2="15" stroke="#000" stroke-width="3"/>
  </pattern>
</defs>
<rect x="0" y="0" width="740" height="225" fill="url(#Pattern)"/>
</svg>

And example showing the bug when rendered below 501px width:

<svg xmlns="http://www.w3.org/2000/svg" height="100" width="500">
  <defs>
    <pattern id="a" width="1" patternUnits="userSpaceOnUse"
             patternTransform="rotate(-45)" height="8">
      <rect height="9" width="2" y="0" x="0" fill="#adc6f6"/>
      <path stroke="#fff" stroke-width="1px" d="m0 0h2"/>
    </pattern>
  </defs>
  <rect height="100" width="400" fill="url(#a)"/>
  <rect height="100" width="100" x="400" fill="#ff7f2a"/>
</svg>

The second example also shows that libRSVG somehow breaks when hitting the spot (the second rectangle is not drawn anymore).
Comment 3 Perhelion 2016-03-21 12:59:12 UTC
I see the bug only if I scale the images, here is probably a better example (duplicate) bug 565955#c5
Comment 4 Perhelion 2016-03-21 13:09:17 UTC
Sorry, maybe bug 565955 is nevertheless another bug. 
I can only confirm this bug if you use an viewBox:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="80" height="80" viewBox="0 0 100 100">
<defs>
<pattern id="fll" patternUnits="userSpaceOnUse" width="1" height="1">
<rect width="1" height="1" fill="#f00"/>
</pattern>
</defs>
<rect width="100%" height="100%" fill="#0f0"/>
<rect width="100" height="100" fill="url(#fll)" stroke-width="20" stroke="#000"/>
</svg>
Comment 5 Massimo 2016-03-22 12:05:22 UTC
Using a cairo_surface that has at least 1 row
and 1 column improves all the examples in this
bug report.

In practice it is possible to change these 2 lines:

https://git.gnome.org/browse/librsvg/tree/rsvg-cairo-draw.c#n226

to 

pw = MAX (1.0, patternw * bbwscale * scwscale);
ph = MAX (1.0, patternh * bbhscale * schscale);


Only cases where a 0 sized surface would be used
are affected and asking cairo to render to such a
surface is rarely producing the correct output anyway
Comment 6 GNOME Infrastructure Team 2017-12-13 17:32:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/19.