Page MenuHomePhabricator

[DO NOT USE] SVG rasterisation and management on Wikimedia sites (tracking)
Closed, InvalidPublic

Description

See T10901#4976138 below.


Original task description:

Author: robchur

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

Details

Reference
bz8901

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 9:34 PM
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"?

Aklapper closed this task as Invalid.Feb 22 2019, 3:13 PM
Aklapper lowered the priority of this task from Normal to Lowest.

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

Tracking tasks (and also project tags) have a cost: Someone needs to regularly update their subtasks, otherwise they become incomplete and rather useless. Nobody has added any subtask to this task for 3 ½ years. The currently 65 subtasks of this task are a very small subset of the currently 648 tasks which have the string 'svg' in their task title. Furthermore, only 3 of the 65 subtasks here do not have either the project tag Wikimedia-SVG-rendering or MediaWiki-File-management.

The huge majority of SVG related tasks can be found by looking into Wikimedia-SVG-rendering.
Some (mostly old ones, potentially predating the Wikimedia-SVG-rendering tag) can be found under MediaWiki-File-management.
Thumbnailing (=creating bitmap images from other image file formats, SVG being only one of them) is nowadays handled by Thumbor (and relatedly T43371: Thumbnail/imagescaler (tracking) which is a task that might also get superseded as its subtasks are Thumbor issues nowadays).

Given these reasons I'm boldly declining this tracking task as I described ways to get way more complete lists of SVG rasterisation and management related tasks.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptFeb 22 2019, 3:13 PM
Aklapper renamed this task from SVG rasterisation and management on Wikimedia sites (tracking) to [DO NOT USE] SVG rasterisation and management on Wikimedia sites (tracking).Feb 22 2019, 3:14 PM
Aklapper updated the task description. (Show Details)
Phabricator_maintenance removed subtasks: T111815: SVG files larger than 10 MB cannot be thumbnailed, T76852: OOUI's svgo-optimized SVG files are not compatible with rsvg's broken SVG parsing, T69733: Error creating thumbnail: Multiple SVG files are only allowed for PDF and (E)PS output., T58508: Default "Other resolutions" options do not make sense for SVG, T51061: Lines missing in thumbnail of SVG diagram, T45648: Install package fonts-farsiweb on image scalers, T45640: SVG to PNG: font rendering problem in Persian, T40589: Rendering of SVG text too large (font sans), T43427: rsvg does not support marker styling, T43426: hsl colors not supported by rsvg, T43423: CSS child selector not supported by rsvg, T43425: rsvg does not support the font shorthand style property, T43422: rsvg cannot handle classes/ids with cyrillic alphabet when styling, T43424: flowRoot (defined only in deprecated SVG 1.2 draft) not supported by rsvg, T48540: SVG file rasterization uses wrong green color (#00FF00 instead of #008000) due to libcroco bug, T40271: Review and deploy SVGEdit extension to Wikimedia wikis, T36792: rsvg: SVG Text font-size rendered incorrectly, T33122: rsvg on scaler does not support styling the root element, T44566: Diffs between SVG uploads should display differences in code, T29356: No gradient visible in SVG rendered as PNG at large sizes, T23982: Reader feedback generates bad png graphs on enwikinews, T25643: Allow alternative declaration of SVG fonts (font-family="'FontName-Bold'" in addition to: font-family="Font name" font-weight="bold"), T27403: OOM when rendering SVGs, T25574: SVGs with tspan that have multiple x or y coordinates don't render properly, T32033: stroke-dasharray in PNG thumbnails does not support spaces as separators, T26916: rsvg does not support styling of tspans, T26768: rendered SVG images should use sRGB chunk, T35245: Incorrect text positioning/kerning in SVG rendering (text/tspan x/y, dx/dy attribute; upstream), T29832: Only first gradient in the SVG file seems to be processed, T18368: [SVG Rendering] Worsening of font rendering quality, T18185: rsvg error when generating thumbnail "no fonts found", T21224: SVG rendering: problems with paths beyond page extent, T19845: DejaVu Sans font renders incorrectly in SVG thumbnails, T18014: Thumbnails not generated for SVGs with non-ASCII characters, T21053: Some arrows direction in SVG are wrongly rendered, T20936: Hairline / seam in SVG rendering, T14274: Svg start and end markers are not rendered correctly, T11110: SVG element missing when image is downsized, T20900: misplaced text in rendered SVG, T26000: Update rsvg so styling SVG images with CSS works properly on Commons, T10895: Incorrect rendering of stretched text in svg -> png conversion, T12469: SVG -PNG conversion error in Wikimedia?, T10797: Some greek characters don't render in SVG, T10666: SVG with CJK fonts doesn't render CJK text, T10552: SVG renderer does not support the <pattern> tag, T10566: Thumbnail rendering of SVGs broken, T12207: Upgrade librsvg to 2.22.2, T7257: librsvg rendering buggy wrt color and fill attributes, T8834: Add "Other resolutions"-links to .svg files as well (PNG thumbnails), T19187: SVG to PNG conversion broken for text, T19174: SVG rendering: stacked tspan elements rendered in incorrect order, T7108: SVG: attributes not inherited from root svg element, T15495: SVG text-decoration (including underlining) doesn't render, T15494: SVG font scaling bug ("%" and "em" misconverted to "px"), T12045: SVG image display, T20463: SVG thumbnailing issues - part of the image with <pattern> not rendered, T6947: SVGZ (gzipped SVG) support, T15387: SVG: Missing implementation for textLength, T8417: Incorrect SVG rasterisation, T8250: PNG replacement image for .SVG does not show transparency gradient correctly, T9914: Strange behaviour with SVG figure, T15069: SVG rendering and image uploads, T11420: textPath is not supported by rsvg, T7792: rsvg does not render baseline-shift correctly (<percentage> and <length>), T5769: Fonts are off in rasterized SVG images on wikimedia sites.Feb 22 2019, 3:15 PM