Openshot-qt: SVG files not rendered properly

[N3WWN]

I've seen this since one of the Openshot 2.3 versions (never used anything older than 2.3) and can confirm the issue is still present in 2.4.1 cuz I just used 2.4.1 to prepare the support files for this issue.
This has always been on Fedora 25.

I use titles to overlay statistics on my videos. I like to have fun with them (sometimes) and wanted a creepy font with fun colors for a Halloween-themed video I was working on.

Starting with one of the stock titles and using the Advanced Editor (inkscape), I created a title using the Shlop font, made it green and turned the stroke red.

This file is provided in the attached zip archive: Stage 1 stats.svg

Directly using/importing this SVG file within Openshot results in very different rendering, most of which is off screen due to the text anchor point being honored, but the alignment is ignored.

In order to better see how Openshot is rendering the SVG file, I copied the file and manually edited it, adding an x-offset of -800 pixels.

This file is provided in the attached zip archive: Stage 1 stats_offset.svg

In order to use this SVG file, I had to convert it to a PNG on the command line and import the transparent image.

This file is provided in the attached zip archive: Stage 1 stats.png

The OSP file is included in the attached zip archive, too: SVG rendering issue - 171128.osp

An Openshot 2.4.1 rendered video that shows each of the 3 files and demonstrates that the issue is present in the final export (not just the preview) is available here: https://youtu.be/1R6uUPfotss

SVG rendering issue - 171128.zip

Please let me know if I can provide any additional information or help.

Thanks!

-Rich

[DylanC]

@N3WWN - Wow, this is an example of a really great bug report! O_O Thanks a million!

[donkikhot]

Hi
i have this problem too
OpenShot 1.4.3 (font Cyrillic old)

[peanutbutterandcrackers]

@donkikhot - Good sir, Openshot 1.x series is no longer under development. Perhaps you should try the 2.x series out.

@N3WWN - Wow. That's a really good report. :+1:

[donkikhot]

Ok, thanks.

[peanutbutterandcrackers]

@donkikhot - I will try to bring the developer's attention to this, too. Hopefully, this will be fixed soon. I hope you keep on supporting OpenShot and do report any issues as they arise. Thanks! :)

[peanutbutterandcrackers]

@DylanC - Can you confirm this, cap'ain? I am not that good with InkScape. Perhaps this ought to be put in the check list for v2.4.2?

[gary9872]

Didn't work for me either

titles_model:INFO updating title model.
exceptions:ERROR Unhandled Exception
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/openshot_qt/windows/main_window.py", line 357, in actionEditTitle_trigger
win = TitleEditor(file_path)
File "/usr/lib/python3.6/site-packages/openshot_qt/windows/title_editor.py", line 120, in __init__
self.load_svg_template()
File "/usr/lib/python3.6/site-packages/openshot_qt/windows/title_editor.py", line 275, in load_svg_template
self.update_font_color_button()
File "/usr/lib/python3.6/site-packages/openshot_qt/windows/title_editor.py", line 372, in update_font_color_button
s = node.attributes["style"].value
File "/usr/lib/python3.6/xml/dom/minidom.py", line 552, in __getitem__
return self._attrs[attname_or_tuple]
KeyError: 'style'

[peanutbutterandcrackers]

Thank you for the confirmation. Are you using the latest daily build? Does it render incorrectly or are you unable to import the svg file at all? o.O

[DylanC]

@peanutbutterandcrackers - Maybe consider this for the checklist.

[peanutbutterandcrackers]

@DylanC - The checklist has been updated, Cap'ain!

[N3WWN]

FYI, I'm working on resolving this right now. It will hopefully be my next PR for this project.

[peanutbutterandcrackers]

Awesome! I am looking forward to the PR! :)

[N3WWN]

OMG! I can't believe I messed up the PR for this! I somehow PR'd zero changes back into my dev branch instead of here.

At any rate, would @peanutbutterandcrackers , @DylanC , @ferdnyc and/or @jonoomph take a look at my changes and do a quick sanity check on them:

https://github.com/OpenShot/libopenshot/compare/master...N3WWN:resvg_rendering

I'll remove the lines with my initials (RDA) before doing the actual PR. I use them as search anchors to jump around in files quickly.

There will need to a change to openshot_qt/installer/build-server.py and openshot_qt/freeze.py so that the resvg.so library is packaged with the AppImage builds. I'm not sure what else will need to be changed for other pre-packaged builds as I'm only ever using AppImage builds, even for my own local testing.

Basically, if the image file has an .svg extension, the rendering is performed by an external library (resvg.so) and the rendered image is saved to the homePath()/.openshot_qt/cache directory. resvg supports a "static SVG Full 1.1 subset", which is much more than QtSvg, which "officially supports only a tiny portion of the SVG Tiny 1.2 subset".

cmake/Modules/FindRESVG.cmake will try to find the resvg library and, if it is missing, libopenshot will be compiled and function exactly as it does now. This means that devs and power users can clone the libopenshot repo and compile it themselves in the presence of the resvg.so library to gain this feature, but it does not need to be compiled into the publicly released builds right away.

Feedback welcomed for this change before I submit the PR so I can fix any problems beforehand.

Thanks!

[ferdnyc]

Hmm, seems I can't comment on that branch as it's not a pull request. That's fine, here works.

I haven't tested the SVG changes yet, but I will try to. But if there are rendering issues with the current lib, and resvg fixes them, then changing over sounds sensible. Thanks for doing the work to find an alternative.

I'm a bit concerned that sudo dnf search resvg on my Fedora 27 box returns no results — is the library packaged for standard distros? How is it identified? The dependency change will have to be communicated to packagers so that they can update their builds.

That aside, one minor nit: I'd suggest submitting OpenShot/libopenshot@16b9cd949df393414c118136520b308b04505254 as a separate pull request from the rest. I'm curious to see how it affects the logging output, but on first glance it looks like a good change to me. If I'm interpreting correctly it's totally unrelated to the SVG rendering changes, though, yes? Better if each logical change stands alone in its own PR, and can be evaluated on its own merits.

[ferdnyc]

I subsequently (and accidentally) deleted the comment that referenced this issue, but I'm glad the link stayed here because I ended up tossing a bunch of inline comments at the commit, which can be seen by following the "ferdnyc referenced this issue..." link above. They don't show up inline if you follow @N3WWN 's link (though I now see they're collected at the bottom of the page), because I didn't have permission to add inline comments there. For some reason! (That reason being: Github is confusing.)

