FT2.wiki wrote:

Although the browser renders the SVG file correctly, its inclusion _whether full size or thumbnailed_ on a wiki page is broken as above.

FT2.wiki wrote:

Tested further. Its not related to being a "large SVG" either.

http://en.wikipedia.org/wiki/Image:BLP_flowchart_2b-no%24.svg has half the linear dimensions, 380 x 615. Identical error.

Eh? Correctly? What are these "several browsers"... In Firefox 2, I get this:
http://uploads.screenshot-program.com/upl4252097277.png

And even in Inkscape I get this:
http://img183.imageshack.us/img183/9195/blpflowchart2au2.png

So, while the issue isn't black blocks. The SVG clearly is not normal.
I would chalk this up to differences in SVG rendering engines. Cause not all SVG engines render a SVG the same. A SVG file should at least be correct before any rendering issue be considered a 'bug'.

Besides, MediaWiki doesn't even render SVG files, it offloads that to a separate svg program which is set in configuration, so to fix a svg 'bug', you'd have to fix every engine which it breaks in, which is something MediaWiki has no control over, because svg rendering engines are created by other projects not connected with MW.

FT2.wiki wrote:

Screenshot - opera 9 + IE6

Attached:

FT2.wiki wrote:

The SVG renders correctly in Opera, and Internet Explorer. Those are the two I have to hand. See above screenshot. (And note the slight differences in blurring of fonts, otherwise the two render them identically.)

I also hand-checked the xml within it a second time and it's as best I can tell, standards compliant. I don't have firefox so I can't test on that, but both of those two it renders fine.

FT2.wiki wrote:

Screenshot of the same images as rendered by mediawiki

Attached:

FT2.wiki wrote:

And above, as these display within mediawiki pages.

FT2.wiki wrote:

BUGS FOUND:

According to a graphics specialist:

"The problem was that in some places the font size was being scaled to 120% of the original size, but ImageMagick (MediaWiki's rendering engine) was interpreting this as a literal 120 point (I think) - the black boxes were actually letters. I've fixed that, and partially fixed the problem with the overlayed text when it's rendered with Gecko, e.g. in Firefox; the problem there was that it wasn't recognising the 'dy="1.4em"' in the tspan elements, but a simple change of units to pixels fixed that. There are still some strange things going on with Gecko, but I'm not sure what to do with those."

http://en.wikipedia.org/w/index.php?title=Wikipedia:Graphic_Lab/Images_to_improve&diff=200523223&oldid=200513237

FT2.wiki wrote:

So we have two apparent bugs identified in rendering SVG's:

• Font sizing via percentage is broken somehow: sizing of the form font-size = "120%" is being rendered as "120px"

• Line separation in SVG text elements of the form dy='1.4em' is broken somehow.

FT2.wiki wrote:

Third bug, underlining also isn't recognized. Compare:

http://en.wikipedia.org/wiki/Image:BLP_flowchart_2.svg
and
http://upload.wikimedia.org/wikipedia/en/thumb/f/f0/BLP_flowchart_2.svg/370px-BLP_flowchart_2.svg.png

FT2.wiki wrote:

BUG CAUSES:

Looking at the svg the issue seems to be that alternative size scales are not being correctly converted to pixels in svg rendering.

Thus 120% of a 14px fontsize is rendered as 120px rather than 16.8px (=14px x 120%), whereas if the font-size=120% is replaced by font-size=16.8px it's fine. Likewise dy=2em fails whereas its equivalent dy=28px (=14px x 2) succeeds.

Failure to render underlined text is a separate issue.

Please list bugs individually; there's no way we can reasonably track three or more different things on one bug entry.

Please also check for duplicates; there are plenty of SVG-related issues filed already.

Please also note that we use rsvg, not ImageMagick, as the rendering backend.

FT2.wiki wrote:

Thanks Brion! Bugs opened:

Bug 13494 - font size and conversion to px.
Bug 13495 - underline not rendering properly.

I checked for duplicates. 40+ bugs are open mentioning SVG, but I can't find clear reference to these in them.

I guess this one can now be closed if all's ok?