Page MenuHomePhabricator

Update rsvg so styling SVG images with CSS works properly on Commons
Closed, ResolvedPublic

Description


Version: unspecified
Severity: normal
OS: Linux
Platform: PC
URL: http://commons.wikimedia.org/wiki/File:Bielsko-Biała,_Biała_Krakowska.svg

Details

Reference
bz24000

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:08 PM
bzimport set Reference to bz24000.

Think you might have submitted a bit too soon there. Can you try again? :)

Yes, I've mistakenly pressed the 'Enter' button :)
Here it goes:

Hello,
there seems to be a problem with styling CSS files and rendering them by the
rsvg library used by MediaWiki at Commons.

I have a file
http://commons.wikimedia.org/wiki/File:Bielsko-Biała,_Biała_Krakowska.svg that
is styled with CSS using an internal stylesheet.
I have read the CSS specification and used the code given there; the file is
valid according to the w3 validator.

It renders correctly in Mozilla Firefox and Opera (click on the file to see) as
well as using rsvg 2.26.3 on Ubuntu Lucid Lynx (screenshot attached). However,
as you may see, the thumbnail visible at Commons renders incorrectly -- a path
that should be filled in orange is still blue.

Any ideas what may be wrong with that?

Created attachment 7476
Screenshot of eog 2.30 (rsvg 2.26.3) on Ubuntu Lucid Lynx rendering the file correctly

Screenshot of eog 2.30 (rsvg 2.26.3) on Ubuntu Lucid Lynx rendering the file correctly.

Attached:

sc.png (600×440 px, 55 KB)

for what it's worth, rsvg 2.22.3 does *not* render it correctly for me. so hoefully, this can be fixed by ugrading rsvg.

Seems like both cascading order (http://www.w3.org/TR/CSS2/cascade.html#cascading-order) and specificity (http://www.w3.org/TR/CSS2/cascade.html#specificity) rules are broken.

You have an author-specified rule:

#Biala_Krakowska { fill: #ff7e00 !important; }

in the local stylesheet that does not take precendence over author-specified normal rule in style="" attribute.

I have uploaded a different version (http://upload.wikimedia.org/wikipedia/commons/archive/c/cd/20100616150857%21Bielsko-Bia%C5%82a%2C_Bia%C5%82a_Krakowska.svg) where style="" atributes are replaced with classes and where path#id CSS rule should take preference over path.class. However, it does not happen in the older versions of librsvg2 (I'm using 2.22.3 that exhibits similar problem to Wikimedia's).

http://git.gnome.org/browse/librsvg/log/ shows serveral improvements in the recent librsvg2, so looks like proper CSS support is being actively worked on.

Bryan.TongMinh wrote:

Changing component to Wikimedia; this can be fixed by an rsvg update.

I don't want to find the one of the many SVG bugs that is related to, but the broken PNG rendering of http://de.wikipedia.org/wiki/Datei:Chios_topographic_map-de.svg (the text "Meerenge von Chios" between the two islands) is fixed on my local box with "rsvg version 2.26.0", so please update and then close all bugs that have disappeared as well :-).

The latest version of librsvg is 2.32.0. 2.22.2 is almost 1.5 years old. It seems like it would be high time for an upgrade.

Agree, updating rsvg seems like a VERY good idea.

Bumping priority, giving to Mark to handle and adding CT Woo to aid me in pestering them, or at least getting an update on the rsvg update.

Removing "shell" keyword for things that aren't directly doable by shell users etc

Removing shell keyword if exists

Looking at this, upgrading to 10.04 will fix the known version problems

Just spoke to CT about this, and will look into whether we get the current image scalers upgraded, or how to proceed

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

lowering priority on this that will take a little longer to get resolved.

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

Did an action=purge on http://commons.wikimedia.org/wiki/File:Bielsko-Bia%C5%82a,_Bia%C5%82a_Krakowska.svg and refreshed to check update status...

Confirmed that the old versions of the file now render correctly, with the orange-highlighted chunk in the middle -- previously they rendered all-blue and only the newer version that worked around the bug looked right.

Yay!

Try ?action=purge on any images still affected by this and refresh to confirm they're good now.