Rendering errors in QtSvgRenderer due to changed SVG output in Inkscape 0.47

[Sean]

Saving a vector image as svgz breaks the rendering of it with Qsvg. Some basic vector graphics seem to not get affected.

The svgz file doesn't render the objects when viewing in KDE applications, i.e the theme is not rendered correctly inside KDE Games themes or when viewed in Gwenview. I'm assuming this exposes a bug in Qt?

Version Inkscape 0.47pre4 r22446

Distros Kubuntu are shipping these pre builds, which if you use KDE4/Qt4.5, makes it practically useless(KDE4 uses svgz for various plasma/KDE Games themes).

How to reproduce the bug.

Open a svgz file in Inkscape. here is a example http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/carddecks/svg-ancient-egyptians/Ancient_Egyptians.svgz

Save the file as a svgz.

Then open the file in Gwenview.

You'll notice that it is not rendered properly and various objects or letters/numbers are missing or corrupt.
I attach a screenshot of the rendering issue with that svgz file.

[su_v (suv-lp)]

- Did you report it upstream to Gwenview/Qsvg/KDE4/Qt4.5 (?) if it is a known issue?
- Do *.svgz files saved with older Inkscape versions lead to the same rendering errors in Gwenview?

[Sean (suseux)]

It's not Gwenview, it's the Qsvg renderer which all KDE applications use to render the SVG's.

Inkscape 0.46 saves the svgz fine and it renders properly. Inkscape 0.47 pre seems to make the svgz not render properly with Qt's svg renderer.

[Sean (suseux)]

Sorry, it's not just svgz, it's all SVG file formats too.

[su_v (suv-lp)]

Then I doubt that it is an Inkscape issue. Does Batik render the files saved with Inkscape correctly (apart from 'Flowed Text')?

'Ancient_Egyptians.svgz' downloaded from above link doesn't open here in both Inkscape 0.46-2 and current Inkscape 0.46+devel r22531. Batik 1.7 gives an error (SVG Error: Content is not allowed in prolog.) and doesn't load it either (all tested on OS X 10.5.8).

[su_v (suv-lp)]

console message of inkscape:

** (inkscape-bin:93575): WARNING **: SVGView: error loading document '/Volumes/blue/img/Inkscape/test/bug/458388-Ancient_Egyptians.svgz'

/Volumes/blue/img/Inkscape/test/bug/458388-Ancient_Egyptians.svgz:1: parser error : Start tag expected, '<' not found
 �
^

(I used the <download> link of Revision 977313 and saved the file directly to the hard-disk. Browser is Firefox 3.5.3)

[Sean (suseux)]

No. The Ancient Egyptian.svgz should work in 0.46 because I did it in that version and it's made to render properly for inside KPatience (KDE4 game). That file is the perfect test case for this issue.

The other examples don't render proper either, for various reasons(having blur in them which qsvg doesn't support and is not the issue).

I'm thinking you trigged a bug with Qsvg/Qt in your 0.47 pre builds.

[su_v (suv-lp)]

log entry of Revision 977313: «optimizegraphics: Losslessly optimized PNG and SVGZ files with "optipng -o5" and "advdef -z -4".
Reduced disk space: 3180KB (3MB)»

I don't know what happened to that file in the repository, but it doesn't open in any Inkscape version here.

[su_v (suv-lp)]

Could you test the attached sample file: SVGZ saved with Inkscape 0.46+devel r22531 (built from current SVN) on OS X 10.5.8

[Sean (suseux)]

I just opened it directory from that link on the download text. It works and opens just fine in this Inkscape 0.47 re build.

Try this one http://websvn.kde.org/branches/KDE/4.3/kdegames/libkdegames/carddecks/svg-jolly-royal/jolly-royal.svgz

[Sean (suseux)]

The yin+yang.svgz renders just fine after saving it as a svgz from Version Inkscape 0.47pre4 r22446.

It's hard to pin this down. I tried one of the other card decks(oxygen-white) and some of the fonts are not showing or render wrong, after I saved as a svgz from Inkscape 0.47pre4 r22446.

[su_v (suv-lp)]

'jolly-royal.svgz' (Revision 986143) fails to open in both Inkscape 0.46-2 and Inkscape 0.46+devel r22531 on OS X 10.5.8. Doesn't open in Batik 1.7 with the same SVG error as 'Ancient_Egyptians.svgz'.

