I don't see the blocker there. The buildd page says that rustc compiles on every officially supported Debian architecture, the only ones that don't compile are a few of the unofficial ports. Maybe it has changed since the mailing list discussion?

Finally I tried myself in backporting current librsvg. The problem is not the core package Rust but the submodule Cargo. It's only available in upcoming Debian 10 or later...

@JoKalliauer
Ok haven't looked at the details that much.

In T193352#4166886, @Aklapper wrote:

We cannot easily upgrade librsvg on our Debian servers from 2.40 to 2.42 as 2.42.x requires Rust. See https://buildd.debian.org/status/package.php?p=rustc&suite=unstable and the discussion in https://mail.gnome.org/archives/desktop-devel-list/2017-December/msg00072.html

The updated (archived) version of the links I posted above:
dewiki chart
enwiki chart
writeup (in German)

The bug seems already present in 2.40.2. Commons SVG Checker shows the same and runs on older tool servers.

Looks good from here. The only thing I'm curious now is that Times is not substitued by DejaVu Serif as on my Debian system last friday (not at my hands yet). On Wikimedia it is obviously not:
https://commons.wikimedia.org/wiki/File:Test_T139543.svg

One more thing. Did you reboot? Otherwise try:

What is the result of fc-match?

In T139543#2465507, @MoritzMuehlenhoff wrote:

I've added such a file locally to one of the new jessie-based scalers and that seems to fix it, result is at:
https://people.wikimedia.org/~jmm/svg/alias-jessie-new.png

I'll puppetise the config file next.

And so the problem starts. Librsvg expects these decisions on global level not per application/desktop environment.

BTW: How do you invoke rsvg-convert / librsvg on image scalers?

I've install a Debian Jessie from netinstall on a local virtual machine and added Wikimedia repositories for backport: https://wikitech.wikimedia.org/wiki/APT_repository

From outside it is difficult to estimate when fallback fonts are use. Maybe this is something to look at since fallback fonts seem to be affected only: https://wiki.archlinux.org/index.php/Font_configuration#EmbeddedBitmap

Besides Pango the library Harfbuzz is mention in the librsvg bugreport on Gnome, too.

It's heuristic to identify important tasks. One topic is minimize issues with fonts since their handling is diffcult even in a world without bugs. Another source are the archives of graphics village pump on Wikimedia. The last critiria is thinking about what issue would annoy beginners most.

@MoritzMuehlenhoff: Please consider remarks about Pango in T40010 as well. To me they sound more plausible.

Please keep in mind that Linux implements font-substitution and has many fonts not installed. There is a fc-list, but not sure if it is valid now. Font-substitution is configuration dependant.

@MoritzMuehlenhoff: Look at the file history both have work arounds applied. You may test old version on

Please be patient and see T112421 in the meantime.

Ping @MoritzMuehlenhoff : Noticed my last comment?

&action=purge produces random results. Once with showing known bugs and the other time without. Try out on:
File:Rsvg_marker_element_bug.svg

@Tgr: be patient. Now [[File:Rsvg marker element bug.svg]] is borken again too. Although it work fine recently.

Recent Debain has librsvg 2.40.16 ready for backport too. https://packages.debian.org/source/stretch/librsvg

I suspect this is not a recent issue and has always been present.

Regression from 2.40.11 has been fixed in recent 2.40.16. I've compiled it on Ubuntu 14.04 and I've seen no issues on a short test.

Evaluating a SVG renderer is not a simple task. You need to consider all kind of side effects and find the real needs. I recommend to use this task to find out which are the metrics for such an evaluation.

T40010 is a request for evaluation. Since there hasn't been a evaluation between available options I wouldn't call it a blocker. In fact T40010 is a subset of this Task. Improving rendering may lead to evaluate alternative options.

Looks okay with my local build from main/latest of librsvg plus bugfix for a new bug. Marker code has been rewritten recently. But I still get a Null pointer assertion from GTK.

The diff algorithm does already evaluate context information[1]. Why not collection context information about sections while creating a diff. It is not uncommon as gnu pages say[2]. In a second step this information can be used by the watchlist code to evaluated observed section. At best give the whole section context like: == H1 === H2 ==== H3

T97758 sounds identical. If I don't forget it I'll double check this later as it has been fixed upstream.

Oh, I think not but at least partly. Need to try out this, but won't have time until 31. October.

Partly addressed by https://bugzilla.gnome.org/show_bug.cgi?id=664533

Fix included in version 2.40.10 which got released yet. Now need to backport or need to wait for the distribution used on Wikimedia servers to provide that version....

I cannot reproduce this with librsvg 2.36.4 or 2.40.9 but only on Wikipedia or https://tools.wmflabs.org/svgcheck/index.php with librsvg 2.36.1.

The original link to the broken SVG has been deleted.

What is the max size limit?

Is this really a bug of SVG rendering. Consider SVG is not a WYSIWYG tool. Used space by letters depends on font rendering. Wikimedia uses font hinting which results in rounding letter position to pixel scale.

Close this bug.

Sounds like there is an evaluation to remove librsvg and replace it by browser side rastering of SVG? Please inform me if there is a schedule because I plan to fix some bugs of librsvg but on the other hand I could save my time for other tasks.

The result to text elements is equal to multiplying font-size with scaling of previous path elements which leads to font hinting and upscaling text again to the intended font-size.

This bug at gnome shows also an issue with a matrix element: https://bugzilla.gnome.org/show_bug.cgi?id=634324

I can clearly reproduce when the reported issue takes place. It like comes from the two path elements between the two text elements containing main body. I suspect a wild pointer problem in the matrix attribute.

Forget this I misunderstood the initial description

Remark: In SVG2 there will be a attribute called extend. It defines the width of a textline and support a similar feature.
see https://svgwg.org/svg2-draft/text.html#TextLayoutContentArea

These libRSVG bugs are that simple to fix. I've patched it myself instead of pressuring someone and explaining me. See bugzilla above.

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

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)

This test suit is a good starting point to evaluate the quality of a SVG rasterer. One can easily write a small shell script to execute comparisons between different solutions.

There had been an effort to support development of libRSVG which obviously fell asleep.
http://strategy.wikimedia.org/wiki/Proposal:Librsvg_development_funding

I see unresolved security issues since SVG may contain JS script and references to external webpages. There must be some sort of filter for that kind of stuff otherwise it is a huge entry point for hackers.