Bug 448234 - Usage of Qt SVG renderer causes some 3rd-party app icons to be mis-rendered
Summary: Usage of Qt SVG renderer causes some 3rd-party app icons to be mis-rendered
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.23.5
Platform: Arch Linux Linux
: HI normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
: 450971 451598 456083 462121 467151 472227 473022 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-01-10 21:34 UTC by Adam Fontenot
Modified: 2023-08-07 22:22 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot showing the issue in the search plasmoid (22.68 KB, image/png)
2022-01-10 21:34 UTC, Adam Fontenot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Fontenot 2022-01-10 21:34:01 UTC
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_()
Comment 1 Nate Graham 2022-01-11 16:42:42 UTC
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.
Comment 2 Janet Blackquill 2022-01-11 16:45:58 UTC
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.
Comment 3 Nate Graham 2022-02-28 21:37:25 UTC
*** Bug 450971 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2022-03-28 04:02:00 UTC
*** Bug 451598 has been marked as a duplicate of this bug. ***
Comment 5 David Edmundson 2022-03-28 07:36:28 UTC
>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.
Comment 6 Nate Graham 2022-03-28 13:53:04 UTC
*** Bug 450971 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2022-03-28 13:53:23 UTC
*** Bug 451598 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2022-03-28 14:00:34 UTC
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.
Comment 9 Nate Graham 2022-06-29 16:21:43 UTC
*** Bug 456083 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2022-11-30 02:33:22 UTC
*** Bug 462121 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2023-03-13 19:52:11 UTC
*** Bug 467151 has been marked as a duplicate of this bug. ***
Comment 12 dofficialgman 2023-04-30 05:02:23 UTC
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
Comment 13 Harald Sitter 2023-05-03 20:29:51 UTC
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.
Comment 14 Adam Fontenot 2023-05-03 22:35:35 UTC
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.
Comment 15 Nate Graham 2023-05-05 06:13:30 UTC
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.
Comment 16 Nate Graham 2023-07-24 23:45:39 UTC
*** Bug 472227 has been marked as a duplicate of this bug. ***
Comment 17 Nate Graham 2023-08-07 22:22:39 UTC
*** Bug 473022 has been marked as a duplicate of this bug. ***