1081338 - Enable conversion of svg images so that png previews are available

Status: RESOLVED FIXED

(Websites :: wiki.mozilla.org, defect)

Description

[Christie Koehler [:ckoehler]]

svg images are supported on the wiki, but display using the generic svn icon:
https://wiki.mozilla.org/skins/common/images/icons/fileicon-svg.png

Let's explore enabling png preview of svg images by changing the value of $wgSVGConverters in LocalSettings.php.

The value will depend on what's available on the webserver. Possibly ImageMagick?

Relevant documentation:
https://www.mediawiki.org/wiki/Manual:$wgSVGConverter
https://www.mediawiki.org/wiki/Manual:$wgSVGConverters
https://www.mediawiki.org/wiki/Manual:$wgSVGConverterPath

I'm not entirely sure of the performance impact of enabling this conversion, so we should be sure to test.

Comment 1

[C. Liang [:cyliang]]

In dev, I tested two different converters (ImageMagick and rsvg).  The only setting I needed to change was $wgSVGConverter, e.g.:

  $wgSVGConverter = 'ImageMagick';

Testing showed that both ImageMagick and rsvg had can convert some, but not all, SVG files  present in the dev instance.  It doesn't look like there is an update for ImageMagick (6.5.4.7-7.el6_5) in the usual repos; there may be bugfixes for librsvg2 (2.26.0-6 -> 2.26.0-14).


Reading through http://www.mediawiki.org/wiki/Manual:Image_administration#SVG, it looks like ImageMagick "is the default, but avoid it if possible. However, it does work."  There are some suggestions for other converters.  I've confirmed that there are packages available for the following:

    inkscape  0.48.4-1
    batik     1.7-8.5

batik will incur some overhead as it is Java based.  


Looking for opinions RE: pursuing another converter versus trying to get a newer version of the converter we have versus waiting to see what happens if we have more SVGs to test with (as there are more SVGs present on stage).  =)

Comment 2

[Christie Koehler [:ckoehler]]

It sounds like rsvg is the converter recommended/used by wikimedia. Should we try that in stage where there are more svg files to test with?

Another option would be to enable direct rendering of svg in browser with this extension:
http://www.mediawiki.org/wiki/Extension:NativeSvgHandler

Comment 3

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Christie Koehler [:ckoehler] from comment #2)
> It sounds like rsvg is the converter recommended/used by wikimedia. Should
> we try that in stage where there are more svg files to test with?

If it's good enough for Wikimedia, it's probably good enough for us.

> Another option would be to enable direct rendering of svg in browser with
> this extension:
> http://www.mediawiki.org/wiki/Extension:NativeSvgHandler

If this appears to be a route we want to take, it should happen in a different bug.

Comment 4

[C. Liang [:cyliang]]

Pushed the changes to staging, using rsvg as the renderer.  In a quick test of five SVG files, I got three to render, one came out as a black square, and one came back as "this file has been deleted".

Comment 5

[Christie Koehler [:ckoehler]]

Looking at the svgs on Stage:
https://wiki.allizom.org/index.php?title=Special%3AListFiles&limit=50&ilsearch=svg&user=

Most all svgs seem to render. Most, if not all, the ones that don't are test images uploaded by a bug bounty person and probably aren't actual images in the first place.

Comment 6

[C. Liang [:cyliang]]

This change has been pushed into production.  As theorized, the SVG preview images are built upon visiting the SVG page itself and forcing a reload (e.g. go to https://wiki.mozilla.org/File:<foo>.svg and force-reload).

As with stage, some images aren't building proper previews.  It may be a matter of how strict/liberal one's SVG rendering software is.