SVG image support

This page is kept for historical interest. Its content is outdated or may be wrong. You may find more up-to-date information at on the www.mediawiki.org website.

Example of embedded SVG image with rendering

SVG uploading is currently enabled. See also mw:Category:SVG.

(The flag image shown here is actually a PNG rendering from the SVG data.)

It has been suggested on the mailing lists from time to time that we provide better support for SVG vector graphics as inline images. This would be better for charts, graphs, and diagrams that might need to be tweaked, as the SVG could be saved, altered by hand or in an SVG-capable vector editor, and simply re-uploaded without requiring that the original author do the tweak, provide the original vector file as a second upload, or requiring subsequent editors to own a proprietary graphics editor.

Additionally, vector images scale better when printed; a "printable version" can rasterize at a higher resolution for browsers that don't grok SVG natively.

For rasterized images produced by MediaWiki's SVG rendering engine for display in articles, the free code image format is PNG.

Possible kinds of SVG support

There are several levels of SVG support that we might hope for in Wikipedia.

Simple storage for download. This would permit users creating diagrams to upload “source” along with the PNG so that, for example, people could translate all the text to a new language. Currently disabled for fear of encountering an SVG image that contains malware.
Storage and rendering on the server. This would save time and trouble for uploaders, especially since scaling raster diagrams is a pretty dubious operation. Currently implemented and active. Requires a usable batch-rendering program on the server; no free program seems to do an adequate job of supporting SVG at the moment (although en:Inkscape is promising, since many users will be using it to produce images, and it's free). Malware is a concern — not that Inkscape or en:librsvg have any known vulnerabilities, since they do not support scripting.
Serving SVG code untouched for client-side rendering. This could save bandwidth in many cases (and use much more if used blindly) and be convenient for users with the correct plugin or Web browser that supports SVG natively. It would also open the door to animated, interactive, scripted SVG on Wikipedia pages — whether this is a good or a bad thing.
Serving SVG code untouched and allowing it to be edited wiki-wise. Might be useful for small fixes (such as colour changes or spelling fixes) to simple files or for translation. There's a simple plugin for this.
Compression. A patch to enable SVGZ (GZipped SVG) images is available. Support has not yet been integrated into the official MediaWiki distribution.

How it works

This shouldn't require any new wiki markup variations, just a new interpretation for a special case of image links.

The object tag seems to be tailor-made for this kind of situation. We should be able to do something like:

<object data="/upload/foo.svg" type="image/svg+xml" style="width: 2in; height: 2in">
  <img src="/svgcache/foo.png" alt="Alt text" width="144" height="144" />
</object>

(Perhaps swapping a low-resolution for a high-resolution PNG in printer-friendly mode.) A compliant user agent should ignore the image if it can render the object (either internally or by a plugin), and show the image if it can't render the object. Preliminary testing indicates that this should work on Microsoft Internet Explorer, Mozilla and Konqueror. It may be problematic with older browsers, such as Konqueror 3.0 (the bane of my existence — it's almost great, but mucks up a few things so badly I find it shocking), which renders a blank, empty object tag and ignores the image tag.