I looked into resvg a bit more. It's distributed under the Mozilla Public License 2.0, which is good because that's considered a GPL-compatible license and is permissible for packaging in Fedora and most likely other libre distros as well, unless the license user has explicitly chosen to make it _incompatible_ (which it doesn't appear RazrFalcon has).

Surprisingly enough, though, it appears that nobody has even _proposed_ its inclusion in the Fedora packaging system. ...Actually, I guess that's not so surprising when you consider that it's only even been available on Github since December 18. Yes, of last year. This thing is _really_ new, and OpenShot would likely be the impetus for its inclusion in many distros. That's not necessarily a bad thing, assuming it's mature and stable enough to meet our needs, and using it solves problems.

I was hoping that perhaps the rendering issue was caused by older AppImage versions of QtSVG, but after building the Qt svgviewer example project under Qt 5.9.4 and using it to load both of the sample .svg files, it's clearly just doing things... wrong. So, QtSVG is definitely failing us here.

(It probably makes sense, for their purposes, that Qt is targeting SVG Tiny 1.2 with QtSVG, as that's explicitly "a profile of SVG intended for implementation on a range of devices, from cellphones and PDAs to laptop and desktop computers" and Qt is very focused on mobile-platform support these days. But it does mean that if we want to incorporate arbitrary files from a full-featured editor like Inkscape, it's probably not going to be up to snuff. QtSVG is meant, it seems, to work with SVG files which have been designed with the intent of using them in Qt applications, and therefore can avoid coloring outside the lines of SVG Tiny 1.2.)

[ferdnyc]

@peanutbutterandcrackers writes:

@DylanC - The checklist [for v2.4.2] has been updated, Cap'ain!

Checklist? There's a checklist?

Does this mythical checklist exist anywhere accessible to others? Seems like it could be a useful thing to have outward-facing.

I know Github has the Projects feature for basically this purpose, though I've never used it myself. There's a Projects tab in the repo here, though currently the only thing it contains is an "ad" for the feature and a link to that doc. So I'm assuming @jonoomph or someone would have to enable access, before it could be used for anything. Still, even a Github issue containing the list would be a way to connect issues to it, sort of like a tracking bug in bugzilla.

[peanutbutterandcrackers]

@ferdnyc - Here it is. It's just a humble little check-list. :)

@N3WWN - I'm afraid I won't be able to test this out as I am working from a friend's computer even right now. But I'll try to see if I can. However, with @ferdnyc here and @DylanC, I think you have plenty of good testers. But awesome, good sir! You're amazing!

[ferdnyc]

[Checklist] Neato.

Another question I can't believe I didn't think to ask until now: Do we know the status of resvg on Windows/MacOS? Has anyone (on their end, I mean) looked into building it for those platforms? If QtSVG is failing us, it's failing us on every platform, and whatever replacement we use should probably be used everywhere.

I have no idea where resvg stands on that front, I'm honestly asking. Hopefully it's not a problem. If it's not going to be available on one of our platforms, though, I have to imagine that certain other options (librsvg in particular) should be fully cross-platform and should also solve these issues. (I can say that with a fair degree of certainty, since it's what ImageMagick uses for SVG support and ImageMagick (a) has excellent cross-platform support, and (b) had absolutely no trouble rendering the bug sample files properly when I used it to view them.) Really, any general-purpose SVG library should work; my understanding, having now looked into it more, is that QtSVG is _not_ quite a general-purpose SVG library.

Sorry to bombard you with these questions, @N3WWN , just thinking out loud.

[ferdnyc]

I looked into it. They have a build process for Windows and MacOS, so there hopefully shouldn't be any issues. It does mean that rust will need to become part of the OpenShot build environment on those platforms as well. (On Linux that won't be necessary, at least once distros have resvg already built and available as a packaged library.)

They do mention that their Qt backend only "officially" supports Qt >= 5.6. It "should" work with any version, they handwave (prefaced with "Technically," to inspire maximum confidence), but this is another excellent argument for updating the version of Qt used for the AppImage build to something newer than 5.2.1. (IIRC Windows 2.4.1 uses 5.6.something, so that's good enough. I'm blindly assuming MacOS is current enough as well.)

[N3WWN]

