This screenshot is from Inkscape. Note the paint order: Stroke, Fill, Markers.
This screenshot is from KDE Dolphin previewing the same SVG.
According to SVG docs on MDN, paint order is executed left-to-right. The default order is fill-stroke-markers, so strokes are rendered on top of the fill. In this case, SVG specifically has instructions to reverse and paint fill on top of the strokes. Apparently, Dolphin ignores these instructions.
Can you explain why? Am I missing something?
This is an issue with QtSvg our svg render used by KDE application.
It does not implement the whole svg specification which is huge.
That’s a bug.
It’s not only about the “paint order”. When I made some custom icona to fit my icon pack I noticed that the sizes as well as the colors in Dolphin don’t match with what is rendered whether in the app that I used to edit the svgs (Boxy SVG) and also in other apps that can render svgs for example Google Chrome
That was my assumption, but I decided to ask first to be sure.
Should I report it? I could (probably) try to fix it myself, but
a) scary
b) knowing about the current influx of AI slop PRs, I doubt that a PR from a newcomer will make it through.
See https://bugs.kde.org/show_bug.cgi?id=448234. It’s a case of missing support for various SVG features in Qt itself. It can’t really be fixed in KDE code. You should feel welcome to fix it in Qt. I don’t think it’s a good assumption that your good-faith PR will be ignored!
You can attach the svg file alongside a png exported from inkscape for reference in a comment.
The support issue seems very modest, so that could fit in current Qt Svg reduced-svg support.
