Page MenuHomePhabricator

Hairline / seam in SVG rendering
Open, LowPublic

Description

Author: t_edwards

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

http://en.wikipedia.org/wiki/File:Crowned_Portcullis.svg
http://en.wikipedia.org/wiki/File:Crowned_Portcullis_red.svg
http://en.wikipedia.org/wiki/File:Crowned_Portcullis_green.svg

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
URL: https://commons.wikimedia.org/w/index.php?title=File:Hairline_crack.svg

Details

Reference
bz18936

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 10:39 PM
bzimport set Reference to bz18936.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.May 26 2009, 3:54 PM

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:

http://en.wikipedia.org/wiki/File:Crowned_Portcullis_red.svg#filehistory

brion added a comment.Aug 3 2009, 4:53 PM

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.

TheDJ added a comment.Dec 4 2011, 9:14 PM

Created attachment 9611
rendering of the problem

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

Attached:

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

TheDJ added a comment.Oct 26 2012, 9:33 AM

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 https://upload.wikimedia.org/wikipedia/commons/5/5d/SVG_3_paths.svg 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 Normal to Low.Mar 10 2019, 6:43 PM

https://commons.wikimedia.org/wiki/File:T20936_Hairline_cracks.svg
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)

https://commons.wikimedia.org/wiki/File:Silversmith_BMP2SVG_accelerated-i-o.svg is antother actual image, amost impossible to make a workaround.