Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimisation: Pipe input svg directly into inkscape instead using temporary file #22

Open
saerdnaer opened this issue Oct 31, 2017 · 0 comments
Open

Optimisation: Pipe input svg directly into inkscape instead using temporary file #22

saerdnaer opened this issue Oct 31, 2017 · 0 comments

Comments

@saerdnaer
Copy link
Member

intro-outro-generator/renderlib.py

Lines 150 to 163 in 7760bc9

# open the output-file (named ".gen.svg" in the workdir)
with open(os.path.join(task.workdir, '.gen.svg'), 'w') as fp:
# write the generated svg-text into the output-file
fp.write( etree.tostring(svg, encoding='unicode') )
if task.outfile.endswith('.ts'):
width = 1920
height = 1080
else:
width = 1024
height = 576
# invoke inkscape to convert the generated svg-file into a png inside the .frames-directory
cmd = 'cd {0} && inkscape --export-background=white --export-width={2} --export-height={3} --export-png=$(pwd)/.frames/{1:04d}.png $(pwd)/.gen.svg 2>&1 >/dev/null'.format(task.workdir, frameNr, width, height)

mstock added a commit to mstock/intro-outro-generator that referenced this issue Jul 16, 2021
@mstock
Don't use temporary file for SVG data when rendering with Inkscape
e71ae01 
This was already suggested in voc#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.
mstock added a commit to mstock/intro-outro-generator that referenced this issue Aug 27, 2022
@mstock
Don't use temporary file for SVG data when rendering with Inkscape
7dd51d0 
This was already suggested in voc#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.
mstock added a commit to mstock/intro-outro-generator that referenced this issue Sep 15, 2024
@mstock
Don't use temporary file for SVG data when rendering with Inkscape
522ba33 
This was already suggested in voc#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.
mstock added a commit to mstock/intro-outro-generator that referenced this issue Sep 24, 2024
@mstock
Don't use temporary file for SVG data when rendering with Inkscape
799fd20 
This was already suggested in voc#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@saerdnaer