On this document http://qt-project.org/doc/qt-5/svgrendering.html you can read "Qt supports the static features of SVG 1.2 Tiny. ECMA scripts and DOM manipulation are currently not supported." That means that several SVG features like text on paths are not rendered by Qt based applications. On several Qt bug reports like this one https://bugreports.qt-project.org/browse/QTBUG-12588 (closed as "out of scope") is recommended to use webkit when rendering complex SVG files. Maybe Gwenview needs to switch to webkit or blink when rendering SVG files. Reproducible: Always I do not see a way to attach a sample SVG file now, so I'll attach one on the comments. That file opens without a problem on rekonq, inkscape, chromium and OpenOffice, but display several problems on Gwenview and karbon14, like missing text, lines that should be invisible are displayed, etc.
Created attachment 87279 [details] Sample SVG with complet layout The attached SVG file opens fine on webkit based applications like rekonq and on other applications like inkscape or OpenOffice is displayed without errors too, but shows several problems on Gwenview and karbon14 due to non complete SVG support.
*** Bug 307331 has been marked as a duplicate of this bug. ***
*** Bug 353085 has been marked as a duplicate of this bug. ***
*** Bug 359550 has been marked as a duplicate of this bug. ***
*** Bug 364534 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
*** Bug 405660 has been marked as a duplicate of this bug. ***
Created attachment 124338 [details] Gwenview renedering issue of a SVG. I guess I experience the same bug(s). KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.13.2
Created attachment 124339 [details] Sample file of the above post.
*** Bug 417815 has been marked as a duplicate of this bug. ***
And more than 10 years after, the same bug persist... Is there any plan so that KDE's default image viewer can properly render SVG images in 2020? OS: Gentoo Kernel: x86_64 Linux 5.4.72-gentoo DE: KDE 5.74.0 / Plasma 5.19.5 WM: KWin kde-apps/gwenview-20.08.3:5::gentoo USE="X activities handbook kipi mpris semantic-desktop -debug -fits -raw -share -test"
*** Bug 432330 has been marked as a duplicate of this bug. ***
(In reply to ebray187 from comment #11) > And more than 10 years after, the same bug persist... Is there any plan so > that KDE's default image viewer can properly render SVG images in 2020? > > OS: Gentoo > Kernel: x86_64 Linux 5.4.72-gentoo > DE: KDE 5.74.0 / Plasma 5.19.5 > WM: KWin > > kde-apps/gwenview-20.08.3:5::gentoo USE="X activities handbook kipi mpris > semantic-desktop -debug -fits -raw -share -test" I'm gonna take a shot at switching over to Qt WebEngine (based on Chromium/Blink). I'm still getting acquainted with Gwenview's code base so I can't make any promises but I'm definitely going to give it a try.
No need to look at Gwenview's source, check kimageformats/qimageformats instead. These have code to load a file into a QImage.
(In reply to Christoph Feck from comment #14) > No need to look at Gwenview's source, check kimageformats/qimageformats > instead. These have code to load a file into a QImage. I'll have a look at it. Thanks a ton.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/41
Is this still assigned? Is the solution to switch to webkit or blink still considered to be the best choice after the discussion at https://invent.kde.org/graphics/gwenview/-/merge_requests/41 ? Are there any smaller alternative libraries which could be used and are easier to maintain?
*** Bug 270838 has been marked as a duplicate of this bug. ***
*** Bug 423655 has been marked as a duplicate of this bug. ***
(In reply to postix from comment #17) > Is this still assigned? > Is the solution to switch to webkit or blink still considered to be the best > choice after the discussion at > https://invent.kde.org/graphics/gwenview/-/merge_requests/41 ? > Are there any smaller alternative libraries which could be used and are > easier to maintain? just FYI: there are librsvg and cairo, and we can try piggybacking on CLI inkscape - with a fallback.
*** Bug 448110 has been marked as a duplicate of this bug. ***
*** Bug 451554 has been marked as a duplicate of this bug. ***
Created attachment 157447 [details] SVG file produced by LibreOffice Draw For now, even SVG files produced by LibreOffice Draw (7.5) cannot be viewed correctly with Gwenview while LibreOffice Writer, Firefox, Scribus and Inkscape show them perfectly.
Will KSVG be a valid alternative library to properly draw fullscreen pictures, or can it only display icons? Will KSVG support e.g. SVG 2 features in development since 2018 (or anything newer than 1.2 tiny from 2008)? Is version 1.0 production ready and suitable for inclusion in Gwenview? https://invent.kde.org/frameworks/ksvg https://www.w3.org/TR/SVG2/ https://www.w3.org/TR/SVGTiny12/
No, because KSvg sits on top of the Qt SVG renderer, which is what suffers from this problem. The solutions are: 1. Improve the Qt SVG renderer 2. Use different SVG renderer
*** Bug 478505 has been marked as a duplicate of this bug. ***
Qt 6.7 has improved SVG rendering by adding support for elements that go beyond the SVG Tiny spec, see https://www.qt.io/blog/qt-svg-not-so-1.2-tiny-any-more
As discussed in bug 448234, Qt 6.7 unfortunately does not address all (or even most?) of the problematic SVGs people have encountered, and even in this bug report Gwenview still has trouble rendering the SVGs in comment 1 (the graph lines end up going outside of the box) and comment 27 (the text in the diagram is missing). Although at least Qt is no longer against going beyond the Tiny spec at all now, so hopefully future Qt releases will have more of an impact.
Indeed, QtSvg just got support for Gaussian blurs for 6.8: https://bugreports.qt.io/browse/QTBUG-123138 That plus clipping paths should make a big difference.
*** Bug 487398 has been marked as a duplicate of this bug. ***
So I think it's time to close this as RESOLVED UPSTREAM. The Qt folks have put work into improving their SVG renderer, with some improvements landing in 6.7, and others in 6.8, with still more to come. So far no feasible alternative to waiting for these fixes has emerged. That makes it, in all practicality, purely an upstream issue, and thankfully our upstream appears to be working to address it.