rhododendronbusch wrote:

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

arunganesh03 wrote:

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.

rainald.koch wrote:

[[: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]].

rainald.koch wrote:

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.

ralf wrote:

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 :/

I've created a patch adding support for baseline-shift properties "sub/super/baseline". This would fix the issue as this are the important types of baseline shift.
(PS see gnome bugzilla for details. Its not in added to libRsvg yet)

In T7792#1217781, @Menner wrote:

I've created a patch adding support for baseline-shift properties "sub/super/baseline". This would fix the issue as this are the important types of baseline shift.

Thank you!

Note the original example file http://commons.wikimedia.org/wiki/Image:Fluoxetine_.svg has been deleted on commons.

@Menner would you mind pointing to the patch you wrote?

See attachements of https://bugzilla.gnome.org/show_bug.cgi?id=340047#c3 on Gnome Bugzilla

In T7792#1217843, @hashar wrote:

Note the original example file http://commons.wikimedia.org/wiki/Image:Fluoxetine_.svg has been deleted on commons.

It looks like it was a duplicate of https://commons.wikimedia.org/wiki/File:Fluoxetine_2.svg, which still uses baseline-shift="sub".

In upstream version 2.40.13,

@Menner added basic support for the "baseline-shift" attribute in text objects. We support "sub", "super", and plain "baseline", so you can at least have subscripts and superscripts for formulas and such. There is no support for percentages or explicit lengths yet. https://bugzilla.gnome.org/show_bug.cgi?id=340047

https://bugzilla.gnome.org/show_bug.cgi?id=760191 tracks supporting baseline-shift via font size percentage and/or explicit length.

In T7792#2315213, @Aklapper wrote:

In upstream version 2.40.13,

@Menner added basic support for the "baseline-shift" attribute in text objects. We support "sub", "super", and plain "baseline", so you can at least have subscripts and superscripts for formulas and such. There is no support for percentages or explicit lengths yet. https://bugzilla.gnome.org/show_bug.cgi?id=340047

https://bugzilla.gnome.org/show_bug.cgi?id=760191 tracks supporting baseline-shift via font size percentage and/or explicit length.

Here is a example SVG that doesn't render correctly due to the issue listed above.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg height="70px" width="200px" xmlns="http://www.w3.org/2000/svg" version="1.1">
<style type="text/css">
.sub{
	baseline-shift:-5px;
	font-size:12pt;
}
</style>
<!-- Example #1 -->
<text x="20" y="20" font-size="22">
    <tspan>N<tspan baseline-shift="-5px" font-size="12">2</tspan></tspan>
</text>

<!-- Example #2 -->
<text x="20" y="50" font-size="22">
    <tspan>ThO<tspan class="sub">2</tspan>,ThN,Th<tspan class="sub">3</tspan>N<tspan class="sub">4</tspan></tspan>
</text>
</svg>

Most of the example files cited in this bug have had workarounds applied, so I changed the description to point to a version that is just for this bug.

We deployed 2.40.18.

https://upload.wikimedia.org/wikipedia/commons/1/16/Diazepam-BUGTRACKINGVERSION.svg to me neither looks like "same size" nor subtext.

Hence unsure if this is resolved. Someone having an opinion?

This is why all SVG bugs need screenshots :P

The example I provided above still doesn't render correctly, see attachment.

@Offnfopt: Where to see your example? Please always provide URLs for testcases.

The PNG rendered on the server at https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/Diazepam-BUGTRACKINGVERSION.svg/868px-Diazepam-BUGTRACKINGVERSION.svg.png looks correct:

The SVG itself does not in Firefox, but in Chromium: https://upload.wikimedia.org/wikipedia/commons/1/16/Diazepam-BUGTRACKINGVERSION.svg
But that is up to your browser's SVG rendering engine, not to the librsvg software on Wikimedia servers.

Which makes this bug resolved, in my opinion, as it's nothing we can influence.

I uploaded the SVG file as a attachment in this thread. It doesn't have a permanent URL on commons, you can test the issue by uploading the file to File:Test.svg.

The file you linked to uses baseline-shift="sub", if you read the bugzilla (340047) you'll see the patch applied only provides support for a few of the options of baseline-shift, i.e. sub, super and baseline. So the first example in this thread is fixed, but the example I posted isn't fixed. My example uses baseline-shift="-5px"

The patch did not add support for numerical values i.e. percentages and length values ( https://www.w3.org/TR/SVG/text.html#BaselineShiftProperty ).

The last post of the bugzilla links to a new bugzilla report for this issue, bugzilla (760191).

So while the status of baseline-shift has improved, it is not resolved until there is support for percentages and length values.

Ah. Thanks a lot for clarifying!

This is one of the lower bugs I know. As in the "Non-goals of librsvg" stays: "Implement every single SVG feature that is in the spec." On the other hand, even industrial-strength SVG rendering machinery in modern web browsers, don't supports this baseline-shift (as Firefox and Edge).

(removed comment, my mistake)

Sorry, did not see the example https://phabricator.wikimedia.org/T7792#2491164

This is fixed upstream in librsvg 2.48.1