After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784885 - SVG slightly more complicated CSS style not working at all
SVG slightly more complicated CSS style not working at all
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-13 03:34 UTC by conrad_heimbold
Modified: 2017-12-13 18:28 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24


Attachments
SVG file with CSS rules that don't get applied in eog/gthumb, but work inside firefox/chromium (636 bytes, image/svg+xml)
2017-07-13 03:34 UTC, conrad_heimbold
Details

Description conrad_heimbold 2017-07-13 03:34:26 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!
Comment 1 conrad_heimbold 2017-07-13 03:41:23 UTC
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.
Comment 2 Felix Riemann 2017-07-14 18:32:49 UTC
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.
Comment 3 GNOME Infrastructure Team 2017-12-13 18:28:05 UTC
-- 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.