I wish I could reply to each message individually, but alas, I have to reply with some context quotes (see also @ferdnyc 's comment of "Github is confusing"). 😄

@ferdnyc :

I'd suggest submitting OpenShot/libopenshot@16b9cd9 as a separate pull request

This should already be a separate pull request under these two PRs:
https://github.com/OpenShot/libopenshot/pull/82
and
https://github.com/OpenShot/libopenshot/pull/86 (which fixes builds on Mac OSX)

Regarding resvg, yes, it is very new, but I tested out several different methods of rendering SVG files and resvg provided the most features in a relatively small library (do one thing and do it well) that interfaced well with the existing code.

I have updated the build scripts on my dev system to include the resvg library in the AppImage, so it would not be necessary for the individual distro to have resvg available. This would mean that distro-specific builds would lack the full rendering, so perhaps this functionality should be a runtime configuration item (detect the presence of the library and use it, if present, or set the path for it like blender and inkscape in the preferences).

That definitely shouldn't say "FFmpeg" there ( https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28778119 , https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28778119 )

Oops! You're right! I need to clean up those files!

...ensure that it's only looking at the very end of the string ( https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28776960 )

Good catch! I definitely need to fix that!

"Path manipulation" described here : https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28777053 and here : https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28778078

I will look into this, too!

"printf" described here : https://github.com/N3WWN/libopenshot/commit/fc4860bd8d1686ff2fabfdfd15164c96c11c6d66#r28777146

Yup, obviously debugging code that I had in place that also needs to be cleaned up or removed . It's this kind of thing that is hard to see in your own code and why I didn't submit a PR without getting feedback from you guys 😁

@peanutbutterandcrackers

...just a humble little check-list

Thanks for the link to the list! I had not seen this before, either, and may help me find items to work on next!

I'm afraid I won't be able to test this out as I am working from a friend's computer even right now.

If you're running a Linux machine, I can upload an AppImage for you (or anyone) to test.

@peanutbutterandcrackers and @ferdnyc

I don't have the dev env to build for Mac OS or Windows, but resvg is cross-platform (one of my requirements for the external SVG renderer).

@ferdnyc

Sorry to bombard you with these questions

Bombard away! Most of OpenShot is outside of my wheelhouse, but I use it all the time and any improvements that I can help with help me and, presumably, everyone else who uses it.

I'll take the feedback and update my PR as time permits (not sure what this week looks like yet, so it may or may not be today or tomorrow).

[ferdnyc]

I wish I could reply to each message individually, but alas, I have to reply with some context quotes (see also @ferdnyc 's comment of "Github is confusing").

Yeah... and some of that confusion stems from the odd things they've left _out_. F'rinstance, I _really_ don't understand why, in the Issues web interface, even when you select some text and use the 'r' shortcut to start a quoted reply, it doesn't _attribute_ the quoted text at all. I won't even bother wishing for real threading, but who figured bare, unattributed blockquotes would be very useful?

It's a very strange, seemingly social-media-influenced conversation structure. (With maybe the odd random feature plucked from email / more traditional online discussion, like the fact that you _can_ quote previous "comments" at all.) Which I suppose may be liked for its familiarity, if it's the only style of online interaction you've ever known, but it's just not as good a fit for bug-tracking and discussion as they seem to imagine. Or maybe I'm just an old fart. Well, no, not maybe.

Yup, obviously debugging code that I had in place that also needs to be cleaned up or removed . It's this kind of thing that is hard to see in your own code and why I didn't submit a PR without getting feedback from you guys

*nod* Though, having tried out the external-repo feedback thing for the first time, now, it's... not ideal. It _should_ be simpler, but Github makes certain things a pain when trying to refer/interact across users' forks. Their concept of request-for-feedback code seems to want it presented _as_ a PR. That gets it in front of the group (directly), enables the full power of Github's review flows (without the "oh, I can't comment here, but I can comment there..." struggle when going against The Github Way™), and... well, hell, it's even nice just to be able to refer to the proposed code by writing " #1384 ", instead of having to puzzle out cross-repo refs/links. :grin:

You can always mark the PR "WIP:" to show that the code isn't ready or intended to be merged, like I did with #1384 until I was confident it was ready to go. (There's even a Github WIP app someone wrote that formalizes the process: It runs a bot that watches for PRs with "WIP" or "do not merge" in the text and sets them to pending status. Mostly that means it disables the Big Green Merge Button, looks like. So, in theory @jonoomph could install that in the repo to manage evolving PRs until they're ready for primetime.)

In the end, tho, I think just getting the code out there, however it's done, is more important than the bureaucracy of _how_. So thanks for doing that, and looking forward to the next updates on this one!

[N3WWN]

Yeah, I agree with everything you've said, so I must be just as old of a fart as you! 😆

So, for the sake of the flow that we're looking at with OpenShot, would you prefer I make a "WIP" PR for us to continue the discussion?

[ferdnyc]

I think it might be more convenient for us all to be able to discuss the changes that way, and it'd help corral the discussion into a single location, yeah. See @DylanC 's #1506 for an example of the back-and-forth we've been doing on that PR over the past few days.

It sounds like this is getting pretty close, so I don't know that there'll _need_ to be that much more discussion, but when you've got something ready for us to kick around again... I'd say shoot it over as a PR, sure. But that's purely my opinion, speaking only for myself. I don't know if @jonoomph has any particular views on in-development PRs, but I 'd say his opinion should carry the most weight since he's really the intended audience for them all, ultimately.

[N3WWN]

Ah, I see... I can edit the title of the PR after I submit it, so I can prepend "[WIP]" to the PR title and remove it when it is ready.

I'm going to go ahead and submit a PR for this, noting it WIP, for us to continue. Since I'll reference this issue, the bread crumbs should lead us where we need to go.

[If @jonoomph says, "No WIP PRs, please," we'll deal with that at that time 😉 ]

Thanks @ferdnyc !

[peanutbutterandcrackers]

@N3WWN - Yes, please! An AppImage would be great! Also, I am glad that the checklist could be of some help. :)

[N3WWN]

@peanutbutterandcrackers (and anyone else who wants to give it a try), give this one a "Shot":

https://www.dropbox.com/s/5qrswr9yfqf2ipa/OpenShot-v2.4.1-65-g0b47fd8-59-688-x86_64.AppImage?dl=0

I built this one on Apr 25th and have been using it for my videos ever since. It has resvg support built in as well as SHIFT+LEFT and SHIFT+RIGHT to nudge selected clips.

Not sure how long I'll keep it up on Dropbox, but I'll keep it there for at least a week.

ETA: That AppImage is using the externally cached and loaded rendered images a la https://github.com/OpenShot/libopenshot/pull/88/commits/b73ef9b7383602727604dc6f032948a5088c6496 . For the user experience, it's exactly the same as the current state of the PR... the current PR is just more efficient.

[peanutbutterandcrackers]

@N3WWN - Thank you! wget -c-ing it right now (I don't have the best Internet connection :D )

[peanutbutterandcrackers]

@N3WWN - I'm sorry I still haven't tested it out yet. But this morning, I had this thought - why don't we use what inkscape uses to render svg files. And turns out, inkscape uses cairo to render stuff. Do you think OpenShot could also use Cairo? Just a thought. I have to confess I don't know very much about all this...

[N3WWN]

@peanutbutterandcrackers - resvg can use either Qt or Cairo backends. Since OpenShot already uses Qt, that seemed like a natural fit rather than add another external dependency.

[peanutbutterandcrackers]

@N3WWN - Oh, I see... Hmm. I will try to test the AppImage out, soon. :)

[peanutbutterandcrackers]

@N3WWN - So, I did try out the AppImage. Will probably do some further tests but so far I have found only one svg file that it couldn't render. All the others - it rendered really well. You're awesome, as always!
However, I couldn't render this one particular svg file. I wonder why that is...

[N3WWN]

@peanutbutterandcrackers - I'm getting the following errors from resvg for All-times-exist-together_nevit_126.svg:

Warning (in svgtypes::style::parser:201): Style attribute '-inkscape-font-specification' is skipped.
Warning (in svgtypes::style::parser:201): Style attribute '-inkscape-font-specification' is skipped.
Warning (in svgtypes::style::parser:201): Style attribute '-inkscape-font-specification' is skipped.
Warning (in svgtypes::style::parser:201): Style attribute '-inkscape-font-specification' is skipped.
Warning (in usvg::preproc:113): File doesn't have 'width', 'height' and 'viewBox' attributes. Automatic image size determination is not supported. The Document will be cleared.
Warning (in usvg::convert:66): Invalid SVG structure. An empty tree will be produced.

I'm no SVG specification expert, but it looks like the height and width attributes are set to a %, which is fine if there's an existing window/frame/viewport/etc to render the image within, but as a standalone image, that doesn't appear to work without a viewBox.

I did run each of the svg files that comes with OpenShot through resvg the other day and, while I did get some of the same Style attribute '-inkscape-font-specification' is skipped warnings, they all rendered properly. The only exception being Creative_Commons_1.svg, where the banner text (black on white) is not visible:

It should look like this:

Since Creative_Commons_2.svg renders fine, I'll have to see what the issue is with the first.

[N3WWN]

@peanutbutterandcrackers - I just confirmed that it was the height and width specified as percentages. Here's the same file with width="100%" replaced with width="819" and height="100%" replaced with height="1353" (to mimic the sized of the original): All-times-exist-together_nevit_126_rda.svg

[peanutbutterandcrackers]

Hmm.... I see.

However, the photo manager could render it pretty well. Even on this LXLE machine, mirage, the default photo manager can open it well. And so can InkScape.
Also, the Creative_commons_2.svg thing might be a problem. I wonder why resvg can't render it properly.

Perhaps you should file an issue regarding this over at resvg's repo?

[ferdnyc]

@peanutbutterandcrackers - I just confirmed that it was the height and width specified as percentages.

That's _supposed_ to be OK, though, and indeed the original file passes every SVG validator I can find with flying colors.

Because SVG files are scalable, you shouldn't have to specify pixel dimensions for a file, as it can be rendered at any pixel dimensions you want. There really are no "native" pixel dimensions for a fully-vector SVG file. There may be "nominal" dimensions that control the coordinate system used within the file, but those dimensions may also be specified in units other than pixels.

width="100%" is, in a way, actually _preferable_ as a way of specifying an SVG file's dimensions, as it simply means "render to fill available space". That's why, for example, the file shows up with a preview icon in my file manager: The thumbnailer knows that it's supposed to render icons at 128x128 pixels, so it just _does_, and implicitly width="77" and height="128" for that render. (Not quite the proportions of the original, because like most renderers, including Wikimedia's, the file actually renders with some random blank space to the right and bottom of the text.)

The percentage dimensions also makes that file a good test of rendering capabilities, though, because while it _should_ be OK, it isn't always. OpenShot isn't the only software that has problems with that file. ImageMagick's display command line tool insists on rendering it at 1px × 1px by default, and I can't seem to convince it _otherwise_ with any combination of flags. I consider that a bug in ImageMagick, to be honest.

It's certainly not out of the question to say, "SVG files used in OpenShot must be sized for the video frame", if necessary. But, if it's _possible_ it would be nice NOT to have to do that, especially with video resolutions being so variable recently. I'd love it if the same .svg files we use for HD could be used unmodified on 4K or higher videos, and they'd just render at the native resolution of the output.

I haven't read the code, so apologies if I'm making bad assumptions here. But I'm guessing that, today, if we're expecting pixel dimensions inside the SVG files, that doesn't work? It'd be awesome if it could be _made_ to work, though I'd say it's only worth it if it can be done without too much effort. If there's any way to pass a target output geometry to resvg, when rendering, then would handing it the width and height of the current output profile help with rendering files like that one?

If it isn't easily solvable, then I see no problem with just mandating that SVG files used in OpenShot titles have to contain concrete physical dimensions, as we know that works well and it's a perfectly reasonable restriction considering we're rendering to fixed pixel sizes anyway.

[ferdnyc]

The only exception being Creative_Commons_1.svg, where the banner text (black on white) is not visible:

That's the file. About to open a PR that should fix it. (ETA: #1600)

[peanutbutterandcrackers]

Perhaps the resvg devs should be informed about this? o.O

[ferdnyc]

About which? The Wikimedia SVG or our broken Illustrator-mangled title file?

The Wikimedia file is only a problem if resvg has the same issue as ImageMagick, and fails to render it at set dimensions when those dimensions _are_ specified. I'm not yet clear on whether that's the case, hopefully @N3WWN can shed some light.

(That file, while (as I said) technically valid, is also wonky in other ways. Like, it loads in Inkscape, but if you look at what you're _seeing_ there, it's pretty bizarre. Inkscape sets up page dimensions of 1×1 (either pixels or millimeters, I forget which), then renders the drawing totally outside of that area. So if you use "Zoom to Page" you get this tiny, empty box, and there's a giiiiiiiiiiant drawing way offscreen to the lower ~left~ right. If you "Zoom to Drawing", there's a teeeeeny almost invisible page-area floating to the upper left of the drawing. It's just screwy.)

Our wonky title file, I suppose they might be interested, possibly in adding <switch> to their test suite if nothing else. But at the same time, it's not really within their stated goal featureset to support weirdo extensions like that, so I suspect it will continue to fail that test, and the official word will be, "Not supported, not going to be." Which is perfectly fair. Still, like I said, it may be of interest to them. (ETA: Actually, come to think of it, before bothering them we should check that it isn't _already_ a known-fail part of their test suite.)

[peanutbutterandcrackers]

About the file where the height and width were specified as 100% instead of pixels. But now that you say it and I have tested it on InkScape... I see what you mean. Perhaps it is not necessary to file an issue, then.

I hope resvg will soon support anything and everything the svg standard has specified and will become a one-stop-solution for everything svg.

[ferdnyc]

Mmm, and re: the breaking version of our Creative_Commons_1.svg, it turns out that, while <switch> is standard SVG, as the SVG spec itself notes:

Usually, a ‘foreignObject’ will be used in conjunction with the ‘switch’ element and the ‘requiredExtensions’ attribute to provide proper checking for user agent support and provide an alternate rendering in case user agent support is not available.

It was the foreignObject within the <switch> that utilized an Illustrator extension. And, indeed, resvg is documented as not supporting or properly handling foreignObject at this time.

[N3WWN]

All of the existing svg files that come with OpenShot have fixed widths and heights specified, so I don't think it's a show stopper that resvg does not currently support images with dynamic sizes.

I'd love it if the same .svg files we use for HD could be used unmodified on 4K or higher videos, and they'd just render at the native resolution of the output.

Maybe we could do this by adding a tad of parsing to the svg data before it is sent to resvg for rendering? If a % height or width is specified, replace that percentage with a fixed value.

I have looked at obtaining project/timeline info within the readers (QtImageReader in particular), and as far as I can tell, it's not available. But if it is, or can be made so, it will allow us to fix this and other issues, like https://github.com/OpenShot/openshot-qt/issues/1478#issuecomment-388176705, as well.

[mcbluefire]

This problem continues in 2.4.3 and 2.4.3-dev1 that I just downloaded tonight. I even created a multiple line title in the latest version and it instantly converted to a title and the multi-line subtitle show as one continuous line.

assets.zip

[ferdnyc]

This problem continues in 2.4.3 and 2.4.3-dev1 that I just downloaded tonight. I even created a multiple line title in the latest version and it instantly converted to a title and the multi-line subtitle show as one continuous line.

That's not a rendering thing, that's a structure thing. If you noticed, loading the file into the Title Editor showed the file as containing three lines (with "Title", "Line1", and "Line2" filled in). But in Inkscape, you only had two text boxes: lines 2 and 3 ("Line1" and "Line2") were in the same two-line box, which confused OpenShot. Changing the rendering engine wouldn't change that.

This version of the file splits that box into two separate boxes, so there's one per each of the three Line fields in the Title Editor. It renders fine in OpenShot. (I just roughly eyeballed the placement of the third line ("Line2"), so that may have to be adjusted. It's definitely not in exactly the same place as it was in the original version.)

