Commit graph

5 commits

Author SHA1 Message Date
Manfred Stock
7dd51d08b6 Don't use temporary file for SVG data when rendering with Inkscape
This was already suggested in #22. In addition to potentially being a
little more efficient, this also avoids the problem of files referenced
from the SVG not being found, since the SVG is now rendered while in the
artwork directory, so relative paths inside the SVG are still correct.

Please note that the pipe functionality of Inkscape requires a relatively
new version of Inkscape, i.e. the version from Debian Buster is not
sufficient (the Buster backport from Debian should be though).

Unfortunately, the same does not work when using ImageMagick, since it
seems like they use different delegates/libraries to render the SVG based
on how it is passed, i.e. when passed as file, it got rendered with
Inkscape on my machine, when passing it as blob, it seemed to be some
internal library or another delegate which did not seem to support the
same feature set as Inkscape, which resulted in inferior output. Therefore,
a temporary file is still used for ImageMagick. However, the issue of
included images that could be solved for Inkscape with these changes
still persists, since at least when using the Inkscape delegate,
ImageMagick seems to create a temporary symbolic link in /tmp, which
prevents that the Inkscape delegate finds included images.
2022-08-27 15:34:09 +02:00
Daniel Molkentin
32b1cd8885 SVGTemplate should not need to know any specific names 2019-09-12 13:22:58 +02:00
Daniel Molkentin
4c7f481634 Fix refactoring errors 2019-08-28 09:21:54 +02:00
Daniel Molkentin
1b3892a984 Refactor svgtemplate into a neat context class SVGTemplate 2019-08-28 00:14:01 +02:00
Daniel Molkentin
7a915605d3 refactor svgtemplate into seperate file 2019-08-28 00:14:01 +02:00