Bug 448234

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.

*** Bug 450971 has been marked as a duplicate of this bug. ***

*** Bug 451598 has been marked as a duplicate of this bug. ***

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