GNOME Bugzilla – Bug 764808
currentColor is rendered transparent; it should be black
Last modified: 2016-04-12 21:59:18 UTC
Goal: Generate png images from svg images generated by mathjax for wikipedia Problem: Currently we use the node module librsvg which calls librsvg-dev and all the images are just transparent png images. For example https://en.wikipedia.org/api/rest_v1/media/math/render/png/4c0004393a88f350a93bcef62106d556c7fc827b but you can also generate arbritrary svg images using the web ui at https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type Cause: I tried to track down where the problem comes from. On my development machine (windows) everything works well, and I could generate png images for all svg images I tested including this list https://github.com/wikimedia/mathoid/tree/master/test/files/mathjax-texvc/svg. Also travis that uses the librsvg2-dev package ship with ubuntu Description Ubuntu 12.04.5 LTS generates the exactly same png images see https://travis-ci.org/physikerwelt/node-rsvg/jobs/121768668 (unfortunately I do not know how to figure out the specific number of that librsvg2-dev version). I tried to generate different version of the same svg image that look alike here https://github.com/physikerwelt/node-rsvg/tree/master/test/svg However, all the svg images beginning with 1 did not match the version generated by travis and my windows machine when I renderd them with the wikimedia test instances. Those instance use a customized version of librsvg dpkg -l | grep librsv ii librsvg2-2:amd64 2.40.2-1+wm1 amd64 SAX-based renderer library for SVG files (runtime) ii librsvg2-common:amd64 2.40.2-1+wm1 amd64 SAX-based renderer library for SVG files (extra runtime) ii librsvg2-dev 2.40.2-1+wm1 amd64 SAX-based renderer library for SVG files (development) Therefore I build the librsvg package from sources which and now I get dpkg -l | grep librsv ii librsvg2-2:amd64 2.40.13-3 amd64 SAX-based renderer library for SVG files (runtime) ii librsvg2-common:amd64 2.40.13-3 amd64 SAX-based renderer library for SVG files (extra runtime) ii librsvg2-dev:amd64 2.40.13-3 amd64 SAX-based renderer library for SVG files (development) The resulting images look like that http://drmf2016.wmflabs.org/images/ubuntu14.zip The node module is availible from https://github.com/physikerwelt/node-rsvg/ Possible Workarounds: Since we have full control over the workflow changing the input svg to a version that looks like the original but uses different svg features is also an option. However, I have not found a way to manipulate the SVG image in a way that it does actually render.
Created attachment 325754 [details] 1-noXlink.svg - this renders badly
Created attachment 325755 [details] 1-noXlinkBlack.svg - this renders well
The only meaningful difference between those SVGs is that the one that renders badly has <g stroke="currentColor" fill="currentColor" and the other one has <g stroke="black" fill="black" Maybe we are mis-initializing currentColor to all-zeros / "fully transparent black" or something like that? Off a quick scan of the SVG and CSS specs, I couldn't find what to use for the base default color.
(From what I can glean, currentColor is used so that you can embed SVG in HTML or something, and it will use the "current color" from whatever was rendering. Those example files are from SVGs created out of math formulas, which are to be embedded inline with other text - thus they should have the same color as the text.)
I've pushed a fix as commit aec5f5c34a233cae4d21284f55c2af2e4ddb0b3b in the master branch. This requires the previous commit as well, which renames a bunch of fields in the internal structures. This makes currentColor render as black. The API in librsvg doesn't let you pass in a starting state of CSS; it always starts off fresh. I think this will solve your immediate problem for Wikimedia. Are you tweaking the Cairo context at all before asking librsvg to render things? I guess we could make currentColor inherit the cairo_t's current color if it is a CAIRO_PATTERN_TYPE_SOLID.
Forgot to say that the fix for currentColor=black will appear in 2.40.16.