[Sean (suseux)]

Can't somebody test this? I don't understand why those svg files are not opening in your inkscape, since they were design in Inkscape.

[jazzynico (jazzynico)]

jolly-royal.svgz from your link is zipped twice! It should be renamed jolly-royal.svgzz :)
Attached is a fixed file, which opens correctly in inkscape 0.47 rev 22536 and 0.46.

[su_v (suv-lp)]

Thanks for the tip, JazzyNico! Both 'jolly-royal.svg' and 'Ancient Egyptian.svg' open without error in Inkscape 0.46+devel r22531 after gunzipping them twice ;-) and don't show any obvious rendering errors like missing fonts or paths on OS X 10.5.8.

[Sean (suseux)]

Did you save them as a svgz and view those svgz's in Gwenview?

[su_v (suv-lp)]

I'm on OS X - no KDE or Gweniew here. 'Ancient Egyptian.svg' saved as *.svgz with Inkscape r22531 is not twice gzip'ed (as my previous attached example wasn't either) and opens without error in Batik 1.7.

Any KDE user following this report and willing to test?

[Sean (suseux)]

Well yes, it will render correctly :p I'm suggesting that it exposes a Qt bug in those Inkscape pre builds, so you trigger it somehow during the 0.47 development.

I just can't believe you're trying to reproduce the bug without KDE or Gwenview. :/

[jazzynico (jazzynico)]

Ok, I've tried with Gwenview (though I use Gnome...), and it doesn't want to open svgz files (error message).
I've also tried with a version a this file saved as Inkscape SVG, and I see nothing wrong in Gwenview (except that I can't see half of the first row in normal view, but it works in full screen and I don't think it's related to your problem).

[su_v (suv-lp)]

related KDE bug reports (there might be others and I didn't search for Qt reports):

Bug 206753 – Qt cannot render some of the icons correctly in .svgz format: <http://bugs.kde.org/show_bug.cgi?id=206753>
«It will get a bit better with Qt 4.6, but clipping and filters (such as blur for shadows), are not supported in Qt's SVG implementation. It is recommended to use the (Inkscape-generated) PNG icons.»
Bug 201914 – Svg elements displayed incorrectly after editing in Inkscape 0.47 (unstable).: <http://bugs.kde.org/show_bug.cgi?id=201914>
«we rely on Qt for all SVG parsing and presentation. Inkscape may indeed now be exporting SVG that Qt's QSvgRenderer can not render. please report it upstream to Qt, however, as that is where the code (and the developers for it) are.»

(In the file 'Ancient Egyptian.svg' there are for example 8 objects - in the faces of the Kings - that have filters applied.)

[su_v (suv-lp)]

Looking at your screenshot I noticed that all missing objects are straight line path segments. There have indeed been changes how Inkscape writes its path data in an optimized way: <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Optimized_path_data>:

a) without repeated operators: A simple rhomboid exports
in 0.46 as:
  <path
     d="M 50,155 L 95,80 L 50,5 L 5,80 L 50,155 z"
     id="path2385"
     style="…" />
in 0.47 as:
  <path
     d="M 50,155 95,80 50,5 5,80 50,155 z"
     id="path2822"
     style=""…" />

b) relative coordinates: one of the original diamond shapes in 'Ancient_Egyptian.svg'
in 0.46 as:
      <path
         d="M -68.285567,108.34311 L -87.426619,80.405358 L -74.282869,64.421185 L -55.411669,90.473109 L -68.285567,108.34311 z"
         id="path6808"
         style="…" />
in 0.47 as:
      <path
         d="m -68.285567,108.34311 -19.141052,-27.937752 13.14375,-15.984173 18.8712,26.051924 -12.873898,17.870001 z"
         id="path6808"
         style="…">

Besides possible issues with filters - maybe this is a path notation that Qsvg doesn't yet support? You could test to change the SVG output format (allowrelativecoordinates to OFF, forcerepeatcommands to ON) as described in the release notes to see if it makes a difference. (SVG Specification on Path data: <http://www.w3.org/TR/SVG11/paths.html#PathData>)

Other than that the only real difference I see is the used SVG Version:
in 0.46:
  <svg … version="1.0" …>
in 0.47:
  <svg … version="1.1" …>

