svglib for svg handling

[Dobatymo]

Could https://pypi.org/project/svglib/ be used instead of cairosvg to handle svg/clp files?
It would have the advantages that we can remove cairo as a dependency and also insert SVGs as vector files and not rastarized.
Not sure if there are any issues I haven't thought about.

[AnEnglishmanInNorway]

I have to admit that the graphics handling is not my domain at all, but my initial reaction would be "if it works, leave it alone". I see the theoretical advantage of handling svg directly, but is there any other benefit? And isn't cairo there for more than just the svg handling? The tricky bit would be to make sure all our old albums still produced the "correct" result. But if you're interested from a purely theoretical point of view, try it on your fork and see how it works out!

[AnEnglishmanInNorway]

Hi @Dobatymo. Did you ever get around to trying svglib yourself? If so, then you might like the latest pixel-by-pixel test result verification, though I have to confess that I have refactored the code into smaller files which will make it a bit more difficult to merge with your own work. Alterrnatively, if you don't plan to look at svglib, perhaps we can just archive (close!) this issue for now and leave it for another day?

[Dobatymo]

Hi @AnEnglishmanInNorway
I still would like to use svglib instead. I have been busy with other stuff, however I would like to come back to this here. Having good testing comparison will make it easier. Could we leave it open for now?

[AnEnglishmanInNorway]

Thought I'd just add a note here for future use. I just moved to a new win 11 machine, and of course ended up needing a gtk installation to support cairosvg (from https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases). I asked Copilot if it thought svglib would do the job. This is what it said (it even provided me with its "opinion" formatted in markdown for inclusion here!

Comparison: CairoSVG vs svglib for SVG to PDF Conversion

✅ Pros of svglib

• Integrates with ReportLab to convert SVG to PDF
• Handles basic shapes, text, and simple vector graphics
• Easy to use via svg2rlg() and renderPDF.drawToFile()

⚠️ Limitations of svglib

• Limited support for complex SVG features (e.g., filters, gradients, advanced CSS)
• Font rendering and layout can be inconsistent with non-standard fonts
• May misplace text or rasterize vector elements poorly
• Output fidelity often falls short in high-complexity SVGs

🆚 CairoSVG Strengths

• More robust rendering, especially for complex SVGs
• Better support for styles, fonts, and embedded resources
• Handles headless batch conversions gracefully
• Paired with GTK runtime, it delivers high-quality vector exports

💡 Recommendation

For clean, simple SVGs, svglib may be sufficient. For high-fidelity PDF output, especially with advanced features, CairoSVG is the preferred choice.

[AnEnglishmanInNorway]

I've just been using OpenAI's Codex AI to make a whole batch of changes and improvements. I asked it about your idea of using svglib. Here, for the record, is what it said. I won't be doing anything about this

I think #191 is a good idea, but not a simple CairoSVG replacement.
svglib can convert SVG into ReportLab Drawing objects and render them directly into a PDF, so ordinary CEWE clipart could remain vector rather than becoming a PNG. It is actively maintained and specifically supports PDF output without Cairo. svglib documentation
The complication is that current clipart handling deliberately rasterises so it can apply:

• CEWE’s arbitrary stretch-to-frame behaviour;
• whole-clipart alpha;
• horizontal and vertical flips;
• image alpha masks/passepartouts.

The first three are feasible with ReportLab canvas transforms. The masks are the concern: svglib explicitly does not support SVG elements, and its CSS/clip-path support is limited. So removing CairoSVG entirely would likely lose some existing cases. Its LGPL-3.0 licence is fine alongside this GPL-3 project, incidentally.
My recommendation:

1. Add svglib as a vector path for ordinary clipart areas.
2. Keep the current CairoSVG/Pillow path as a fallback, especially for masks or unsupported SVG.
3. Make a focused test using several real CEWE .clp/.svg files: simple shapes, gradients, colour replacements, flips, and complex/masked clipart.
4. Only consider removing CairoSVG if that corpus proves it genuinely unused.

That would be a worthwhile feature: sharper PDF clipart and potentially smaller PDFs, without betting all existing rendering on svglib’s SVG subset.