SVG rasterisation and management on Wikimedia sites (tracking)
Open, NormalPublic

Description

Author: robchur

Description:
Tracking bug for issues with SVG rasterisation on Wikimedia sites due to installation and configuration issues;


Version: unspecified
Severity: normal
See Also: T5593

Details

Reference
bz8901

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedNone
OpenNone
OpenNone
InvalidNone
DeclinedArielGlenn
OpenNone
ResolvedNone
OpenNone
OpenNone
OpenNone
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedReedy
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedmark
ResolvedArielGlenn
DuplicateNone
ResolvedNone
OpenNone
ResolvedArielGlenn
Resolvedtstarling
ResolvedAklapper
ResolvedNone
ResolvedNone
ResolvedAklapper
OpenNone
OpenNone
OpenNone
ResolvedNone
OpenNone
ResolvedNone
InvalidNone
DeclinedNone
DeclinedNone
ResolvedAklapper
OpenNone
ResolvedNone
ResolvedNone
OpenNone
ResolvedNone
OpenNone
OpenNone
DeclinedNone
OpenNone
InvalidNone
ResolvedAklapper
ResolvedAklapper
DeclinedNone
DeclinedNone
ResolvedAklapper
ResolvedNone
DeclinedNone
Resolvedmatmarex
ResolvedMoritzMuehlenhoff
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz8901.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Feb 6 2007, 3:56 PM
daniel added a comment.Feb 6 2007, 8:57 PM

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

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.

brion added a comment.Aug 3 2009, 4:53 PM

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. ***
TheDJ added a comment.Oct 26 2012, 2:44 PM

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.

brion added a comment.Sep 17 2013, 5:04 PM

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. :-)

fbstj updated the task description. (Show Details)
fbstj set Security to None.

Why? That always existed.

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

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

I guess the project does not cover "management"?