TitleFileName-2.svg.zip

Also, just as an aside, those drop shadows on the text aren't going to be rendered. OpenShot doesn't support the "filter" attribute, so they're just ignored. (ReSVG doesn't support filter either, so that's another thing that's not going to change.) You can remove them with the "Remove Filters" option at the bottom of the Filters menu in Inkscape to make the file simpler, but even if you leave them there the rendered titles aren't going to have drop shadows.

[mcbluefire]

@fernyc,
Thanks for the reply. I appreciate all the details in your response. What is interesting are the following:
1) Openshot doesn't support the filter attribute so the drop shadows won't be rendered. This is the "Gold 2" title template supplied by Openshot 2.4.3 with one line added via "advanced editor" option in OpenShot.

2) Openshot's title editor is what is showing there are more than one line - so why doesn't OpenShot itself render with more than one line? The OpenShot title editor and the OpenShot renderer should be on the same page. Nautilus shows the svg file correctly, image viewer shows it correctly, firefox shows it correctly, OpenShot 1.4.3 shows it correctly and ...; I'd be hard pressed to find anything that shows it incorrectly other than OpenShot 2.4.3. That has to be an OpenShot rendering issue: what else could it be? Newlines in a text box is not outside of the standard - although technically it is a completely new tspan complete with x and y position that are being ignored by the renderer in OpenShot.

3) I appreciate that I can just add a new text field for every line and will likely have to do that or make a png of every title and replace them in the timelines until Openshot can render an svg per standards. Now I need to go back and edit 140 titles I just created two weeks ago using Openshot 1.4.3 and Inkscape/"Use Advanced Editor" because Openshot 2.4.3 cannot properly render an SVG file that was created using tools supplied with Openshot 2.4.3 and previous.

4) There is an additional issue in the rendering. Like I said, I have 140 titles. All 140 were created using "Gold 2" title template in 1.4.3. They all draw perfectly in everything but OpenShot 2.4.3. Once I view them in OpenShot 2.4.3 they go from title/multi-line subtitles centered to tittle/single-line subtitles justified left from the center of the screen. Even if there was only one line in the sub-title it still goes from centered to left-justified from the center. Granted they are using the text-anchor:start and text-aligment:start tags as created by inkscape, but they render fine anywhere other than OpenShot 2.4.3.

I moved to Openshot 2.4.3 because I was running into several cut issues with 1.4.3. I'd cut a scene precisely to the frame between scense (using left-right arrows and 'c') and then rarely when I reviewed the clip it would go for another a second or two into the next scene. I'd then have to cut it again and move the sliver to the next scene. Kind of rough working with tiny clips of a second or less. 2.4.3 makes it easier to move slivers like that around and even better just resize the clip to include/exclude as necessary. I do not have the luxury of moving back to 1.4.3 as once the autosave happened to the project file OpenShot 1.4.3 no longer can use the project file.

Appreciate your earlier response and hope my additional feedback/thoughts help.

[ferdnyc]

1. Openshot doesn't support the filter attribute so the drop shadows won't be rendered. This is the "Gold 2" title template supplied by Openshot 2.4.3 with one line added via "advanced editor" option in OpenShot.

OpenShot is supplying titles with drop shadows / filters? Hm. So it is. Specifically:

$ cd src/titles; grep -c filter *.svg|egrep -v ':0$'|cut -d: -f1
Bar_3.svg
Gold_1.svg
Gold_2.svg
Gold_Bottom.svg
Gold_Top.svg
Post_it.svg
Sunset.svg

Note to OpenShot devs: Probably shouldn't be doing that, it's just misleading.

1. Openshot's title editor is what is showing there are more than one line - so why doesn't OpenShot itself render with more than one line? The OpenShot title editor and the OpenShot renderer should be on the same page.

