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