Just for the record: the rsvg version currently installed on the wmf servers is
allegedly 2.14.0

Open librsvg bugs: http://tinyurl.com/2c9ahr
librsvg home page: http://librsvg.sourceforge.net/

rupert wrote:

Very disappointed that my diagram doesn't render correctly at the smaller size:

http://upload.wikimedia.org/wikipedia/commons/thumb/0/05/Fontan_procedure.svg/800px-Fontan_procedure.svg.png
http://upload.wikimedia.org/wikipedia/commons/thumb/0/05/Fontan_procedure.svg/350px-Fontan_procedure.svg.png

I installed rsvg on my home computer and reproduced the behaviour, confirming that this is a problem with rsvg itself, rather than its configuration on Wikipedia. I've reported this on the GNOME bugzilla. (http://bugzilla.gnome.org/show_bug.cgi?id=574544) When they fix this bug, please may the latest version of rsvg be put on the Wikimedia Foundation servers?

One work around in the interim would be to use rsvg to render the picture at the "native" size and then scale it to the desired size using convert. Could this be done temporarily? You never know, it may help with other SVG bugs!

Many thanks,

Rupert Millard

Adding 'tracking' keyword.

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.

SVG text rendering is FUBAR since 2 years, if the administration guys cant fix it, use an Batik server, please

rainald.koch wrote:

(In reply to comment #6)

SVG text rendering is FUBAR since 2 years, if the administration guys cant fix
it, use an Batik server, please

18 month later, still a horror for users casually providing svg images. Please take some money to have this fixed soon.

rainald.koch wrote:

should be blocked also by #30033

giving SVG bugs back to the pool... including the tracking bug.

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.

• Bug 37129 has been marked as a duplicate of this bug. ***

The tracking category for images on Commons that are affected by any of these bugs is https://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug

After the last rsvg update a couple of major problems seem to have been solved. I have however also been able to pinpoint a few problems that we did not yet know about, or at least had not been registered in our tracker.

Some of these still need filing upstream, if anyone would care to assist with that.

I'm slightly expanding the scope of this tracking bug to cover also other questions about SVG files like whether to rasterise them at all, how to visualise raster images, how to handle the SVG source itself in MediaWiki; I considered creating a separate tracking bug, blocker of bug 54213, but the borders between that and this would have been too thin IMHO.

It might be time to start building an RfC for 'determine next stage(s) of SVG handling'; it may be easier to track overall status on a wiki page.

Within Bugzilla we should do a couple things for sure:

• split out the "rsvg rendering" bugs from the fundamental bugs
• find the most important-looking remaining issues and see what we have to do about them

A few forward-facing questions:

• should SVG source be editable on-wiki like a page? Or is it fine to stick with the upload interface, knowing that editing widgets can piggyback on that? (an editor widget could easily expose source, and use the upload interface to save)
• what sort of processing support do we need in addition to serving files direct, if any?
  • compression?
  • minimizing?
  • language filtering?
  • parsing links?
  • injecting wikitext?
  • LTR<->RTL flipping?
• what sort of editing tools do we need?
  • specialized tools like chart generators/editors? How will we attach a 'type' to the file?
  • general vector editors like SVGEdit?
  • how do we integrate these tools into VE?
  • do we need both desktop and mobile UIs?
• if we serve SVGs directly to browsers in the future, do we need tools to assist with file size?
  • XML minimization?
  • decimating extra digits on coordinates?
  • decimating points in detailed paths?
• do we need/want animations support?
  • is browser support for SMIL consistent, or do we need fallbacks?
  • what about non-SVG browsers? fallback content, or generate something?
  • what about printing mode? force fallback content, or?

Whew, that's enough crazy thoughts for now. :)

rainald.koch wrote:

(In reply to comment #14)

Several of your thoughts, Brian, would just vanish if only small SVG sources are served directly. Authors who are keen to have their SVGs served directly would strive toward smaller code size. A positive side effect - or rather the main advantage: Code that is comprehensible and editable by humans.

(In reply to comment #14)

It might be time to start building an RfC for 'determine next stage(s) of SVG
handling'; it may be easier to track overall status on a wiki page.

Yep. Looks like you're well on your way. :-)

Superseded by Wikimedia-SVG-rendering?

In T10901#1143993, @Ricordisamoa wrote:

Superseded by Wikimedia-SVG-rendering?

Why? That always existed.

Then what's the difference between this task and that project?

In T10901#1148437, @Aklapper wrote:

Then what's the difference between this task and that project?

I guess the project does not cover "management"?