Minor fixes and improvements #52
Conversation
|
@derchrisuk willst du da noch drüber schauen oder kann ich das so mergen? |
|
Ich schau mir das gerade an. |
|
Lustigerweise scheint zumindest bei mir trotzdem ein abspielbares Intro und Outro generiert zu werden, trotz der ganzen Fehler. Ich hab noch einen Commit auf den Branch gepusht, der das Problem mit der Fehlermeldung/Warnung bei mir behoben hat. Momentan vermute ich da tatsaechlich einen Bug in Inkscape, wenn man ein SVG mit UTF-8-Codierung per Pipe uebergibt. Wandelt man dieses z.B. per Was mir beim Testen uebrigens nebenbei noch aufgefallen ist: In den beiden fiffkon21-SVG-Dateien steht |
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.
It seems that when processing a SVG file passed via a pipe, Inkscape emits errors/warnings about an XML parser error if the SVG file is UTF-8 encoded. It still does seem to successfully process the SVG file and generates the expected output, however, these messages are at least confusing. Not passing the encoding parameter to etree.tostring() makes it output ASCII with non-ASCII characters encoded as XML entities, so this can then be correctly parsed again, and this does not seem to 'confuse' Inkscape.
… output Since videos with translations appear to require at least as many audio streams in the intro/outro as there are audio streams in the main video, this allows to create intro/outro files for videos with more than one translation (so far, the code already created 2 streams).
mstock
force-pushed
the
minor-fixes-and-improvements
branch
from
b165be1 to
af310d7
Compare
While working on the intro/outro for the SotM 2021 videos, I noticed some minor issues when rendering the videos. Some of these already had GitHub issues (which should be referenced from the commits in this PR) that should also get fixed by these changes.
Please note that the last two commits make use of features that are only available in more recent Inkscape versions, i.e. the version from e.g. Debian Buster is too old for this, the Backport should work though.