Page MenuHomePhabricator

SVG file rasterization uses wrong green color (#00FF00 instead of #008000) due to libcroco bug
Closed, ResolvedPublic


When an SVG file uses a green color specified with the keyword “green”, it is apparently rasterized as RGB #00FF00, but “green” should mean RGB #008080 (see See the attached URL.

This has changed quite recently, I noticed this after uploading a new version of – note the old version thumbnail uses the correct green, however, a newly rendered thumbnail for the same version is broken:!Leapsecond.ut1-utc.svg/121px-Leapsecond.ut1-utc.svg.png.

Version: wmf-deployment
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:17 AM
bzimport set Reference to bz46540.
bzimport added a subscriber: Unknown Object (MLST).

Note that attached URL says "green" is #008000, not #008080.

Umm… of course it is, sorry, just a typo there.

The problem is probably in a broken version of libcroco (used by librsvg): In (on 2012-03-18), the bug was introduced per mistaken

This change was reverted in (on 2012-10-07), after which the behavior should be correct again.

Which means libcroco versions 0.6.5 and 0.6.6 are broken, and at least v0.6.7 is required to fix this (v0.6.8 seems to be current).

Not sure what is needed / who can do such an update (“ops” maybe)?

Thanks for investigating and tracking this down!

Nearly all servers run Ubuntu 12.04 Precise which ships

libcroco3 0.6.5-1

So the very best way would be convincing Ubuntu (in ) to ship a newer version of libcroco, or to specifically backport that patch. If that's a no-go, an updated package could be created based on 0.6.5-1 which includes the aforementioned, isolated patch.

The patch for Ubuntu LTS is currently in -proposed; if somebody would be able to test the package somewhere on beta/labs/whatever, that would be great.


The fix to Ubuntu LTS was released, and probably applied to WMF servers, as the image on Commons renders correctly, now.