Last modified: 2014-09-24 17:04:44 UTC
the SVG renderer does not yet support usage of the <pattern> tag. This tag can
bring more flexibility for example, when crating maps as SVG.
Note: Firefox 3 will support <pattern>.
Are we willing/able to hack librsvg? If not, this is WONTFIX/INVALID, an upstream problem.
Unfortunately I'm not a good coder, so I don't know what you can do but I wanted
to add this:
Apache Batik (http://xmlgraphics.apache.org/batik/) already supports the
<pattern> tag and as far as I understand it, you can download the source and
work on that.
I tried converting an SVG (including <pattern>) to a PNG and it worked. I've
been using this page to convert it:
According to the librsvg changelog, they have supported patterns since 2.13.2.
Can you please upload a test case?
Okay, I found out that the problem is slightly different: The renderer does
support pattern but it doesn't support pattern that uses linear/radial gradient.
Example A: Shows a regular pattern.
Example B: Should show a pattern with a radial gradient, which internally uses a
linear gradient. Note that also Firefox 18.104.22.168 doesn't show it.
Example C: Tryed to fix validation errors of example B but this version doesn't
work at all. Feel free to rework it.
The problem occurs only sometimes for me even for the same cases!
Download it as SVG and open it with Inkscape or AI and you'll see where the patterns should be.
In another case (a variation of the document), it worked:
I've being going crazy with this. What can I do to fix it!! Where can I get the code to check and see if I can do something about it?
if it happens "sometimes" on wikimedia sites, it's probably caused by the fact that some servers use a different version or configuration of rsvg than others. So, depending on where it gets rendered, it works, or it doesn't.
How can that be resolved then? Can we do something about it???
the only way i can think of is: beg someone with server access to test the picks on every box and compare the results. and compare rsvg versions, and update if needed.
I guess they would have a way of knowing on which server some particular image is located, so if people complain about a particular image they can gradually update the servers with the latest version instead of having to check all servers exhaustively. I'm willing to beg. Who has server access?
Still present with 2.22.0.
Have we ruled out different verions of librsvg on different servers? If so, it's a software bug, not shell (& being an upstream bug could be closed as invalid per comment 1).
Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.
Created attachment 7786 [details]
This issue is not yet fixed. Adding a screenshot with left mediawiki rasterizing, right inkscape. The missing patterns are clearly visible.
Removing "shell" keyword for things that aren't directly doable by shell users etc
Adding ops keyword
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
giving SVG bugs back to the pool.
In the meantime the image scalers are on 10.04 as of fairly recently. I'm not sure who (Ryan? Peter?) made it happen.
Issue not fixed after recent rsvg update.
... which is librsvg 2.36 from Precise
In general librsvg 2.36 support the pattern tag. If not open a new concrete bug report.
The example usage mentioned in Comment #5 still fails rendering properly. Ie:
(In reply to Antoine "hashar" Musso from comment #22)
> The example usage mentioned in Comment #5 still fails rendering properly. Ie:
This is a special case of combination of pattern and gradient fill. If you remove the gradient, the pattern works fine. So the bug description is wrong.