Last modified: 2014-07-09 15:14:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8901 - (svg) SVG rasterisation and management on Wikimedia sites (tracking)
(svg)
SVG rasterisation and management on Wikimedia sites (tracking)
Status: NEW
Product: Wikimedia
Classification: Unclassified
SVG rendering (Other open bugs)
unspecified
All All
: Normal normal with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
Depends on: 4947 5792 6250 8552 9110 9420 13387 16368 17845 18463 18936 21982 23643 24768 27356 27832 38271 38589 41422 41423 41424 41425 41426 41427 42566 43640 49061 3769 5108 5257 6417 6834 7914 8566 8666 8797 8895 10045 10207 10469 12274 13069 13494 13495 16014 16185 17174 17187 18900 19053 19224 23574 24000 24916 25403 30033 31122 33245 34792 43648 46540 56508 67733
Blocks: tracking 41371 multimedia 54213
  Show dependency treegraph
 
Reported: 2007-02-06 15:56 UTC by Rob Church
Modified: 2014-07-09 15:14 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rob Church 2007-02-06 15:56:30 UTC
Tracking bug for issues with SVG rasterisation on Wikimedia sites due to
installation and configuration issues;
Comment 1 Daniel Kinzler 2007-02-06 20:57:35 UTC
Just for the record: the rsvg version currently installed on the wmf servers is
allegedly 2.14.0 
Comment 2 Tim Starling 2007-12-12 05:16:29 UTC
Open librsvg bugs: http://tinyurl.com/2c9ahr
librsvg home page: http://librsvg.sourceforge.net/
Comment 3 Rupert Millard 2009-03-08 12:43:51 UTC
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
Comment 4 Andrew Garrett 2009-07-29 16:38:52 UTC
Adding 'tracking' keyword.
Comment 5 Brion Vibber 2009-08-03 16:53:48 UTC
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.
Comment 6 Martin Fischer 2009-08-29 19:18:16 UTC
SVG text rendering is FUBAR since 2 years, if the administration guys cant fix it, use an Batik server, please
Comment 7 Rainald Koch 2011-03-15 11:09:56 UTC
(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.
Comment 8 Rainald Koch 2011-07-24 00:45:53 UTC
should be blocked also by #30033
Comment 9 Ariel T. Glenn 2011-09-18 09:20:32 UTC
giving SVG bugs back to the pool... including the tracking bug.
Comment 10 ralf 2012-03-12 16:33:31 UTC
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.
Comment 11 Bawolff (Brian Wolff) 2012-06-26 12:08:29 UTC
*** Bug 37129 has been marked as a duplicate of this bug. ***
Comment 12 Derk-Jan Hartman 2012-10-26 14:44:28 UTC
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.
Comment 13 Nemo 2013-09-17 09:21:48 UTC
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.
Comment 14 Brion Vibber 2013-09-17 17:04:08 UTC
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. :)
Comment 15 Rainald Koch 2013-09-24 00:41:39 UTC
(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.
Comment 16 MZMcBride 2013-09-24 04:38:25 UTC
(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. :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links