See ~~Media:SVG test demo.html~~ for an example. (This will crash Mozilla on Linux if you use the Adobe SVG viewer plugin; it's obsolete and broken.) If you're seeing the SVG version, the star will appear red instead of green.

…(on my Galeon browser, it shows a text area with the XML code in it -- Tim Hemel)

Turns out the server wasn't set up with the right mime type; this may have confused poor Galeon. Try again and see… --Brion VIBBER 20:51 25 May 2003 (UTC)

Galeon still only shows a text area … looks like the HTML source.

FireFox (with default installation, no SVG extensions or anything) just shows text source, too. When I copy and paste into an html file I get a broken image. Oh, I guess because it is a local link. If I copy, paste, and edit them to complete links, it shows a green flag. - Omegatron 20:49, 16 Mar 2004 (UTC)

Yes. Wrong MIME-type. As mentioned by Omegatron copy'n paste this

<?xml version="1.0" charset="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
 <head>
  <title>SVG test demo</title>
 </head>
 <body>
  <p>
   This should show an SVG or PNG image of the
   <a href="http://www.wikipedia.org/wiki/Esperanto_flag">Esperanto flag</a>,
   depending on whether your browser supports SVG objects, or alternate
   thumbnail images generated in PNG format on the Wikimedia Commons upload site.
  </p>
  <p>
   <a
    href="http://commons.wikimedia.org/wiki/Image:Flag_of_Esperanto.svg"
    title="Flag of Esperanto"
   ><object
     type="image/svg+xml"
     data="http://upload.wikimedia.org/wikipedia/commons/f/f5/Flag_of_Esperanto.svg"
     style="width:400px;height:266px;border:0"
    ><img
      src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f5/Flag_of_Esperanto.svg/400px-Flag_of_Esperanto.svg.png"
      alt="Flag of Esperanto"
      style="width:400px;height:266px;border:0"
   /></object></a>
  </p>
  <p>
   See <a href="http://meta.wikipedia.org/wiki/SVG_image_support">SVG image
   support</a> on meta for work in progress...
  </p>
 </body>
</html>

into a new text file and save it as something.htm. This should work, as for local files usually no MIME-type is required. --SteffenB 16:46, 23 Mar 2004 (UTC)

you can't fix this on the other end? - Omegatron

Fixed the URL to point to something valid. —Ævar Arnfjörð Bjarmason 13:44, 5 December 2005 (UTC)[reply]

Fixed for validated conformance to the "XHTML 1.0 strict" content model, and validated conformance to CSS 1.0.

Also fixed the alternate bitmap image in PNG format (corrected URL), when SVG is not natively supported in the browser. This syntax would save bandwidth and processing time on the Commons upload servers, by enabling effective support of SVG directly in browsers without using the SVG-to-PNG convertor and Commons Upload caches for thumbnails.

Note how size parameters are provided: although thumbnails (and the Wiki syntax) only require specifying the image width, for compatibility, we must provide also the image height for the object and for the image, using a CSS "height:" property. We also fix the border width to 0 here (otherwise, the link would add a plain 2px border whose color is changing depending on the current status of the link: normal, visited, hovered). fr:Verdy p 16:40, 20 October 2006 (UTC)

Rasterizing

There's a PHP class for SVG-to-PNG conversion using Batik, but this sounds hackish, fragile, and resource-hungry. Batik also has a command line SVG to PNG client. Batik supports all the static features of SVG and some of the dynamic.

The only rasterizer that reasonably works is Batik. RSVG, ImageMagick and Sodipodi are broken. Taw 11:28, 8 Oct 2003 (UTC)

Inkscape has revived the Sodipodi project, and the export to PNG is brilliant. You can invoke it from the command line with inkscape filename.svg --export-png=filename.png -w600 -h400 Glitch010101 8:16, 7 Dec 2004 (UTC)

It's silly to wait to implement this until the perfect SVG renderer is written — rasterization is such a simple operation from the wiki's point of view. Inputs: SVG file, resolution; Outputs: Bitmap image. So make it a shell script that runs the best available rasterizer. Easy upgrades…

Says who? Any programmer knows that before creating the "perfect" s/w, one have to create an imperfect s/w and thereafter improve it. rursus 06:47, 7 October 2008 (UTC)[reply]

Concerns

SVG files can contain references to external resources. What does this entail?

At minimum, if the image was converted to a tag, the a tags in SVG would need to be parsed out and added so that someone could still follow the links even if they were viewing the PNG version. See: http://www.w3.org/TR/SVG11/linking.html#Links

A possibly complete list of external references allowed in SVG is at: http://www.w3.org/TR/SVG11/struct.html#Head

What about animations, etc.?

Online editing

It's also been suggested that SVG images could be edited in the wiki way (as raw XML text, or with some kind of vector editor applet). That's a bit more complicated, though. See SVG whiteboard. This would allow easy updating of diagrams and maps when data changes, for instance.

Others consider SVG's baroque and tedious XML syntax of little use for manual processing with text editors and HTML forms. In comparison, a far more powerful, comfortable and better-established vector-graphics file format is MetaPost. In contrast to SVG, MetaPost was specifically designed to be edited directly with a text editor and is therefore far better suited for a Wiki environment. MetaPost is a high-level programming language and therefore far better suited to represent geometric constructs at the appropriate level of abstraction. It is widely used today in scientific typesetting and freely available.

Although SVG images may not be appropriate for human online editing, enabling online editing would permit templates that produce SVG images as output. For example, the collection of Railway line template (also see w:WP:TRAIL) icons are currently growing exponentially - they could be replaced with a handful of template programs.

Browser notes

Mozilla Firefox 1.5 includes native SVG support for a subset of SVG 1.1.
Mozilla Firefox 2.0 includes native SVG support for a subset of SVG 1.1
Mozilla Firefox 3.0 includes native SVG support for a subset of SVG 1.1, and now supports all SVG 1.1 filters, among other improvements.

(the above links are broken, explore http://www.mozilla.org/projects/svg/)

Opera 8 includes native SVG support for the SVG Tiny mobile profile of SVG 1.1 plus extensions for opacity, font handling, and animation.
Safari 3, and other recent Webkit based browsers, include native SVG support, for a subset of SVG 1.1
Microsoft Internet Explorer 9.0 Testdrive includes native SVG support for a subset of SVG 1.1.

Support via plugins

I'm having trouble getting the Adobe SVG plugin running with Mozilla on Red Hat 8; as a full-page viewer it works, but as in inline plugin it crashes Mozilla.
- Having better luck with Windows version in both Internet Explorer and Mozilla. As an inline, it seems to require specifying a size for the plugin or it defaults to some ridiculous square. It also defaults to displaying at 100% zoom at the Windows logical display resolution; specifying width and height in inches per stylesheet instead of pixels (i.e., to match the pre-rendered PNG's resolution, probably 72) seems to give the right results
  - Corollary to that is that SVG images should be logically sized to something that will be comfortable on screen and on print.
There's a Corel SVG viewer plugin, but for Microsoft Windows only.
Amaya supposedly has SVG support; I can't get it to compile, I'll have to look for a binary.
- Happened to have an old old version 5 that came with Debian 3.0; it doesn't like the particular demo image, so doesn't seem to work right. I'll try a newer version. … Amaya 8.0 does show the SVG, but the star is placed too far to the right. I don't know if it's a bug in the file or in Amaya's rendering. --Brion VIBBER 04:38 26 May 2003 (UTC)
There is some sort of Konqueror plugin. Haven't tested yet.
- According to browserspy SVG embeded and as an object are supported (Mandrake Linux with KSVG 3.3.2) --Hhielscher 20:12, 3 Mar 2005 (UTC)
Adobe SVG Viewer one of the best SVG rendering plugin for Windows 98-XP, MacOS 8-9, Mac OS X, RedHat Linux and Solaris, available in 20 languages (also offers an optional extension for handling ICC color profiles). Unfortunately, Adobe now announces that it will discontinue its support on 1 January 2009. The current version of this viewer is 3.0 (with update 3 on Windows). -- fr:Verdy p 17:13, 20 October 2006 (UTC)
Adobe SVG plugin will accept some SVG pages that aren't supported by the native engine in some of the recent web browsers. This is often down to a missing anonymous namespace reference in the SVG element. In such cases the SVG document should be reworked to ensure maximum compatibility.

Unsupported

Netscape Navigator see below

The trick to "hide" inline SVG in an <object> tag with a fallback to a plain inline <img src="some.png" /> is elegant, but please note that some legacy browsers also don't support inline PNG. For very important icons that's unacceptable, e.g. on MoinMoin all external links are screwed up by ugly "internal-icon-baddata" artifacts. On the other hand, <object> can be nested, and using inline PNG only within <object> could avoid harmful side-effects on old browsers.

Implementation

One possible way of implementing would be to create a special namespace called SVG:. Editings in this name space would be interpreted as a svg image. The preview and the final display would first of all check to make sure that the SVG had the correct syntax, and then it would display a PNG and the SVG of the image. When the editing was done a PNG would be generated from the svg and placed in a generated images directory. The SVG would be edited as text, or could be copy and pasted into the editing box.

I like this! You could also have a user option to display the SVG directly, which you might pick if you know that your browser handles SVGs well. -- Toby Bartels 18:09 1 Jul 2003 (UTC)

Yeah. People should be able to choose if they are getting PNG when they know their browser supports SVG. This is happening to me a lot and I hope that this will be implemented soon.

A second way would be to check when a new file is uploaded. If the file is a SVG, then a generated image would be created from it. Then when a SVG image is linked, it would generate the appropriate object tag and the secondary link to the generated image.

This, in contrast, isn't really any better than any other image format, since it's unclear to people that they can edit the image in the wiki way. -- Toby Bartels 18:09 1 Jul 2003 (UTC)

Current implementation

MediaWiki 1.5 allows use of an external program to rasterize SVG images to PNG for inline use. (SVG still needs to be manually added to the upload whitelist to allow uploads.)

The Wikimedia sites are currently using a slightly hacked rsvg (to disable loading of sub-images or other resources from the filesystem) as the renderer. The version used is 2.14.0 (cairo-based).

Batik provides better rendering but is very slow (a large Java-based library) so we're not using it at the moment. Making it a callable daemon may allow using it effectively.

All Wikia-hosted projects are currently using ImageMagick's convert (the default). This application has some severe limitations in its SVG->PNG conversion abilities, including complete loss of all gradient-fills and text. All uncyclomedia.org-hosted projects (for example) therefore use Inkscape. The options to select each of the various renderers are listed in includes/DefaultSettings.php - copy to LocalSettings.php and edit as required. Note that, when first invoking Inkscape, the web server (user: apache on RH/Fedora-style installations) must have write access to its own home directory so that it may create a pair of hidden subdirectories to store Inkscape's settings. Once these directories have been created, no further changes are required.

A same-image comparison (as of August 2006, based on various MediaWiki 1.7alpha, MediaWiki 1.8alpha installations):

RSVG: ~~http://fr.wikipedia.org/wiki/Image:Lapinrose_ratp.svg~~ (transfered from fr.Wikipedia to Commons, then deleted from both wikis due to copyright violation)

ImageMagick: http://desencyclopedie.com/wiki/Image:Lapinrose_ratp.svg

Inkscape: http://desencyclopedie.org/wiki/Image:Lapinrose_ratp.svg ( Inkscape on Win32 Server Setup Notes )

The image should display as a pink bunny with one hand caught in a subway train door (from a warning sticker on the Paris métro system). Wikipédia displays this correctly, as does the server running Inkscape. The windows are gradient fills and, on the ImageMagick version (default as used on Wikia), they simply disappear into the blackness behind them.

Sources of SVG images and icons

The entire Openclipart archive is SVG, a few thousand freely-reusable public-domain images. A commons-style setup does allow reuse of this handy material across many projects.