Created attachment 145311 [details] screenshot showing the issue in the search plasmoid SUMMARY This is a very general bug that results from KDE's use of Qt to render SVGs. Qt does not support the full SVG spec, and requests for Qt to support additional features of SVG have been denied in the past. See https://doc.qt.io/qt-5/svgrendering.html and https://bugreports.qt.io/browse/QTBUG-12588 for more on this. What this means is that KDE cannot rely on Qt's image handling functionality for SVG rendering - at all. Any place where a third party SVG is loaded by KDE might end up displaying a broken rendering to the user. Gwenview is most obvious case of a KDE application affected by this bug. There is a confirmed report for moving Gwenview to a different renderer: https://bugs.kde.org/show_bug.cgi?id=336436 There is also a report for incorrect rendering in the thumbnailer, which also relies on Qt: https://bugs.kde.org/show_bug.cgi?id=330585 I am reporting this against plasmashell (1) because there are cases where plasmashell specifically is affected and (2) to raise awareness of the fact that Qt's lack of support for SVG is a general problem affecting the KDE code base. Sample broken SVG image: https://gitlab.gnome.org/GNOME/eog/-/blob/master/data/icons/scalable/apps/org.gnome.eog.svg STEPS TO REPRODUCE 1. Use an icon theme with a broken SVG icon. (If you have EOG installed, any icon theme that doesn't replace its default icon will show the problem.) 2. Interact with the application in various Plasma tools (for example, in krunner, the search plasmoid, right click menu, or elsewhere) 3. Observe whether the icon is correctly rendered. (Compare to Inkscape or Firefox, which aren't affected by this bug.) OBSERVED RESULT Broken icon. Screenshot attached. EXPECTED RESULT Not broken icon. The preview image shown in Firefox looks correct to me: https://gitlab.gnome.org/GNOME/eog/-/blob/master/data/icons/scalable/apps/org.gnome.eog.svg SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 (5.15.13-arch1-1) KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION As a way of verifying that this is a Qt problem, the following trivial program shows the issue: from PyQt5.QtGui import QPixmap from PyQt5.QtWidgets import QApplication, QMessageBox, QLabel app = QApplication([]) msg = QMessageBox() pixmap = QPixmap("/usr/share/icons/hicolor/scalable/apps/org.gnome.eog.svg") label = QLabel() label.setPixmap(pixmap) msg.layout().addWidget(label) msg.exec_()
There was an effort to port to librsvg a while back, but it didn't go anywhere. CCing some people who might remember the details.
The effort to use RSVG for icons instead of Qt SVG was mostly blocked by a) it would introduce a Rust dependency into KDE frameworks, which nobody wants, and b) refactoring stuff so that the Rust dependency wouldn't be in frameworks but elsewhere would be a large amount of pain.
*** Bug 450971 has been marked as a duplicate of this bug. ***
*** Bug 451598 has been marked as a duplicate of this bug. ***
>This is a very general bug that results from KDE's use of Qt to render SVGs Bug reports should be about the actual bug, not proposing workarounds.
David, please don't close a Bugzilla ticket just because it proposes a solution. The issue itself is quite clearly explained in the description, and is absolutely a valid issue. In case the issue is not clear enough, I will paraphrase: The Qt SVG renderer is only guaranteed to correctly render SVGs that adhere to the TinySVG spec. However, many SVGs made by non-KDE people don't adhere to the limitations of the TinySVG spec, because that limitation doesn't apply to the software they regularly use. As a result, these SVGs look broken in Plasma. So there is a fundamental mismatch between what the library supports, and what people who make SVGs outside of KDE expect. I'm not sure what else we *could* do besides switching to another renderer, but if you have any ideas, I'm all ears.
*** Bug 456083 has been marked as a duplicate of this bug. ***
*** Bug 462121 has been marked as a duplicate of this bug. ***
*** Bug 467151 has been marked as a duplicate of this bug. ***
Qtsvg has had some work since last fall after being dormant for years. They have been adding more of the qt 1.1 spec beyond tinysvg. What more is needed that upstream doesn't have currently? Clipping support I know was a big deal and was added upstream in November https://github.com/qt/qtsvg/commit/77ad7934057b056bdb0c15d15a01ef83190dafaa
Qt SVG just needs improving really. There are various bug reports upstream about that and Qt maintainers also seem to agree with the general sentiment. That can ultimately mean basing it on another library behind the scenes. But, qtsvg is acting as a good abstraction for us here and we don't really need to throw the baby out with the bath water. IOW: the effort for improvement ought to be directed at Qt, not plasma/kde software specifically, as that would mean even more work in having to port everything away from qtsvg and adopting whatever other library, when we could just put forth a proposal to have qtsvg be based on that library. Now that being so that leaves us with a status quo where the user may not get all icons rendered correctly. That problem is indeed independent from the qtsvg being insufficient problem. e.g. librsvg also doesn't support everything the SVG spec does, so even there you can run afoul of the software. The solution I'd like to propose for that is to walk all icons and check their used xml tags. If we can maintain a fairly comprehensive list of supported tags we can then detect unsupported tags and notify the user about just how unsupported this theme is and tell them that they may be better off using another theme. They can still choose to use the theme, but they at least know about graphical glitches being expected.
I haven't investigated beyond this, but a quick test with Qt 6.5.0 on my system shows that clip paths don't seem to be working yet. The code that dofficialgman linked is supposed to be present in that version. It looks like they've only implemented clip path support in the SVG *generator*, not the renderer, as of this version. Here's a trivial test if you have eye of gnome installed (path to the icon is possibly Arch Linux specific). from PyQt6.QtGui import QPixmap from PyQt6.QtWidgets import QApplication, QMessageBox, QLabel app = QApplication([]) msg = QMessageBox() pixmap = QPixmap("/usr/share/icons/hicolor/scalable/apps/org.gnome.eog.svg") label = QLabel() label.setPixmap(pixmap) msg.layout().addWidget(label) msg.exec() Something else worth mentioning... I know this bug is about icon rendering specifically and we have bugs for the other issues. However, unless we bifurcate SVG handling in KDE, then Plasma, the system thumbnailer, and end user applications like Gwenview will all use the same library. Maybe we could do a survey of large public icon sets and decide that QSvg with clip path support is sufficient for icons, but a user might want to open a much wider variety of SVGs in Gwenview.
If we have no practical choice but to improve the Qt SVG renderer, either its own code or it as a platform abstraction, that's fine. What wouldn't be ideal is if we mark this as RESOLVED UPSTREAM and then the upstream work never materializes, though. :) If we want to show a warning for icon themes that will potentially mis-render icons given the known limitations of the chosen SVG renderer, the best place to show that would be at the moment when the user activates such an icon theme. Any other time and it would be really super annoying.
*** Bug 472227 has been marked as a duplicate of this bug. ***
*** Bug 473022 has been marked as a duplicate of this bug. ***
> The effort to use RSVG for icons instead of Qt SVG was mostly blocked by a) it would introduce a Rust dependency into KDE frameworks, which nobody wants, and b) refactoring stuff so that the Rust dependency wouldn't be in frameworks but elsewhere would be a large amount of pain. What Rust dependency? `librsvg` is provided as an `.so` plus several `.h`s on my distro (Arch). And here's its dependencies: cairo freetype2 gdk-pixbuf2 glib2 harfbuzz libxml2 pango I don't see any Rust dependency. Yes, you need Rust to build it. But we don't have to, and don't in practice, build all our dependencies.
Qt SVG in Qt 6.7 sees support for additional features which should alleviate this bug: https://doc-snapshots.qt.io/qt6-6.7/whatsnew67.html#qt-svg-module
This blog post has more info on the improvements Qt 6.7 brings: https://www.qt.io/blog/qt-svg-not-so-1.2-tiny-any-more In short the goal still isn't to support the full SVG 1.1 or 2.0 standard, just for the "useful and common elements", but it does show that Qt is now open to expanding beyond the tiny SVG standard for the bits that people use in practice.
Cool, let's monitor the situation and see if it makes a different. I did some tests with my current system version of Qt 6.6.0. - From Bug 472227: Mission Center now looks fine, Monero still looks wrong - From Bug 467151: Oxygen's edit-bomb and document-revert icons still look wrong - From Bug 462121: Kooha and Cheese both still look wrong - From Bug 456083: Audacity now looks fine - From Bug 451598: still looks wrong - From Bug 450971 EasyEffects now looks fine So, a bit better so far, but not what I'd call close to fixed yet. I'll test again after Qt 6.7 is released. From the blog post, it looks like most if not all of the issues from those child bugs ought to be fixed.
> - From Bug 456083: Audacity now looks fine > - From Bug 450971 EasyEffects now looks fine From memory, at least these two I fixed myself by contributing upstream changes to the icon that avoided the use of SVG elements that weren't supported (mostly clip paths). So it's possible that none of the issues were actually fixed as of Qt 6.6. Further, I can confirm that the issue with at least the Cheese icon is not fixed as of 6.7.0beta2. The blog post does link to a patch for clip path specifically, so maybe this missing feature specifically will be fixed soon. https://codereview.qt-project.org/c/qt/qtsvg/+/531968
Hah! Thanks a lot for submitting those icon patches upstream. Every little bit helps. Hopefully soon The Qt SVG renderer will be better enough that we don't have to bother anymore.
(In reply to Nate Graham from comment #21) > I did some tests with my current system version of Qt 6.6.0. > ... > - From Bug 472227: Mission Center now looks fine, Monero still looks wrong FWIW, Mission Center was also an upstream fix/workaround: https://gitlab.com/mission-center-devs/mission-center/-/merge_requests/64
Confirming. If fact, gwenview doesn't render that SVG file correctly. Operating System: openSUSE Tumbleweed 20240208 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.4-1-default (64-bit) Graphics Platform: Wayland
Created attachment 165751 [details] SVG referred view in Gwenview
*** Bug 484112 has been marked as a duplicate of this bug. ***
Qt 6.7 is released now. Can anyone using it already see if this is fixed now for these icons: - App icons for Monera, Kooha, Cheese, and Solanum - Oxygen's edit-bomb and document-revert icons
(In reply to Nate Graham from comment #28) > Qt 6.7 is released now. Can anyone using it already see if this is fixed now > for these icons: > - App icons for Monera, Kooha, Cheese, and Solanum > - Oxygen's edit-bomb and document-revert icons Cheese: no Kooha: no Solanum: no Monero: no -> fixed upstream by switching to PNG icons: https://github.com/flathub/org.getmonero.Monero/commit/81541b90924fa23033175dd3a719f3c2c779b3b7 -> original icon is not fixed: https://raw.githubusercontent.com/flathub/org.getmonero.Monero/afa2f2420a52e2da9f0af964dc2069d993f79cb9/extra/org.getmonero.Monero.svg edit-bomb.svgz: looks OK to me? document-revert.svgz: **regression!** - renders worse than shown in Bug 467151 Note that some progress has been made on this change: https://codereview.qt-project.org/c/qt/qtsvg/+/531968 If it gets finished, then that would probably fix most (?) broken icons, although I don't know that it will land before 6.8 or later.
Well that's disappointing. I was hoping that the changes in 6.7 were going to finally put this issue behind us. :/ Thanks anyway for testing!
Another important 6.7 regression probably worth mentioning here: causes extreme memory use including OOM conditions on some problematic SVG files (I've seen quite a few in the Adwaita theme). I've managed to crash both Dolphin and Gwenview this way after upgrading to 6.7, there will probably be numerous reports by other users about this and we should probably have somewhere to dupe them to... Upstream report I found: https://bugreports.qt.io/browse/QTBUG-124287
Shall we have an automated test that runs `rsvg` and `qtsvg` over all Breeze and Adwaita icons, `magick compare` them and warns for those with a high MAE or some other metric?
dont know how to link attachments, but just if it is helpful, mine: the "Decoder" SVG which has the bug (while other GNOME (Circle) apps dont) https://bugs.kde.org/attachment.cgi?id=167531
the thing is in my case, Gwenview (Flathub) displays it correctly, while in the plasma panel it is not
QtSvg just got support for Gaussian blurs: https://bugreports.qt.io/browse/QTBUG-123138 Progress! Not all the way there yet, but progress. That plus clipping paths should fix most of the reported issues, I think.
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.
(In reply to Nate Graham from comment #36) > 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. Indeed. Meanwhile, do you think it would be good if we have an automatic test suite in, say KSvg, that collects all SVG icons that used to be rendered wrong, and compares the QSvg renderering results against, say, rsvg or resvg, via some image similarity metric? Maybe this should really be upstream, too. But there probably will be more regressions and KDE will be receiving bug reports, so I'd expect such tests to save some time in future bug investigation. And I'd like to implement such tests.
Cool. It might make sense to get such a test in Qt for the purpose of guiding development of QtSvg in the direction of greater compatibility with common icons. But I don't think it would make sense to have in KDE as the results of the test wouldn't be actionable for us.
*** Bug 488521 has been marked as a duplicate of this bug. ***
*** Bug 489668 has been marked as a duplicate of this bug. ***
*** Bug 491574 has been marked as a duplicate of this bug. ***
*** Bug 493330 has been marked as a duplicate of this bug. ***
*** Bug 499094 has been marked as a duplicate of this bug. ***
I just want to say: We now have Plasma 6.3 and Qt 6.8.2 and this issue is at least not magically fixed. It looks like Qt 6.8 introduced a VectorImage QML Type which sounds like a better way to render SVGs, but probably needs implementing in Plasma.
If it uses the Qt SVG renderer under the hood, then we'll still be in the same situation of needing to wait until it fully supports things like clip paths and Gaussian blurs.
*** Bug 500546 has been marked as a duplicate of this bug. ***
I read everything and finally understood the story a bit. I thank everyone. It's a bit sad though that we drag bugs along forever. Of course it's clear that whoever distributes a library for rendering SVGs would be nice to respect the complete specifications and not self-declared sub-specifications. We'll see. I remember with nostalgia the good old days when all my icons worked and suddenly 2/3 stopped working :-(
Just a quick update with the release of Qt 6.9 - no movement at all on the clip path issue, which is our big one. A lot of common icons continue to use it, and unfortunately the situation has regressed in that work on the upstream issue appears to have stalled. I added the upstream bug for clip path to the URL field.
*** Bug 503613 has been marked as a duplicate of this bug. ***
I'm reopening this, because based off the previous comment it is in fact not quite resolved upstream.
after all this time, i think we should acknowledge the fact that QT has decided NOT to provide a generic library useful for viewing svg. it's obvious.
(In reply to Simona Pisano from comment #51) > after all this time, i think we should acknowledge the fact that QT has > decided NOT to provide a generic library useful for viewing svg. it's > obvious. Please see https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean.
FWIW, the upstream issue about adding support for Clip Paths (which is the last significant problem here) has an open patch to implement the feature, with movement just days ago: https://codereview.qt-project.org/c/qt/qtsvg/+/531968 So all hope is not lost here. Keeping this closed since it is just an upstream issue and we need to be patient until that patch is merged.
*** Bug 504445 has been marked as a duplicate of this bug. ***