svglib

svglib copied to clipboard

i tried to convert this svg: https://github.com/eyaler/blob2svg/blob/master/test.svg to png, and got this: https://ibb.co/k2ksbm

Is the PDF rendering also similarly broken? It would be awesome to isolate and extract the wrongly-rendered polygons from the SVG.

@eyaler Don't hesitate to post a bitmap image in a ticket! I at least find sites like ibb.co a little suspicious. ;-)

Anybody have a pointer to some text about reporting issues and/or making contributions? I feel like we have too many issues recently with either confusing titles, insufficient information and/or desired outcome, or a combination of these...

I was able to reproduce with this minimal svg: <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="224" height="124"> <polygon class="#AC2F75" fill="#AC2F75" points="122,87 122,88 123,88 123,89 124,89 124,90 126,90 126,89 128,88 128,89 129,89 129,91 128,91 128,92 130,99 130,100 129,100 126,103 125,103 125,104 126,106 130,87 129,87 129,86 126,86 126,87"/> </svg>

If I remove the main_group.scale/main_group.translate ops in SvgRenderer.render, the artifact doesn't appear (but then the image is mirrored, of course). Looks like an issue in ReportLab. I can reproduce with this pure ReportLab code:

from reportlab.lib import colors
from reportlab.graphics.shapes import Drawing, Group, Polygon
from reportlab.graphics import renderPM
d = Drawing(224, 124)
points = [122.0, 87.0, 122.0, 88.0, 123.0, 88.0, 123.0, 89.0, 124.0, 89.0, 124.0, 90.0, 126.0, 90.0, 126.0, 89.0, 128.0, 88.0, 128.0, 89.0, 129.0, 89.0, 129.0, 91.0, 128.0, 91.0, 128.0, 92.0, 130.0, 99.0, 130.0, 100.0, 129.0, 100.0, 126.0, 103.0, 125.0, 103.0, 125.0, 104.0, 126.0, 106.0, 130.0, 87.0, 129.0, 87.0, 129.0, 86.0, 126.0, 86.0, 126.0, 87.0]
grp = Group(Polygon(points, fillColor=colors.red))
grp.scale(1, -1)
grp.translate(0, -124)
d.add(grp)
renderPM.drawToFile(d, 'example1.png', fmt="PNG")

@replabrobin Robin, any idea if this is really an issue with reportlab? Thanks!

I think this is almost certainly an issue with the underlying libart library which we use to render the images. It looks as though the fill scanlines are just escaping from the confining polygon. In debian at least they want to abandon libart. I updated to latest debian code recently and found one (possibly serious) difference to the code which we have carried around for ages.

Oddly the problem disappears when the scaling and translation are removed so this is probably a numerical issue. Our code is slightly different to the debian code as we modify to clean up a lot of compiler warnings in the windows build. I will try the unmodified debian code to see if the problem is still there. I don't think this is a winding number issue.

The latest release of reportlab 3.5.5 contains a probabilistic fix, Looking in the code it seems randomization is a standard way to fix stability issues. Hope it works for svglib.

I can confirm similar issues with horizontal lines randomly appearing on rendered images. I'm running Windows 10. This is how one of our svg documents look like in Inkscape (looks same in Chrome):

And this is how svglib renders it:

You can find the SVG attached here:

mask.zip

Do you have an idea of a workaround ?

I'm not sure that this problem is the same issue. The original issue was with png rendering and relates to _renderPM.c; this error is happening in PDF rendering. It looks more like a structural issue decoding the SVG into RL graphics.

If you can make a minimal example that shows the issue I would raise it anew.

I wasn't able to reproduce, are you sure you are using latest svglib?

@replabrobin My issue is with PNG rendering, not PDF, should be the same issue no ?

I'm using svglib 0.9.2, reportlab version is 3.5.23 (can confirm with latest 3.5.26), this is the code I'm using:

from svglib.svglib import svg2rlg
from reportlab.graphics import renderPM
drawing = svg2rlg(filename)
renderPM.drawToFile(drawing, dest, fmt="PNG")

I realize now, maybe this comes from reportlab ? Could you share the code you're using @claudep ?

Oh, sorry, I was testing the PDF output, which looks fine.