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. ***