Well... you're right. There are conflicts in the way things interact. And I may be wrong that changing the rendering engine wouldn't change this, because (as you saw) OpenShot parses the contents of the SVG based on TSPAN tag, and finds three lines. But QtSVG's very simple renderer only supports SVG Tiny, and TSPANs with positional properties are outside the SVG Tiny spec, so QtSVG ignores those properties and renders the second TSPAN right after the first, because they occupy the same text box. (As that bug notes, Qt are open to accepting patches that add support for positional TSPANs to QtSVG, but currently nobody's working on those patches.)

As things currently stand, addressing this in OpenShot would probably take the form of parsing based on TEXT tags, rather than TSPANs, in detecting what constitutes "a line". That would match the output of the renderer. But such a change wouldn't solve your problem, it would merely get OpenShot, as you say, "on the same page" as the QtSVG renderer.

That has to be an OpenShot rendering issue: what else could it be?

A QtSVG / SVG Tiny limitation.

Now I need to go back and edit 140 titles

As far as actually solving _that_ problem, if the titles all take the same basic form (one or more of their TEXT tags encloses multiple TSPANs positioned to represent multiple lines), if you're able to zip them all up and attach them to this issue I can fix up the structure en masse with a little Perl.

Once I view them in OpenShot 2.4.3 they go from title/multi-line subtitles centered to tittle/single-line subtitles justified left from the center of the screen. Even if there was only one line in the sub-title it still goes from centered to left-justified from the center. Granted they are using the text-anchor:start and text-aligment:start tags as created by inkscape, but they render fine anywhere other than OpenShot 2.4.3.

I'd have to see the structure, but since the start value corresponds to left-alignment (or right-alignment in RTL text), there _must_ be a text-align:center or text-anchor:middle _somewhere_. In the title file you attached, all of the TEXT tags used text-anchor:middle and text-align:center. As did all of the TSPANs, though as a positional attribute, I believe that also isn't supported under SVG Tiny. Still, didn't matter as the TEXT tags were set correctly.

If you're seeing centered text in _other_ applications, my guess is that the TEXT tags are set text-align:start / text-anchor:start, and the TSPANs individually have text-align:center / text-anchor:middle properties, a configuration which would cause left-alignment in QtSVG. Regardless, that's something that I should also be able to fix en masse.

[ferdnyc]

As a side note, I'd personally love it if Inkscape supported SVG Tiny as an output format, or better yet an input/editing mode, and restricted the featureset accordingly to avoid creating files which use features not supported in SVG Tiny. There was some discussion of SVG Tiny compliance and/or output around 10 years ago, but nothing seems to have come of that.

[mcbluefire]

@ferdnyc
Appreciate all your responses. You are definitely correct the TEXT tags have settings for center and middle. :+1: My guess is from 1.4.3 to 2.4.3 OpenShot devs made a major decision to shift to another less feature-rich svg renderer. Wonder what happened to the old svg engine. :-1:

I'm happy to do some perl, sed or other scripted replacements en masse on the files myself. You appear to know the svg markup pretty well. Would I just be needing to replace the tspan tags with text tags so QtSVG can work with them? Appreciate any insight. Also, if you have somewhere we can take this offline, I'm good with that.

[ferdnyc]

You appear to know the svg markup pretty well. Would I just be needing to replace the tspan tags with text tags so QtSVG can work with them?

