Last modified: 2013-09-30 15:12:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48540, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46540 - SVG file rasterization uses wrong green color (#00FF00 instead of #008000) due to libcroco bug
SVG file rasterization uses wrong green color (#00FF00 instead of #008000) du...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
SVG rendering (Other open bugs)
wmf-deployment
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
https://commons.wikimedia.org/wiki/Fi...
:
Depends on:
Blocks: svg
  Show dependency treegraph
 
Reported: 2013-03-25 15:05 UTC by Mormegil
Modified: 2013-09-30 15:12 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mormegil 2013-03-25 15:05:20 UTC
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 http://www.w3.org/TR/SVG11/types.html#ColorKeywords). See the attached URL.

This has changed quite recently, I noticed this after uploading a new version of https://commons.wikimedia.org/wiki/File:Leapsecond.ut1-utc.svg – note the old version thumbnail <https://upload.wikimedia.org/wikipedia/commons/thumb/archive/f/fb/20120710134637%21Leapsecond.ut1-utc.svg/120px-Leapsecond.ut1-utc.svg.png> uses the correct green, however, a newly rendered thumbnail for the same version is broken: <https://upload.wikimedia.org/wikipedia/commons/thumb/archive/f/fb/20120710134637!Leapsecond.ut1-utc.svg/121px-Leapsecond.ut1-utc.svg.png>.
Comment 1 Brion Vibber 2013-03-25 21:43:10 UTC
Note that attached URL says "green" is #008000, not #008080.
Comment 2 Mormegil 2013-03-25 22:11:29 UTC
Umm… of course it is, sorry, just a typo there.
Comment 3 Mormegil 2013-03-29 13:19:49 UTC
The problem is probably in a broken version of libcroco (used by librsvg): In https://git.gnome.org/browse/libcroco/commit/?id=0cbb0dfed7350ed48a12d56925cdd76255891aa5 (on 2012-03-18), the bug was introduced per mistaken https://bugzilla.gnome.org/show_bug.cgi?id=672332

This change was reverted in https://git.gnome.org/browse/libcroco/commit/?id=b37d79049a0f9149df98e5adb4f69db69deef056 (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)?
Comment 4 Andre Klapper 2013-04-02 09:55:36 UTC
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 https://launchpad.net/ubuntu/ ) 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.
Comment 5 Mormegil 2013-04-11 15:48:30 UTC
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.

See https://bugs.launchpad.net/ubuntu/+source/libcroco/+bug/1163999
Comment 6 Mormegil 2013-09-30 15:12:14 UTC
The fix to Ubuntu LTS was released, and probably applied to WMF servers, as the image on Commons renders correctly, now.

Marking RESOLVED FIXED.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links