GNOME Bugzilla – Bug 784885
SVG slightly more complicated CSS style not working at all
Last modified: 2017-12-13 18:28:05 UTC
Created attachment 355477 [details] SVG file with CSS rules that don't get applied in eog/gthumb, but work inside firefox/chromium Neither gthumb nor eog correctly apply slightly more complicated internal CSS styles. The only CSS style which works is having a single (!) class or id, combining multiple components (e.g. .class1 .class2 { fill:blue } or #id123,.class1 { fill:red } or .class1 > .class2 { fill:yellow }) does not seem to work at all. For an example, see the attachment. - Open it inside a browser with SVG support (Firefox, Chrome, Chromium, etc.), where it is working - Open it inside eog or gthumb, where it is not working (just a black picture), because eog or gthumb ignore the CSS definitions. If you don't trust me, just inspect the SVG file - it's just a txt file. You may ask yourself, why I even need that SVG feature? I don't want to have the styling information scattered around inside the SVG, this makes the SVG difficult to maintain and extremely BLOATED and GIANT. Inkscape already adds tons of scattered unnecessary text; Adobe Photoshop is even worse with its binary data!
In the long run, I wanted to use external CSS file sheets to reduce the SVG size & complexity even more and apply these rules to multiple SVG files at once. Keeping the style info inside the <def/> element is therefore not the perfect solution.
eog (and likely gThumb as well) use librsvg for SVG rendering. Reassigning. Considering it's related to CSS parsing it may as well become a libcroco ticket.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/167.