Not replace, but wrap. Each <text> tag does still need to contain a <tspan>. (If for no other reason than OpenShot's Title Editor looks for them, and not having them would break it.) QtSVG just can't _position_ text based on <TSPAN>s. Positioning is only supported on <TEXT> tags under SVG Tiny, so each <TSPAN> that repositions its contained text needs to be wrapped in its own <TEXT> tag with that same positioning.

So you'd want to take the chunks that contain:

<text>
  <tspan>Line 1</tspan>
  <tspan>Line 2</tspan>
<text>

And turn them into:

<text>
  <tspan>Line 1<tspan>
</text>
<text>
  <tspan>Line 2</tspan>
</text>

The only tricky bit is the position handling. Where you'll currently have (from the sample file you provided) e.g.:

<text style="textstuff" x="959.01288" y="544.8371">
  <tspan style="tspanstuff" x="959.01288" y="544.8371">Line 1</tspan>
  <tspan style="tspanstuff" x="959.01288" y="647.77881">Line 2</tspan>
</text>

You'll want to update that to:

<text style="textstuff" x="959.01288" y="544.8371">
  <tspan style="tspanstuff" x="959.01288" y="544.8371">Line 1</tspan>
</text>
<text style="textstuff" x="959.01288" y="647.77881">
  <tspan style="tspanstuff" x="959.01288" y="647.77881">Line 2</tspan>
</text>

(IOW, you'd want to steal the non-positional properties from the <TEXT> tag being duplicated, but the _positional_ properties from the <TSPAN> being enclosed.)

text-align:start/text-anchor:start vs. text-align:center/text-anchor:middle, same basic deal. You'd want to either _remove_ the text-align:start or text-anchor:start style attributes from any tag (at any level) that encloses something that _should_ be centered but isn't, or you'd want to replace them with text-align:center and text-anchor:middle, since those attributes aren't being respected from a different level. The latter is probably the more forceful approach, and therefore more likely to succeed in convincing all parsers, including QtSVG.

My guess is from 1.4.3 to 2.4.3 OpenShot devs made a major decision to shift to another less feature-rich svg renderer. Wonder what happened to the old svg engine.

Yeah, I don't know the 1.4.x code at all, so I'm not sure what exactly handled rendering in those versions. OpenShot 2.0 was a complete rewrite — there isn't a single line of code that _remains_ from the 1.x series, except for a few legacy class files preserved solely to handle importing and conversion of old 1.4.x project files.

In particular, 1.x was written entirely in Python, it used GTK for the interface and a Python library called MLT for most of the video lifting. Presumably either MLT or GTKPixbuf would've handled SVG rendering.

OpenShot 2.x uses Qt for the GUI and a lot of the media file management, and hands the rendering (and playback) of A/V content off to its own C library built on top of FFMpeg. Whatever renderer was used in the 1.x versions wouldn't be directly available to libopenshot. Whether it was MLT or GTK, neither is used in OpenShot 2.0, and neither provides a way to access just an SVG rendering functionality independent of the rest of the framework. Pulling in an entire codebase like that just for SVG support isn't practical. Especially since it would have to be part of libopenshot, not the OpenShot frontend.

QtSVG is unfortunately very limited by design (moreso than the devs probably realized initially), but it's also the only option Qt provides, and thus the only option that didn't require code to integrate it or add external dependencies to libopenshot. (The alternate renderer proposed here, ReSVG, is extremely capable. But as a rust library, it also adds _numerous_ dependencies, since rust is a highly modular language. And as I only just happened to notice, it's also not available for 32-bit Windows, which adds a further wrinkle.)

[mcbluefire]

Many thanks, I got them to work alright by commenting out the text tags, replacing tspan with text and fixing the text alignments.

for file in *.svg
do
sed -i 's/text-align:start/text-align:center/' $file
sed -i 's/text-anchor:start/text-anchor:middle/' $file

sed -r -i 's/(/' $file
sed -i 's/ sed -i 's/<\/text>//' $file

sed -i 's///' $file
sed -i 's/<\/tspan>/<\/text>/' $file
done

If anyone decides to use this please note the following:
Disclaimer - didn't add any logic to prevent running on a file more than once - doing so will definitely break it.
Backup your svg files before running this so you can just copy from backup and run again if anything goes wrong.

If I run into any issues I'll update to include tspan tags within each text tag. Thus far my most complicated multi-line file translated perfectly.

Thanks again for all your help - greatly appreciated.

[ferdnyc]

Many thanks, I got them to work alright by commenting out the text tags, replacing tspan with text and fixing the text alignments.

Excellent, glad it worked out. That should be fine, provided you don't need the ability to edit the titles in OpenShot's Title Editor interface. (If you were to load them into the Title Editor, you'd find that the TEXT tags without TSPAN children aren't detected. But I'm fairly sure that should be the only issue, and as I said it's only an issue if you actually _need_ them to be editable.)

If I run into any issues I'll update to include tspan tags within each text tag. Thus far my most complicated multi-line file translated perfectly.

*nod* That's all you'd need to do, at least for editability. The Title Editor expects a single <tspan> for every <text>, and it requires a style="" attribute on that <tspan> (because it parses and modifies the inline CSS within). But wrapping the content inside the <text>...</text> block with a simple <tspan style="">...</tspan> should suffice to re-enable interactive editing.

[huubvanniekerk]

Since my bug report #838 has been closed today in favour of this one, I should add that I'm still using version 1.4.3 because the also the latest version 2.4.3 can't handle my SVG title files properly. Also, I'm using Inkscape to create those SVG files. Apart from that, I don't know about QtSVG or SVG Tiny.
All I know is, that N3WWN confirmed the problem and a while later reported to have solved it but not released the fix into the next version of OpenShot. So now I'm not sure what to expect.

[ferdnyc]

All I know is, that N3WWN confirmed the problem and a while later reported to have solved it but not released the fix into the next version of OpenShot. So now I'm not sure what to expect.

Realistically, don't expect the current SVG support in OpenShot to change any time very soon. @N3WWN 's SVG modifications are OpenShot/libopenshot#143, and still listed as a work-in-progress PR that hasn't been merged into the library. That effort stalled some months ago while the changes were still in a preliminary state. (They were _big_ and complex, introducing an entirely new SVG rendering library to replace QtSVG, written in a relatively-new programming language called Rust which none of the rest of us have any experience with.) @N3WWN hasn't been active here for several months now, as he's been busy with other obligations.

So, that's what you should expect, realistically. I'm just trying to give you an honest picture of the situation. The ReSVG integration may be a long-term path to more capable SVG handling in OpenShot, but it's not going to solve anything in the immediate future.

Since my bug report #838 has been closed today in favour of this one, I should add that I'm still using version 1.4.3 because the also the latest version 2.4.3 can't handle my SVG title files properly. Also, I'm using Inkscape to create those SVG files. Apart from that, I don't know about QtSVG or SVG Tiny.

Depending what features you actually need to use in Inkscape, you may have _somewhat_ better luck saving your files out as Plain SVG in Inkscape. It's definitely not SVG Tiny, but the files might be slightly more palatable to QtSVG. ...Honestly, though, I'm doubtful it would really make much difference, as the compatibility all comes down to the use of certain features that aren't supported in SVG Tiny.

The single biggest one is filters: Any SVG file that uses a filter will cause problems for OpenShot, and many Inkscape SVG files do. By far the most common filter is Blur, because it's the standard way of creating things like drop-shadow, reflection, or glow effects: Take a grayscale copy of some elements of the drawing, apply a Blur effect to make them fuzzy and indistinct, darken them up, raise the transparency, and boom: Drop-shadow. Inkscape lets you do it in one click, without even knowing you're using a blur filter. But now the file won't render properly in OpenShot.

You say you're creating the titles in Inkscape, though — are you creating them _entirely_ in Inkscape, in their final form? Not as templates for the OpenShot Title Editor? Because, unless you're editing the titles in OpenShot itself, there's really no point in importing them as SVG at all. It sounds like you might be using Inkscape as your title editor, in which case SVG is only an intermediate file format that you're better off not bothering with.

See, the SVG support in OpenShot is actually a LOT less crucial than it seems, because the truth is there's a lot less to it than it might seem. In practical terms, it really does exist ONLY to enable the functionality of the built-in Title Editor. With SVG title files, you can edit the content in OpenShot. That's convenient. The price is that they have to be simple files that can be processed by QtSVG.

The very _first_ thing the OpenShot video renderer does, when it encounters an SVG file on the Timeline, is hand it to QtSVG to render as a PNG image, which is then passed to the video encoder. The encoder _never_ sees any SVG files, and it has absolutely no idea how to handle them. It only handles regular fixed-size image formats.

So, if all of your title editing is done in Inkscape, for import into OpenShot only in their final state, then you're much better off having _Inkscape_ generate the PNG image, and then importing THAT. Inkscape is the most capable SVG renderer available to you, and it can turn anything it can create into a perfect PNG representation.

TL;DR

Unless you're using the OpenShot Title Editor interactively, don't bother with OpenShot's SVG support. Instead of loading your titles as SVG files, have Inkscape export them as PNG files at the same resolution as your OpenShot project's output video, and then import those PNG files instead.

Not only will the rendering of the titles be far superior, but it'll be more efficient since the OpenShot previewer/exporter doesn't have to do the work of turning those SVG files into PNGs, which is _exactly_ what it would do anyway.

[DylanC]

@ferdnyc - I agree. I used to always do this with Inkscape anyway. I would work on a title and when I felt it was ready just export at a high resolution. Import the file as .png into Openshot and export the video with beautiful titles. 😆

[huubvanniekerk]

@ferdnyc My SVG title page is plain and simple: some text, made white and saved/exported to SVG. Not knowing how OpenShot handles stuff, reading your suggestion, I'll give it a try to export to .PNG and see how OpenShot works it out. I've noticed the OS Title Editor but never touched it.

[peanutbutterandcrackers]

While I agree with the svg to png solution for now, I, personally, kinda' like the idea of working with svgs themselves. The reason being, theoretically, I could export it to whatever resolution and it would still work great. In hindsight, if the theory is true, the meet-tux project should export neatly as a 4k video, as all it uses are svg files (and a couple of black-and-transparent overlay pngs).
However, while working with a few other svg files, I noticed that scale-ing it up in OpenShot didn't give me crisp, neat image but blurry ones. Which was most certainly strange. I was expecting to have the ability to zoom in infinitely onto an svg clip on the timeline without losing any image quality.

[ferdnyc]

While I agree with the svg to png solution for now, I, personally, kinda' like the idea of working with svgs themselves. The reason being, theoretically, I could export it to whatever resolution and it would still work great. In hindsight, if the theory is true, the meet-tux project should export neatly as a 4k video, as all it uses are svg files (and a couple of black-and-transparent overlay pngs).

But you _can't_, because the SVGs are converted to PNG — and at the dimensions defined in the SVG file (with no consideration for export dimensions). It just isn't implemented that way. If it was, that'd be one thing, but I can unequivocally state from having read the code that it is absolutely not. In fact, rendering the SVGs to PNG yourself DOES give you control over the output resolution, which is another reason it can produce _better_ results.

However, while working with a few other svg files, I noticed that scale-ing it up in OpenShot didn't give me crisp, neat image but blurry ones. Which was most certainly strange. I was expecting to have the ability to zoom in infinitely onto an svg clip on the timeline without losing any image quality.

Because you're rescaling a PNG export.

[peanutbutterandcrackers]

Perhaps with the switch to ReSVG in the future, we could hopefully implement it as such so that I can create a project once export multiple times, and also scale up an svg image infinitely, somehow? Seems like a neat feature to have...

[ferdnyc]

Perhaps with the switch to ReSVG in the future,

I think describing it that way is, at this point, not a realistic assessment of the situation. ReSVG is one _possible_ approach to better SVG support, but it is not in a state where it is definitively "in the future" for OpenShot. Partly due to the difficulty of integrating a library in a highly modular language like Rust (and its — 43?, I think I counted — dependencies) into the codebase, along with (as I mentioned above) the complete lack of availability for 32-bit Windows.

But an even bigger concern (and one I'd only caught on to fairly late in the discussions about the proposed patches), is that by adding ReSVG support only to _libopenshot_, the GUI is still forced to use QtSVG as its own SVG renderer. So things like the Title Editor previews still look corrupted, and now they _don't match_ the final exported output.

Using ReSVG as the SVG rendering implementation for export means that, in order to have the rest of the interface match that output, we'd have to either find or build an _additional_ implementation for the OpenShot Python code. Either that, or turn libopenshot itself into a ReSVG-based SVG renderer (except on systems where ReSVG isn't available, and then it would have to fall back either to QtSVG or a _third_ renderer), with the Python code making requests to libopenshot instead of QtSVG everywhere it needs to display an SVG in the interface (Title Editor, timeline thumbnail, Media Files thumbnails, etc..).

we could hopefully implement it as such so that I can create a project once export multiple times, and also scale up an svg image infinitely, somehow? Seems like a neat feature to have...

It would be an awesome feature to have.

It's not something that ReSVG would make any easier to support. In fact, it would probably make it even harder to implement, since none of us write Rust code. (Heck, I tried to _read_ some of it and my eyes bled a little. This is not the most penetrable syntax, and I read Perl:)

type LayerData<T> = Rc<RefCell<T>>;
pub struct Layers<T> {
    d: Vec<LayerData<T>>,
    counter: Rc<()>,
    img_size: ScreenSize,
    dpi: f64,
    new_img_fn: Box<Fn(ScreenSize, f64) -> Option<T>>,
    clear_img_fn: Box<Fn(&mut T)>,
}

[peanutbutterandcrackers]

Oh, now that you point that out, I kinda' understand the situation a bit more clearly. Thank you for your always so in-depth explanations (you would so totally be a great tech-youtuber if you wanted to do that on the side; I'd subscribe for sure :smile: )

[huubvanniekerk]

Now that I've used OpenShot 2.4.3 with .PNG, a kind of review. The 1st video I created went fast and good. The 2nd video is a different story. About the same length, same PNG, but takes like forever. After 34.6%, there's 2:59:10 Remaining (and counting...), at 2.84 FPS (down from over 11 FPS). I run this on an 8 core i7 @ 2.6 GHz Fedora28 machine. In comparison, I created the same video with the SVG using Openshot 1.4.3 on a 1 core P6200 @ 2.13 GHz Mint 7.2 machine. I started this MUCH later and it was finished when the i7 was at 34.6%.
So I'm curious about what possibly goes wrong here somewhere/somehow.

[ferdnyc]

(you would so totally be a great tech-youtuber if you wanted to do that on the side; I'd subscribe for sure )

Ew, nobody needs to see that. I try not to even allow _photographic_ evidence of my existence, I'm certainly not going to start putting myself on video. The world already has reality TV if it wants to watch bullshit people doing their bullshit, and the ones on TV are far more attractive than this whole mess here.

@huubvanniekerk

So I'm curious about what possibly goes wrong here somewhere/somehow.

It's hard to say without a _lot_ more information, but... a couple of guesses/theories.

You say this is the second video you created with OpenShot 2.4.3, and the first one performed well. HOW exactly did you transition from working on the first video, to working on the second video? Did you start a whole new project file? Load a saved one? Delete the clips from the first video off the Timeline and start placing clips for the second video?

OpenShot currently has a large problem with session data buildup, both within an editing session _and_ inside project files, where the session history is stored on save. Anything that involved _continuing_ an older session, rather than starting fresh (ideally by completely quitting OpenShot, then reopening it and starting to build a new project from the initial empty state) might have caused your session to accumulate history data that's got it bogged down.

One good clue would be the size of your project file for the current project when you save it. If it's _huge_ (we've had reports in the tens of megabytes, for a file that should be a few hundred KB at most), then that's a good sign you're going to have problems.

[huubvanniekerk]

Ok, yes, then that's the explanation of what happened. For the next video will make sure that it's a fresh session and see what happens.

[ferdnyc]

Ok, yes, then that's the explanation of what happened. For the next video will make sure that it's a fresh session and see what happens.

Please do let us know.

(Devs: If #2400 merges, we'll at least be able to advise users encountering these performance issues that all they have to do in order to return OpenShot to normal operation is save their work, restart the program, and load the saved project file back in.)

[huubvanniekerk]

Ok, here's review 2.

First, I removed all but the title PNG from the existing project, saved it, restarted OpenShot and let it work. Found that it again was 37% and 1:30:xx remaining, down to 2 FPS. Cancelled it and started completely from scratch. So, new project, imported the title PNG, then added the ogg's and mov's for the video. Watched it initially go nice with 0:30 time remaining, but this soon went up. After I let this go for quite a while, I again started the old laptop with OpenShot 1 and started editing. This one was finished when OpenShot 2 at the 8 core showed 41.3%, 1:43:22 remaining at 3:40 FPS. I cancelled it.
So I'm afraid that starting from scratch wasn't a solution either, in my case.

[ferdnyc]

@huubvanniekerk :

That's helpful, thanks. (Though, not very helpful to you, unfortunately.)

Is there any way you'd be able to provide the project file and media for that project to us? (I don't know how sensitive the content is, obviously if it's something you can't share, that's totally understandable.) I'd just like to get an idea of the complexity and structure, and see whether I see the same issues. (I assume the answer is yes.)

If you can't share the media, just the project file itself would be helpful, as it contains all the information we'd need _about_ the media files in use, structurally.

[huubvanniekerk]

@ferdnyc What I noticed, is that (different from OpenShot 1), the .osp file is automatically changed and saved during editing. So even without actively saving changes and with cancellation of the editing process, the .osp file keeps all data added for the video. Can this be changed in preferences?
Please find attached the .zip of the project .osp file. The .osp extension appeared not to be supported for attachment.
intro_png.osp.zip

[ferdnyc]

@huubvanniekerk :

What I noticed, is that (different from OpenShot 1), the .osp file is automatically changed and saved during editing. So even without actively saving changes and with cancellation of the editing process, the .osp file keeps all data added for the video. Can this be changed in preferences?

_Somewhat_, yes. In the Preferences tab "Autosave", you can turn off... well... autosave, and that'll keep OpenShot from writing to the file on its own. However, at this time it'll still store your session history in the file when you _manually_ save — PR #2400 proposes to eliminate history from the project files for the time being, but isn't yet merged into the code.

The other thing you can do is _lower_ the History Limit (in that same Preferences tab) from the default value of 20, which will cause it to save less history in the project file — but you'll also have less of a history buffer during your session, too. (Realistically, though, it's almost never useful to undo more than 5 or 6 steps. But if you ever use the "Slice: Keep Both Sides" feature to split clips, it's currently a quirk of how it interacts with the history that each use creates _three_ history steps. So, it's worth taking that into account as well.)

Please find attached the .zip of the project .osp file. The .osp extension appeared not to be supported for attachment.

Yeah, it's not, that's a GitHub thing. .zip is perfect, I'll take a look tonight.

[ferdnyc]

Please find attached the .zip of the project .osp file. The .osp extension appeared not to be supported for attachment.

One thing I did notice with this is that, while all of the audio files are 48kHz, the project sample rate was set to 44.1kHz. So, the audio would all end up being resampled on export, which can definitely be a source of slowness (especially with vorbis audio, as it's not the fastest codec to process).

Here's a copy of the project file with the history removed (though it was very small, really), and the sample rate changed to 48000 to match the media files in the project. I'm curious whether exporting might go any faster like this?

intro_png.zip

[huubvanniekerk]

I'm not quite sure what's changed in this .osp file, but I'm getting loads of messages about each of the png files: "is not a valid video, audio or image file". 5 of them are blank, i.e. showing no content. And each time when I try to do something (e.g. remove) with any of them, the message returns for each. In the end, after finally removing everything from the timeline and project list, I try to load and insert them again with some of the files giving the same series of messages again, ending with those files not being loaded into OS at all.

[shoogle]

@ferdnyc said:

Instead of loading your titles as SVG files, have Inkscape export them as PNG files at the same resolution as your OpenShot project's output video, and then import those PNG files instead.

Agreed. The SVG specification is a large moving target which OpenShot will never be able to keep up with, so rendering is best left to a dedicated program, and ideally it would be the program you used to create the SVG in the first place.

@peanutbutterandcrackers said:

I, personally, kinda' like the idea of working with svgs themselves. The reason being, theoretically, I could export it to whatever resolution and it would still work great.

The solution to this is to allow SVGs to be imported, but then for __OpenShot to call Inkscape for you__ (if it is installed) to generate a PNG for display. New PNGs would be generated (and possibly cached) each time the user resizes an imported SVG or changes the video export resolution.

[peanutbutterandcrackers]

@ferdnyc - Does the method suggested by @shoogle eliminate the need for an external library like resvg? if user_has_inkscape: svg_renderer = inkscape else: svg_renderer = qtsvg?

[ferdnyc]

@peanutbutterandcrackers

@ferdnyc - Does the method suggested by @shoogle eliminate the need for an external library like resvg? if user_has_inkscape: svg_renderer = inkscape else: svg_renderer = qtsvg?

It's a possibility. Inkscape does take command-line arguments to batch process files, and inkscape -z -f $SVG_FILE -e $PNG_FILE will (according to the inkscape --help output) convert $SVG_FILE into $PNG_FILE without opening the interface. Inkscape is a _heavy_ application, even without its GUI, so how well this would perform is questionable — but really it's no different than the way Blender is currently used.

@shoogle

Agreed. The SVG specification is a large moving target which OpenShot will never be able to keep up with, so rendering is best left to a dedicated program, and ideally it would be the program you used to create the SVG in the first place.

That's not really the issue — the SVG support in Qt is actually based on a very well-defined and static spec. The problem is that the spec in question is SVG Tiny, because it's lightweight and QtSVG was mostly meant for icon rendering, including on mobile devices. _Inkscape_ has no support for constraining itself to the features of SVG Tiny — so it's impossible to reliably write out SVG files from Inkscape that will be guaranteed compatible with QtSVG, even if you wanted to.

Anyway, that's my final summary on this issue, best of luck with it.

[shoogle]

Qt uses SVG Tiny because the main SVG specification is a large moving target that they have no intention of keeping up with. Inkscape is heavy because they are trying to keep up with the specification (and because it uses GTK+).

Performance shouldn't be a problem providing it is implemented correctly. Ideally PNG generation would be done in the background and on a different thread to OpenShot, with some kind of placeholder box displayed until the PNG was ready (or QtSVG used to render a placeholder / a previous cached version displayed). Each SVG to PNG conversion will take around 1 second, which is nothing compared to importing a video, but would start to add up if the user imports hundreds of SVGs.

[peanutbutterandcrackers]

Everyone,

OpenShot now builds (optionally) with resvg. Currently, all the installers (and AppImages) from the website have resvg as the renderer. The PPAs however, do not.

If anyone wants to build libopenshot with resvg support, here is a script to install resvg and here is how one would compile libopenshot.

Hope that helps.

All we need now is for the distros to start packaging resvg.

Closing for now.

Thank you all for your help and insights into this issue. You guys are all awesome!

[huubvanniekerk]

The only improvement for me is that with the daily build of 2019-01-20 the svg handling is solved. What is NOT solved is the processing of the video from scratch: after 30 minutes, it showed a progress of 22.2% and 2:39:07 remaining time. I cancelled it, again.

[peanutbutterandcrackers]

huubvanniekerk - Could you please attach the logs here so that we can see what is causing the slowness? Your system specs too, and any other relevant information would be of great assistance.

[huubvanniekerk]

openshot-qt.log
libopenshot.log
Specs: 8 core, Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz, 16 GB RAM. Fedora Linux 28

[huubvanniekerk]

Since the latest nightly-build, I can use OS quite nicely. It finishes in reasonable time without issues.

[ferdnyc]

@huubvanniekerk That's great to hear!

The 2.4.4 release should be making it to rpmfusion some time very soon, as well, if you're interested in installing it that way. If you've updated to Fedora 29, there's a build going into -testing that I expect will be available in rpmfusion-free-updates by the end of the week. If you're still using Fedora 28, we hit a snag with the build servers so 2.4.4 will be delayed a few more days there.

[huubvanniekerk]

@ferdnyc After upgrading to Fedora 29 the other day, I installed 2.4.4 via rpm. Unfortunately, the first attempt in using it became a disappointment: it doesn't handle the SVG files properly. Since the 2.4.4 app from the website works fine, I keep using that version.

[ferdnyc]

@huubvanniekerk Yeah, unfortunately the ReSVG support in the AppImage isn't included in the RPM Fusion build. I'd _like_ it to be, but there are a large number of Rust language prerequisites that aren't yet satisfied in Fedora. (Though I should check how much that situation has changed in F30 / new-Rawhide.)

You aren't seeing the same color issues reported in #2697, with the AppImage?

[huubvanniekerk]

@ferdnyc I'm not using the title editor, so I can't confirm any colour issue with the AppImage.

[ferdnyc]

@huubvanniekerk That shouldn't matter, I don't believe it's related to the title editor.

Could you add this SVG file (removing the .txt extension) into an OpenShot project, and let me know whether the text renders blue (correct) or orange (inverted)?

TitleFileName-1.svg.txt

[huubvanniekerk]

@ferdnyc After importing it into the AppImage of 2.4.4, the big R renders blue, the rest of the text renders, orange/red. Same result after exporting it to a 1 second Youtube video.

[ferdnyc]

@huubvanniekerk Interesting! As you can see, for me running the 2.4.4 release AppImage, _everything_ is orange, including the large R. I wonder why that would be different?

...But, real point is, all of that orange text is _supposed_ to be blue. There's definitely some sort of issue with color inversion in the AppImage's SVG support. Not sure yet whether it's on the ReSVG side or in the libopenshot QtImageReader code. (Hm. I should probably try the 2.4.4 Windows release build, as I believe that also includes ReSVG.)

[huubvanniekerk]

@ferdnyc Now that you mention this... I do have a colour inversion with SVG, and that also occurred when I was still using version 1. I use svg files that have white text on white. After importing, they are white text on black. So, when I create them, I have a white sheet and have to make the letters white as well to have them appear as white text on black. I will try to create black text on white, since that reads easier, but will have to see how that works out. Btw, I use Inkscape to create my SVG files.

[ferdnyc]

@huubvanniekerk That _may_ be a function of how you're creating the files. By default, Inkscape doesn't include the "page" background of a file in the SVG output, since SVG files natively support transparency. So, if you're creating white letters over a blank page in Inkscape, what you're really creating is white text on a transparent background.

Because OpenShot is a video editor, its default background is a black field rather than a white page, so the letters will show up white-on-black. (Though, if you were to place them in front of another image or video, you'd be able to see that content behind the white lettering.)

If you wanted to create actual white text on a white background (or any color background) in Inkscape, you need to also create a filled rectangle containing the background, then place the text in front of that.

For reasons I've never fully understood, the option to show a standard "checkered background" transparency hint is a _document property_ rather than a preference, in Inkscape. But to get a clearer picture of how the output will render, you can turn it on for an individual Inkscape project by checking the "Checkerboard background" option under "Background" on the "Page" tab of the File > Document Properties... window.