The file 'Ancient Egyptian.svg' I downloaded from the repository was clearly saved with 0.46 (that's what I didn't realize before) as it has all path data written in the old M … L … notation for straight lines. If I save it with 0.47pre4 as 'Plain SVG' the path data is rewritten in the new optimized way using relative coordinates and/or omitted repeated commands.

Could anyone with KDE and an SVG viewer based on Qsvg (KDE4/Qt4.5) test if saving the files with Inkscape 0.47pre4 - after changing the SVG output options (as described in the release notes) - as "Plain SVG" or "Compressed Plain SVG" prevents this rendering error in Qsvg?

[su_v (suv-lp)]

correction: I was wrong about the SVG version: obviously Inkscape 0.47pre4 writes the same version number (1.0) of the opened 0.46 file into the newly saved 'Plain SVG' file. New drawings however are saved with <svg version="1.1" …>.

[Sean (suseux)]

The files are done to work perfectly with the Qsvg, since they need to render properly with our KDE games. I know exactly how to design themes in Inkscape so they render properly(We can't use features such as masks and blur).

It seems as you've stated that Inkscape has changed the way it renders objects(which is what I suspected or exposes a bug in Qsvg).

Yes the objects still render wrong using plain SVG and Compressed Plain SVG.

[su_v (suv-lp)]

I haven't 'stated' - I was investigating your initial question what changes in Inkscape 0.47pre4 could trigger a rendering bug in Qsvg. Therefore I compared the SVG output (in the file, not the rendering in Inkscape on-canvas) of the two versions and quoted the Release notes 0.47 to explain one major difference. The path data that Inkscape 0.47 outputs is in accordance with the SVG specifications.

Obviously this change in path data writing is not what triggers the Qsvg bug. Thank you for testing it anyway.

[su_v (suv-lp)]

Related Inkscape question: "SVG edited with 0.47 isn't rendered correctly by QT 4.5.2", solved with 'Force Repeat Commands'.
<https://answers.launchpad.net/inkscape/+question/78561>

[Sean (suseux)]

Ahhh, thanks. That's one of the guys that designs Plasma themes and has picked up on it too.

[su_v (suv-lp)]

Could you report back if you have any more insight into what triggers the 'QtSvg' bug? Maybe this report could be changed into an RFE for Inkscape to support the Mobile SVG Profiles (SVG Basic and SVG Tiny) as 'Save/Export' format or as options to 'Plain SVG'.

related links:
Qt 4.5: QtSvg Module: Detailed Description: SVG Support
<http://pepper.troll.no/s60prereleases/doc/qtsvg.html#details>
static features of SVG 1.2 Tiny
<http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static>

[fabfedo (fabfedo)]

This bug seems to be fixed in Qt 4.6 :
http://bugreports.qt.nokia.com/browse/QTBUG-6321

[su_v (suv-lp)]

@fabfedo - thank you for the link to the qt bug tracker.

Can someone with Qt4.6 confirm that the cards files <http://websvn.kde.org/trunk/KDE/kdegames/libkdegames/carddecks/svg-ancient-egyptians/Ancient_Egyptians.svgz> (see Bug Description) or <http://websvn.kde.org/branches/KDE/4.3/kdegames/libkdegames/carddecks/svg-jolly-royal/jolly-royal.svgz> render without errors in Qt4.6 (e.g. with Gwenview)?

[Jon A. Cruz (jon-joncruz)]

Can someone check if we are looking at the wrong problem?

A .svgz file should be just a .svg file that has been gzipped.

What happens if the user with the problem saves it as just "Inkscape SVG" named *.svg? Does that file load and display properly in Qsvg?

After a .svg file has been seen to work for Qsvg, run it through gzip and, if needed, rename it from *.svg.gz to be *.svgz. Does that file present the same problem in Qsvg as saving directly as .svgz from inside of Inkscape?

[su_v (suv-lp)]

incorrect summary: issue is optimized path data. Files saved in Inkscape 0.47 are incorrectly rendered in QtSvgRenderer of KDE 4.5 (straight line segments are omitted).
unconfirmed workaround: 'Force Repeat Commands'

[su_v (suv-lp)]

… please see comment #4 by the bug reporter: “Sorry, it's not just svgz, it's all SVG file formats too.“
I should have changed the summary at the point, sorry.

[su_v (suv-lp)]

Closing as 'Invalid' because the reported issue is not a bug in Inkscape. Please feel free to reopen if you think this was done in error.