Last modified: 2014-06-02 08:49:22 UTC
I think that MediaWiki ignore „baseline-shift” in SVG files. Example: http://commons.wikimedia.org/wiki/Image: Fluoxetine_.svg. „3” should be as subscript. Code: <text fill="#000" font-family="Arial" font-size="30pt" textLength="55.7" x="288.3" y="453.838348083">CF<tspan baseline-shift="sub" font-size="75%">3</tspan></text> Also, MW interpreted „font-size="75%"” as 75% page height or I don't know what.
There are multiple images to demonstrate, that baseline-commands are not rendered correctly. There is also a category on commons that should contain these faulty images. (See [[:commons:Category:Pictures showing a librsvg bug]] Example-Pictures showing that bug: * [[:commons:Image:2 methylnaphthalene.svg]] * [[:commons:Image:Radical benzil.svg]] * [[:commons:Image:Eulan.svg]] * [[:commons:Image:Fenitrothion.svg]] * [[:commons:Image:Diazepam-BUGTRACKINGVERSION.svg]] * [[:commons:Image:Aspartame.svg]] As a result of this bug, many characters are converted into paths. This on the one hand increases file size and on the other hand makes it different to later modify that files.
Upstream feature request: http://bugzilla.gnome.org/show_bug.cgi?id=340047
Even kerning/letter spacing is ignored. see [[:commons:Image:New Delhi map.svg]], the street names had different kerning but everything is lost in the png.
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.
For the example, [[Bugzilla:13494]] apply too.
[[:commons:Image:FMCW_Doppler_radar.svg#filehistory]] see 1st version (3rd is identical, 2nd is the workaround) 1. The baseline shift of delta-t is ignored. 2. Indices nested in <text ... as <tspan style="baseline-shift:sub;font-size:0.85em"... are not rendered at all. That may be an existing other bug, which I missed, however, in the tracking [[Bugzilla:8901]].
The tspan issue is #23574, tracked in #8901.
giving SVG bugs back to the pool.
Migrating bug to Wikimedia > SVG rendering Still not fixed upstream.
I propose to work around this until all bugs have been resolved by using a different SVG renderer on Commons, maybe only for those problematic SVGs? Maybe let the uploader decide which engine? One that would work and is OSS: inkview as part of the inkscape package.
(In reply to comment #10) > I propose to work around this until all bugs have been resolved by using a > different SVG renderer on Commons, maybe only for those problematic SVGs? Maybe > let the uploader decide which engine? One that would work and is OSS: inkview > as part of the inkscape package. That should be another bug report, or better, a discussion on the wikitech-l mailing list :-]
These are now all fixed (after a purge)
(In reply to comment #12) > These are now all fixed (after a purge) Please do not close bugs with images that are fixed with a workaround!? Sorry I don`t see anything fixed. Most given examples have NOT a baseline-shift, but this: * [[:File:Diazepam-BUGTRACKINGVERSION.svg]] * https://upload.wikimedia.org/wikipedia/commons/thumb/archive/8/84/20070517212855!Radical_benzil.svg/240px-Radical_benzil.svg.png
Not forgot that Firefox also don't support this: https://bugzilla.mozilla.org/show_bug.cgi?id=308338
Ah didn't notice the baseline-shift. Was distracted by the comments about tspan's in the later comments (which IS fixed).
(In reply to comment #15) Upstream as: https://bugzilla.gnome.org/show_bug.cgi?id=340047
Just to emphasise (since this bug has twice been closed) that this bug has not been fixed. Here is an example with a permalink from the history in Wikipedia; https://upload.wikimedia.org/wikipedia/en/archive/f/ff/20140529085551!H_parameters_dependent_sources.svg and here is what it should look like https://upload.wikimedia.org/wikipedia/en/archive/f/ff/20140529095405!H_parameters_dependent_sources.svg None of the subscripts have been rendered correctly. They are all just rendered as small text. The workaraound is to convert text objects to paths. This is not a fix and is not a good practice since it means that only the original uploader is able to easily modify the text at a later date (and even they might have problems if they didn't keep a version of the file with text objects).
(In reply to Spinningspark from comment #17) > Just to emphasise (since this bug has twice been closed) Once only, not twice. > that this bug has not been fixed. That's why it's still in an open status. :) Work on fixing should happen in https://bugzilla.gnome.org/show_bug.cgi?id=340047
Sorry for causing everyone on the e-mail list to get pinged, but the bug has been open for eight years and there has been no activity on this page for a year and a half. The svg format is supposed to be a preferred format but I frequently render images as jpg before uploading due to various rendering issues on Wikimedia. Given that the bug is causing material to be uploaded in a non-preferred format I thought the bug could do with a bump. Plus, I provided a direct link to a problematic version, which most of the other links on this page do not do.
@Spinningspark Our bug is tracking the issue reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=340047 . A way to move along would be to contact upstream authors, provide them example files and have them fix the issue. There is not much we can do on our side :/
