Page MenuHomePhabricator

SVG renderer does not support the <pattern> tag
Closed, ResolvedPublic


Author: hendrik.tammen


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>.


Version: unspecified
Severity: normal
See Also:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:30 PM
bzimport set Reference to bz8552.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Are we willing/able to hack librsvg? If not, this is WONTFIX/INVALID, an upstream problem.

hendrik.tammen wrote:

Unfortunately I'm not a good coder, so I don't know what you can do but I wanted
to add this:

Apache 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?

hendrik.tammen wrote:

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 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.

mistman123 wrote:

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.

mistman123 wrote:

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.

mistman123 wrote:

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?

mike.lifeguard+bugs wrote:

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

This issue is not yet fixed. Adding a screenshot with left mediawiki rasterizing, right inkscape. The missing patterns are clearly visible.


Screen_shot_2010-11-04_at_02.55.54.png (604×1 px, 312 KB)

Removing "shell" keyword for things that aren't directly doable by shell users etc

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.

(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.

Perhelion set Security to None.