GNOME Bugzilla – Bug 161467
SVG gradients must be reapplied before saving
Last modified: 2005-05-20 00:31:21 UTC
I'm working with Inkscape 0.40, taking a given SVG, importing another (which renders correctly on its own), and saving it. When I do that, the gradients in the imported SVG render correctly in Inkscape but not with librsvg and show up various shades of gray. However, if I reapply the gradient in Inkscape (the same one that it already is) and resave it, it then renders correctly. Steps to reproduce: 1. Begin in Inkscape with either a blank file or another SVG (doesn't matter which). 2. Import an SVG (with gradient). 3. Ungroup objects. 4. Save. 5. Renders incorrectly. I have uploaded a file doing the steps to this point; the following steps fix it. Steps to fix (in Inkscape): 1. With imported SVG, open the Fill/Stroke box for the object with the gradient. 2. From list of gradients, click on the one already chosen. (Sometimes I have to go as far as turning the fill off and back on.) 3. Save again. 4. Renders correctly.
Created attachment 34909 [details] Example file This file displays correctly in Inkscape 0.40 but not with librsvg 2.8.1.
confirm that the arrow is gray instead of a purple-ish gradient
the problem element is <path id="path589"> using fill:url(#linearGradient581); a possible cause of the problem is that linearGradient581 is based on linearGradient578, which is defined *after* linearGradient581
Is that last comment meant to identify the problem or to determine that it's not a bug? If I should go back to Inkscape and tell them anything, please let me know.
the comment is meant only to record some investigation that i did, so that i or caleb can fix the bug more quickly when we get some time. it is best, in my opinion, if the SVGs are emitted in a "streamable" format, which means that gradient 578 should appear before gradient 581 in the file. technically librsvg, not inkscape, is at fault here. but that doesn't mean that inkscape still isn't doing something stupid.
IIRC elements need to be defined before they are used in SVG 1.1. Putting 578 near the top of the file makes it work perfectly. SVG 1.2 will support such things http://www.w3.org/TR/SVG12/progressiverendering.html but since rsvg makes no pretence of supporting this new standard yet, it could hardly be considered a bug.
Please reread sections 5.3 and 11.2 of the SVG 1.1 standard. Unless I am missing something obvious, there is no such requirement and librsvg is in error.
i believe that your reading is correct, nor did i disagree with you. librsvg is clearly in error. however, that does not address my criticism that while inkscape's behavior is technically legal, it is behaving less-than-ideally. and that it would be "nice" if inkscape would emit SVGs in what SVG 1.2 calls a "streamable" manner. http://www.w3.org/TR/SVG12/streaming.html
The comment was addressed to Caleb. To some extent we could try harder to create gradients in a streamable order as well, supplemented by a "streamable" export option. I don't think it's something we'd want to do by default to existing documents.
Ok, it's all fixed now in CVS HEAD.