Page MenuHomePhabricator

Hairline / seam in SVG rendering
Open, Stalled, LowestPublic


Author: t_edwards

Three SVG files identical in every way but their colour have been rendered differently:

The issue is along the centre of the image from top to bottom. The black image has a barely-noticeable seam, and the red image has no seam at all, yet the green image has a very noticeable seam all the way through. It may be helpful to zoom in on the rasters to see what I'm talking about.

The left half of the image is mirrored to create the right half, which explains but doesn't excuse the seam - the two halves actually *overlap* each other!

Given that the seam comes and goes depending on the size of the raster, I'd tentatively put this down to rounding errors...

Version: unspecified
Severity: normal



Event Timeline

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

ayg wrote:

Not a MediaWiki issue. MediaWiki doesn't do SVG rasterization, it just passes off to third-party tools. Refiling as Wikimedia. Checking whether it works in the latest version of whatever SVG renderer we use (librsvg, was it?) would probably be helpful.

t_edwards wrote:

I've just given up trying to compile librsvg for Windows. GNU is as impenetrable as ever...

Someone else will have to test the latest build.

t_edwards wrote:

I changed the red image to a darker shade and it's now developed a seam as well. Check the file history for the version unaffected by this bug:

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.

giving SVG bugs back to the pool.

Created attachment 9611
rendering of the problem

The issue still seems to exist, after the recent librsvg update.


400px-Crowned_Portcullis_green.svg.png (478×400 px, 36 KB)

Seems to be solved with recent rsvg update, can One confirm?

I temp undeleted this (green) file and it still seems to be problematic.

I propose a other name for this ''hairline'' bug. "Colour-dependent" is completely unrelated.

See also:
[[File:SVG 3 paths.svg]]

Some browsers have the same bug (on zooming).

I propose a other name for this ''hairline'' bug. "Colour-dependent" is completely unrelated. See also: [[File:SVG 3 paths.svg]]

The SVG file at itself renders a hairline in Firefox 65 on a zoom level different than 100%. Firefox does not use librsvg. I can also still reproduce the problem locally with the SVG format file on zoom levels different than 100% with librsvg2-2.45.5.

Aklapper lowered the priority of this task from Medium to Low.Mar 10 2019, 6:43 PM
has hairline-cracks all over (from an actual image: File:Two_way_complex_manifold.svg)
you can't even recognise the image any more. (Firefox has the same bug, but chrome not) is antother actual image, amost impossible to make a workaround.

AntiCompositeNumber raised the priority of this task from Low to Needs Triage.Oct 14 2020, 9:27 PM
AntiCompositeNumber moved this task from Backlog to Upstream (librsvg) on the Thumbor board.

Comparison with other renderings: It seems to be a general problem

300px of

SVGInkscaperesvglibrsvg 2.50batikexpected
Silversmith_BMP2SVG_accelerated-i-o_300_Inkscape.png (402×300 px, 267 KB)
Silversmith_BMP2SVG_accelerated-i-o_300_rendersvg.png (402×300 px, 257 KB)
Silversmith_BMP2SVG_accelerated-i-o_300_librsvg.png (402×300 px, 267 KB)
Silversmith_BMP2SVG_accelerated-i-o_300_batik.png (402×300 px, 248 KB)
Silversmith.jpg (818×610 px, 24 KB)

250px of

Bildschirmfoto von 2021-05-07 22-04-28.png (650×1 px, 735 KB)

Detail of

68747470733a2f2f757365722d696d616765732e67697468756275736572636f6e74656e742e636f6d2f31353638373538312f37353439313437302d34653430613230302d353962362d313165612d396463652d3933336130626336613563302e706e67.png (287×361 px, 21 KB)

Copyright of




512 px

T20936_Hairline_cracks_Inkscape.png (222×512 px, 7 KB)
T20936_Hairline_cracks_rendersvg.png (222×512 px, 13 KB)
T20936_Hairline_cracks_librsvg.png (222×512 px, 7 KB)
T20936_Hairline_cracks_batik.png (222×512 px, 5 KB)
Two_way_complex_manifold__rendersvg.png (2×5 px, 536 KB)



This is not how SVG works. Due to antialisaing, floats rounding and scaling it can produce whatever it wants.

Since it is imho something that everybody renders wrong. Hairline-cracks seem to be more likely a bug of the file, than an upstream-bug of the renderer. So I would close it as invalid.

JoKalliauer changed the task status from Open to Stalled.May 16 2021, 5:40 PM
JoKalliauer triaged this task as Lowest priority.
JoKalliauer updated the task description. (Show Details)

This issue is not a bug but rather the way SVG compositing is done. I would close this issue as invalid or Won't Fix.

Consider File:Hairline_crack.svg:

<?xml version="1.0"?>
<svg xmlns="" width="191" height="95.5" viewBox="0 0 198 99">
  <rect width="198" height="99" fill="#FFF"/>
  <rect x="0" y="0" width="99" height="99"/>
  <rect width="99" height="99" x="99" y="0"/>

It fills the 198-wide background with white. Then it overwrites with two 99-wide patches of black.

The SVG will be painted into a bitmap. We are interested in what happens at the midline/hairline column of pixels. For simplicity, assume that 99 logical pixels falls exactly in the middle of the hairline pixel column.

The hairline column is first composited to white #FFF.

The first black patch changes the left side to black, but look what happens at logical pixel 99. It will not try to turn that pixel into solid black because it is only overwriting 50% (not 100%) of that pixel. As a result, the hairline column is set to 0.5 * #FFF + 0.5 * #000 = #888.

The second black patch starts a logical pixel 99, so that black is also only overwriting 50% of the hairline column. Now the hairline column becomes 0.5 * #888 + 0.5 * 000 = #444.

Hence most of the pixels are black #000, but the hairline is #444.

Where the logical pixels fall within the actual bitmap determines the magnitude of the hairline, so it is not surprising that the Silversmith images display Moire patterns.

Any edge that does not fall exactly on an underlying bitmap edge may show a crack.

I would close this issue as invalid.