[reportlab-users] Revival of svglib

[Dinu Gherman]

Hi Robin,

sorry for the late reply, but we have moved this discussion to github, already, it seems. If you want to go for some incompatible fix, I don’t think I’m the person to estimate how much existing code out there will be affected (it might not even break, but only generate wrong graphics).

In general I would favour any solution that respects the SVG spec, being something like the ultimate reference in vector graphics (?). I would assume that PDF also takes it for that, and it might be necessary to confirm that. But I haven’t worked with these things for years, and it looks like I’m not going to put these specs under my pillow anytime, soon, again.

Cheers,

Dinu

> On 11 Jan 2017, at 13:02, Robin Becker <robin at reportlab.com> wrote:
> 
> Hi Dinu,
> 
> I have been pondering one of the issues raised by Claude and it may be appropriate to talk about it here.
> 
> It seems the reportlab Path code is a bit broken in that it doesn't handle filled paths which are not totally closed in renderPDF.drawPath.
> 
> The canvas level operations eg drawPath/clipPath seem to do the right thing, but they have a slightly different model to SVG. In SVG a path which has fill set will be filled with an implicit closepath operator added. If stroke is set then the path is stroked, but without the implicit closepath. In the PDF model filling is done with an implicit closepath, but if stroking is also done then the closepath also applies to it.
> 
> So my problem is whether or not to change the existing behaviour of the renderPDF drawPath method and/or whether to adopt or allow for the svg path model.
> 
> In addition to the above we ought really to fix up the other renderers to do the right thing whatever that is decided. It is possible to change the behaviour by underhand techniques eg adding an optional _vg_model parameter to paths which defaults to 'use-existing' or equivalent. The svglib library could then add _vg_model='svg' to the paths and we would alter behaviour to emulate that.
> 
> Any thoughts?
> 
> On 04/01/2017 13:39, Dinu Gherman wrote:
>> Hi and Happy New Year!
>> 
>> A long time ago I wrote a package named svglib that would let me use SVG files in reportlab-generated PDFs. This projects has become dormant for many years, but some people kept nagging me a about updates. This recently resulted in Claude Paroz fixing a lot of remaining issues and helping with the migration to Python 3, which is really great news. Thanks, Claude! During the process we have even found a buglet in reportlab, which Robin, promptly as usual, fixed in v. 3.3.26. [1] (although that fix, being one in an increased reportlab package micro version, is available only for registered reportlab users from the reportlab PyPI server [2]).
>> 
>> So, if you have some SVG to use in your PDFs, please have a look at the code, run the extensive test suite (pulling in lots of samples from Wikipedia and W3C) and, even better, run it on your own SVGs and report any issues you find, before we are going to make a new revival release this January. There might still be some little issues left, but this new release will be the msot feature-complete svglib ever, running on Python 2 and 3.
>> 
>> Also, the svglib codebase is hosted on GitHub now, so feel invited to star and/or watch the repository! [3]
>> 
>> Best,
>> 
>> Dinu
>> 
>> [1] https://bitbucket.org/rptlab/reportlab/issues/98/
>> [2] https://www.reportlab.com/pypi/
>> [3] https://github.com/deeplook/svglib
>> 
>> _______________________________________________
>> reportlab-users mailing list
>> reportlab-users at lists2.reportlab.com
>> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>> 
> 
> 
> -- 
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> https://pairlist2.pair.net/mailman/listinfo/reportlab-users