Talk:SVG image support

First discussion originally added without header

[this will] be added as soon as someone has the combination of the inclination, the ability, and the time to hack it in. At the moment I lack the time, alas; I may get to it later in the month, or I may not. My Wikipedia to-do list is very long. :) If someone else wants to give it a try, they are more than welcome! --Brion 20:34 Mar 3, 2003 (UTC)

So, this falls under "may not", then? Grendelkhan 00:27, 9 May 2004 (UTC)

I don't see your code in the CVS logs, mister! ;) --Brion VIBBER 02:21, 9 May 2004 (UTC)

So? Some people don't know how to code, and instead contribute to... ARTICLES! OMG!1 - Omegatron 13:56, 6 Apr 2005 (UTC)

self-proclamation of "skills", but refusal to commit? Pathetic. "Oh, I have the skill and the desire... I just cant do it". My butt. Just admit incompetence. What was the point in even posting? What a waste of internet space for your ego.

Uploading XCF files

Since m:SVG support seems to be a long way off, maybe we could upload native formats like .XCF (the GIMP's native format) for increased modularity, and the wiki software could make a rendered version for page display, just like it makes rendered thumbnails?

This way other editors can modify text layers easily, translate to their own language, etc.

I know, I know. I can upload both, but this would be better. - Omegatron 13:59, 6 Apr 2005 (UTC)

Simple SVG plugin

I created a simple SVG plugin that requires a client side SVG viewer:

<?php
$wgExtensionFunctions[] = 'wfSVGExtension';

function wfSVGExtension() {
    global $wgParser;
    $wgParser->setHook('svgObject', 'showSVG');
}

function showSVG($svgsrc, $style=)
{
    global $wgUploadDirectory, $wgUploadPath, $IP, $wgArticlePath, $wgTmpDirectory;
    $hash = md5($svgsrc);

    $svgsrc = ltrim(rtrim($svgsrc));

    $dest = $wgUploadDirectory . '/svg/';
    if(!is_dir($dest)) mkdir($dest, 0777);
    if(!is_dir($wgTmpDirectory)) mkdir($wgTmpDirectory, 0777);

    $fname = $dest . $hash . '.svg';
    if(file_exists($fname)) {
        unlink($fname);
    }
    $handle = fopen($fname, 'w');
    fwrite($handle, $svgsrc);
    fclose($handle);

    $dom = domxml_open_mem($svgsrc);
    $root = $dom->document_element();
    $width = convertUnits($root->get_attribute('width'));
    $height = convertUnits($root->get_attribute('height'));

    return "<object type=\"image/svg+xml\" data=\"{$wgUploadPath}/svg/{$hash}.svg\" width=\"{$width}\" height=\"{$height}\"></object>";
}

function convertUnits ($value) {
    /*
     * http://www.w3.org/TR/SVG11/coords.html#UnitIdentifiers
     */

    if(ereg('in$', $value)) { return round(ereg_replace('in$',,$value)*90);
    }elseif(ereg('pt$', $value)) { return round(ereg_replace('pt$',,$value)*1.25);
    }elseif(ereg('pc$', $value)) { return round(ereg_replace('pc$',,$value)*15);
    }elseif(ereg('mm$', $value)) { return round(ereg_replace('mm$',,$value)*3.543307);
    }elseif(ereg('cm$', $value)) { return round(ereg_replace('cm$',,$value)*35.43307);
    }else{ return $value; }
}
?>

--Wiebren 13:55, 31 May 2005 (UTC)

About SOURCE file in OpenOffice.org

Hi, I have making some drawing with letters embedded in openoffice.org drawing tool in order to aid the translation and edition of them. In every case I have convert the image to png and upload to commons and put in the image description page a note about and an external link to the source drawing (openoffice.org) located in my homepage.

I realize that openoffice 2.0 beta is able to export drawings to SVG but it is not able to import them.

I think to make a template in order to aid this kind of notes and links. But firstly I want to ask you about your opinion about the topic. I if you know if there exist others templates like this aimed to promote the traslation of embedded text images. I had search but I could find anything more that this article I am writing into its talk page.--GengisKanhg (my talk) 15:10, 27 September 2005 (UTC)

Possible to convert .svg to .swf in server-side?

So even if the client doesn't have a svg viewer can see dynamic contents. Flash .swf is an open file format and you can obtain its specification from Adobe.

Confusion

Can someone summarize the current support for SVG in MediaWiki? It seems that you can upload SVG files to Wikipedia but they are (automatically?) rasterized to PNG - the SVG image itself never displays in the actual article (see Scalable Vector Graphics page on Wikipedia), nor can you edit the SVG directly. I also notice that the MIME type is incorrectly displayed as "image/svg" - this needs to be corrected to "image/svg+xml". Since Firefox 1.5 and Opera 8 now support SVG to some degree it would be useful to understand current status and roadmap. Thanks. 136.182.2.221 16:00, 23 November 2005 (UTC)

TITLE filtering problem

I would be a lot more willing to upload SVG's if they didn't ban all <title>...</title> elements -- especially since the official W3C SVG standard highly recommends that TITLEs be included in SVG files, the Adobe SVG plugin displays the contents of the TITLE element in the window bar, and multiple TITLE elements within a document are an important part of the SVG accessibility guidelines (intended to make the contents of SVG's partially available to those who can't view them visually). I submitted Bug report #4388 http://bugzilla.wikimedia.org/show_bug.cgi?id=4388 a month and a half ago, but nothing seems to be being done with it. AnonMoos 21:06, 15 February 2006 (UTC)

resize after raster?

It seems that the current implementation resizes the image *after* rasterizing it. The whole point of using vector images is that they can be resized losslessly (at least up). Right now, doing so looks pretty horrible. See w:User:Ktims/Sandbox/SVG for example. Please comment on my Wikipedia talk page if there's disucssion/progress.--216.113.195.40 14:15, 14 March 2006 (UTC)

batik daemon

I'm working on a Java daemon (using Batik) to convert SVG->PNG using a simple HTTP-based network protocol (Simple framework). So far the basic functionality is working, but the code is really horrible and I'd like to clean it up, add exception handling, and improve the design a bit. Not a fan of Java; it just took me 2 hours to figure out how to instantiate a SVG DOM document initialised from an InputStream. Anyway, once the design is up to snuff, I'll release it and we'll see if it gets adopted. I'd really like to see SVG support embraced more fully here, so I hope this materializes.

http://batikd.sourceforge.net/

Upload Problem

Hello I have a problem with upload an SVG - I think without script. Wikimedia talk to me my SVG file has an script inside. Can somebody help me? Error file can found in sourcecode here. thx --Bastie 12:04, 18 March 2006 (UTC)

Wikimedia (stupidly, imo) blocks any SVG images including a <title> tag. Remove the title tag and the file should work alright.

Thumbnails

Hi there, I decided to give the Inkscape a try and created a simple map for the w:battle of Kircholm article. It got uploaded to Image:Kircholm Phase2.svg just fine, but then the problems started. The image seems to be ok when I click on it in commons (100% zoom), but there's no thumbnail available. Moreover, there's no way to link the newly-created map in the article as it says Error creating thumbnail:. Any ideas? I'd appreciate a response at my English wiki talk page, I do not monitor meta too often.

Oh, by the way, I noticed that multi-layer images don't work in wiki, but my map behaves that way even if reduced to a single layer. Halibutt 20:52, 30 March 2006 (UTC)

Anyone? 83.24.13.49 15:43, 21 April 2006 (UTC)

Arrow problem and fonts

In the images Image:Photomultipliertube.svg and Image:FusionintheSun.svg there are some arrows. With Firefox I can see it, but Commons doesn't. We make it with Inkscape. (Other example: Image:Tunneleffekt.svg.)

I have uploaded Image:LHC.svg but I can't see it. With Firefox there is no problem to see. (Oh it seems to be same as the #Thumbnails.

On the Image:FusionintheSun.svg there are greek fonts. It is correct with Commons, but the fonts fails with Firefox. There is any suggestion what type of font we should use to avoid this problem. -- Harp 12:37, 6 April 2006 (UTC)

The greek text works for me in Firefox. Very nice diagram, by the way. — Omegatron 15:15, 6 April 2006 (UTC)

The line marker problem is due to Imagemagick. I filed a bug on their forum and they said that markers are not implemented in Imagemagick yet. The only complete SVG renderer at the moment is Batik apparently, but it won't be used in Wikimedia due to it being very processor intensive whereas Imagemagick is very quick.

I asked on another forum about the font problem. There were 3 solutions that came up. The first is to declare alternate fonts in the styles, for example:

font-family : Georgia, "Times New Roman", serif;

In this case the SVG renderer will try to use Georgia, if it is not installed it will fall back to Times New Roman and if that is not available it will fall back to serif which will be the default font for the client (which will definately work although it may look bad). This appears to be the best solution, however I do not know of an easy way to do it without manually editing the XML source of an SVG which would be very tedious.

The second is to embed fonts into the SVG. Inkscape currently does not support this and it probably isn't a good idea due to non-free fonts being embedded into SVGs and also the impact on filesize.

The third suggestion is to convert the fonts used to paths in Inkscape, so they will no longer be characters, but they will be shapes. This will increase the file size but it is acceptable on my diagram since I have only 4 characters. -- Borb 18:25, 6 April 2006 (UTC)

Actually, Wikimedia doesn't use Imagemagick for SVG rendering, it uses rsvg. So it's a problem with rsvg not Imagemagick. Imagemagick is even worse for rendering SVGs. -- Borb 18:51, 10 April 2006 (UTC)

Support for crispEdges?

When the shape-rendering CSS attribute of a graphic element is set to crispEdges, the rendering engine is supposed to optimize the object to display sharply on the target display by, for example, turning off anti-aliasing for the object and/or displacing vertical or horizontal lines slightly so they are aligned with the display device's pixel grid. This can be useful for things like ensuring that a one-pixel line stays a one-pixel line even at small sizes and doesn't disappear into the background. It appears that using shape-rendering: crispEdges in an SVG graphic breaks MediaWiki's rendering of the graphic entirely. Is this something that can be easily fixed? --PHenry 20:36, 7 April 2006 (UTC)

Relative units

Will there be any support for relative units? In other words, the image would be rendered differently at different sizes. If I understand correctly, the PNG image is generated from the SVG at full size, and then scaled down in a raster manner for thumbnails, which would mean "no". Are the SVGs eventually going to be placed directly in the text for browsers that can handle it? — Omegatron 15:48, 8 April 2006 (UTC)

Wierd problem

File:Delet.svg

after i uploaded a newer version of my map to Image:Mumbai suburban rail map.svg , i found that the svg didnt get rasterised on the image page. i uploaded the same file to a different filename and it displayed all right Image:Delet.svg. whats going on here? its the exact same file! --59.92.44.137 16:40, 1 June 2006 (UTC)w:user:planemad

• I often find that thumbnails are not properly generated for my SVG files until I do an ?action=purge on the image file, and then maybe after doing it a few times. I expect there are load issues on the SVG rendering toolchain and perhaps race conditions. 68.166.207.60 00:25, 13 February 2007 (UTC) (w:user:brighterorange).

rasters in svg

Inkscape allows to inculde raster-iamges into the svg file. Does the wikimedia converter handle this correctly? --128.130.51.96 08:05, 4 August 2006 (UTC)

SVGZ

Does the MediaWiki software support compressed SVGZ images? Thanks - RedHotHeat

Doesn't seem to support it. Many SVG viewers do not support svgz, even though it is simply a gzipped copy. --Voidvector 22:01, 5 September 2008 (UTC)

PNG Rendering problem

It seems that the rendering machine is not able to render the SVG code for the Sierpinski triangle.svg correctly - to deep an iteration ? The code is actually simple and opens correctly [1]... --katpatuka 19:03, 25 November 2006 (UTC)

RTL Wiki support

See [2] for a discussion. It seems that Wiki and lots of other SVG "supported" programs can't show RTL letters properly, while Inkscape does place Right-to-left letters in the proper position. For example, this file [3] from Wikipedia shows the Hebrew letters misaligned when viewed as an image in an SVG viewer other than Inkscape, and when that was the actual file for this image [4], the Hebrew did not show up at all. (The current version has the Hebrew letters replaced with svg paths.) What's going on? Is there really full support of SVG?

A strange case: Where's the Windows flag on my image?

There is something very unusual. Whan a cetain SVG image is sized too small, part of the image goes away. See [5] for the problem.

It gets stranger. [6] is another windows logo. I had uploaded a new version of that, but the corners didn't show up on Wikipedia. So I reverted.

Windows version of RSVG?

Does anyone know of a windows port of the rsvg tool from librsvg? I looked long and hard for one, but ended up resorting to inkscape (which works fine, i just wanted to compare it to rsvg on my own installation). — The preceding unsigned comment was added by 69.254.187.229 (talk)

Took me sometime to figure out so I will share it with you guys.

1. Download the windows binaries from here, you will need both librsvg and librsvg-dev.
2. The newest Windows version is 2.22, but Wiki server uses 2.14, the closest Windows version availble is 2.16. (You can use the newest exe file with the older DLL file.)
3. Create an empty directory somewhere, let's call it rsvg folder, extract librsvg-2-2.dll and rsvg-convert.exe into this folder.
4. You can try run it now, but chances are it will prompt you for missing DLLs.
5. Download and install the newest Windows verison of GIMP.
6. Copy all the DLL files in C:\Program Files\GIMP-2.0\bin to your rsvg folder
7. Now you have a working rsvg command line in Windows.

Redirecting the output does not work in Windows, the file created from redirection is corrupted (probably because the CR-LF issue). So you have to use the command line option "-o". use "--help" to read about the other options.

Alternatively, you can just download librsvg-dev from the link above, and put the rsvg-convert.exe in GIMP folder. However you won't have control over the version of the library used in this case. --Voidvector 06:01, 4 September 2008 (UTC)

Default monospace font changed

Tim Starling recently updated the fonts on the Wikipedia servers, and, as a result, the default 'monospace' font for SVG images has changed from Nimbus Mono L to one of the Bitstream Vera Mono fonts. Therefore, the appearance of many images has changed. To make them look the way they did before, it's necessary to explicitly specify the font face "Nimbus Mono L". This should be documented, but I'm not sure where to put it. On the en:wikipedia Village Pump, Tim said that a complete list of fonts is now available at SVG fonts. 76.97.207.71 00:51, 30 April 2007 (UTC)

This tidbit probably belongs in some sort of best practices documents for SVG creation, which, as far as I can tell, does not exist yet. Hmm... (idea) — Edward Z. Yang^(Talk) 01:26, 30 April 2007 (UTC)

I could remove the bitstream vera fonts, if they're worse than useless. I added them more or less on a whim. -- Tim Starling 12:29, 4 May 2007 (UTC)

Vera only covers basic Latin, and can be replaced by DejaVu without any issue. In fact, I would go so far to suggest that DejaVu be selected as the default font for SVG rendering, because aside from Vera, it is the only Western TrueType font on the server.--Voidvector 04:05, 4 September 2008 (UTC)

How can I make my wiki like Wikipedia....

Now In Wikipedia, SVG files can be uploaded and are automatically converted to PNG files on server. I want to make my wiki (it is a MediaWiki set up on a linux webhosting server) like this. Is there a simple solution? --Yes0song 08:50, 4 August 2007 (UTC)

After three years of trying on a windows system, I have given up trying to make svg or latex work the way mediawiki says it should. I am not even a developer and I have found it much easier to just jerry-rig my own fix with simple code and third-party rasterizers. The wiki site even has other patrons explain all these techniques... and there are a lot of them... all because the designed method is horrible and no one can ever get it to work besides the wikipedia itself. There is an endless stream of install demands, one after the other, to get one program to work you need another program, and for that one to work you need another, so on. Its retarded. You would think that mediawiki could just package an appropriate executable along with their wiki software, or offer a separate download, instead of charging their patronage with an endless, futile mouse chase.

Confusing and out-of-date page

Hi,

I know that for something that is changing as quickly as svg support, it is hard to keep a page up-to-date, but this one is really bad (especially for such an important topic). When trying to find out about svg support on wikimedia, I came here and got excellently confused. There is even chat on the content page! Someone who actually knows what is going on should take a firm hand to the article. --Slashme 10:29, 25 September 2007 (UTC)

I'd like to 2nd this 26+ month suggestion. Earthsound 17:56, 4 December 2009 (UTC)

How to increase apparent svg resolution?

Does anybody know how to make the svg image appear with higher resolution in w:Reference ranges for blood tests? Compared with the png-image below, it doesn't get that razor-sharp; it does so only when clicking on it, which shouldn't be necessary. Mikael Häggström 13:41, 31 October 2008 (UTC)

We currently have a rendering size limit on rasterization of SVGs, so they are only rendered at up to 2048x2048 pixels -- this is a protection against resource overload from rendering images very large. Your image is extremely wide, and you're requesting an output size that's much greater than 2048 pixels wide. The result is that it's rendered only at 2048 pixels wide, then displayed larger in the browser.

Since the rasterized PNG output is, unlike the original SVG, not cleanly scalable, it ends up looking crappy.

Use of a very wide image like this is IMO pretty awkward to begin with. It requires horizontal scrolling in the browser, which is not a standard practice and may confuse some readers, and it will completely fail to print properly, so it isn't friendly to individual printouts or third-party paper-output versions of the article. I'd recommend breaking up the image into strips which can be seen onscreen without horizontal scrolling and which can be printed. This would also, as a side effect, skip your problem with the rendering size limit. --brion 22:22, 21 November 2008 (UTC)

And I've made a note of the rasterization limit issue at bugzilla:16416. --brion 22:40, 21 November 2008 (UTC)

That explains it. Having it png instead works fine, except for that scrolling part. Perhaps it would be enough with a thumb, as in w:Reference_range#Examples, so people may just click on it if they want the big thing.Mikael Häggström 07:38, 22 November 2008 (UTC)

Text in SVG

I created a few diagrams in MS Visio 2007 which has a neat SVG export function. It works fine, but the wikimedia preview function does not render text correctly. There is a test file which works fine, but mine doesnt (Image). I removed the font-family spec from the file, so there is no specific data about, the only info is {fill:#000000;font-size:1.00001em;font-weight:bold} Why does it not render in the preview? - Schwammerl-Bob

Sounds like it's probably using fonts that aren't supported by librsvg. Lucideer 18:50, 22 December 2008 (UTC)

librsvg features/spec support

Does anyone know where there might be some relatively detailed information about what exactly librsvg does support (I know font support is relatively OS dependent, but what level of support does it have for the SVG spec). It's SF page only really describes how to use it, not much on it's feature set. It's wiki article is a stub, which mentions it's based on Cairo, but does that mean it supports everything Firefox does in the same way, or simply that it operates similarly. MediaWiki documentation seems to imply it has the 2nd most accurate svg rendering (after Batik), but that page doesn't give any real detail, and also says browser rendering is very poor (which in my experience comparing Opera's svg rendering to some of Wikipedia's rsvg png thumbnails is not correct). Lucideer 18:50, 22 December 2008 (UTC)

The only documentation is at http://library.gnome.org/devel/rsvg/. Practical experience says that feature support is not really good (that is why most graphics communities on WP have support pages for handling rendering errors). A systematic testing is lacking. I have tried to nudge Jeff Schiller to include rsvg in his testing scheme at http://www.codedread.com/svg-support.php, but he hasn't reacted yet. My estimate is that librsvg would end up with less than 50% passes on the test suite. --Hk kng 15:38, 31 January 2009 (UTC)

In that case, why is it used? If Batik's efficiency is an issue, I can't see it being a huge overhead - the library is surely only used once per upload, after which the cached png is always used (though looking at that chart you linked, I wonder how far off inline support is; Opera is ahead of Batik and nearing 100% compliance in it's current stable browser and I suppose the others will be needing to catchup if they want to support ACID3. Even IE9/Gazelle is rumoured to be aiming for the same. It would be nice if the wiki didn't need a server-side renderer). _ɹəəpıɔnı 00:49, 18 April 2009 (UTC)

Since Batik is a Java project, it would need to be set up as a permanently running service to avoid loading the Virtual Machine for every upload. I think this has never been tried.

In addition, there is a reason why you would need a server-side renderer anyway: Imagine a wiki page with a large gallery, or multiple thumbnails of maps (which tend to be the largest SVG files around). Would you really like to download more than a Megabyte of data only to see some 180px thumbnails? If you like, take a look at de:Benutzer:Hk kng/svgdirect.js, which is an ongoing experiment to achieve client-side SVG rendering via AJAX. The script is not finished yet, and explanations on the discussion page are only in German. I plan to translate that soon. --Hk kng 15:22, 9 May 2009 (UTC)

Thank you for that link. It certainly looks interesting. Also the point about the VM is one I was not aware of (though I knew it was a Java project, the intricacies of such are not something I'm hugely familiar with).

You're point on the thumbnail issue is not a bad one and one I had not previously considered myself, but generally speaking SVGs should really be quite small. There are many tragic examples of uploads on Wikipedia that are in fact the opposite, but the vast majority are unnecessarily so. One of the biggest culprits is Inkscape, which generates terribly bloated markup (though I know understand of the main motivations of this is to achieve compatibility with the vastly deficient support in most renderers, particularly for non-inline CSS). An SVG compressor (and automatic gzipping of all to the .svgz format) would go a long way. Still worth keeping in mind for some types of images (maps you mention), but I believe it could be less of an issue than one might think. _ɹəəpıɔnı 16:04, 13 May 2009 (UTC)

Support by client-size rendering: this will never be feasible

• 
  Screenshot of server-side SVG rendering
• 
  ...and of client-side rendering with resize error

Imagine at some time in the future browser support would be finally working, and Wikipedia would decide to switch to deliver SVG files untouched. Still, the images would be required to be resized. The standard way would be to harness SVG files via <object> tags, with width and height attributes to indicate rendering sizes - just like with <img> tags.

There is a precondition for this to work: the SVG files need to have attribute viewBox set on the root element to provide the needed base data for coordinate transformations (which is what rendering agents do behind the scenes). Unfortunately, there is one editor out there that does not set this attribute, and it is the most important one - Inkscape (see https://bugs.launchpad.net/inkscape/+bug/168261). Easily more than half of all SVG files currently uploaded in the different projects are drawn with this program, and none of them are client-side resizable.

I'd say, this avenue is closed, unless someone has a neat idea how to edit millions of SVG files on the servers, or how to modify them before they are served. --Hk kng 15:28, 31 January 2009 (UTC)

This is not (IMO) an Inkscape bug, it is a Firefox one. It is listed here. Object is unsuitable for this purpose, it's not semantic and as you point out it was never designed to resize it's content directly, both Opera and WebKit support img. _ɹəəpıɔnı 01:08, 18 April 2009 (UTC)

With something like Google Chrome Frame, IE can have a quality and supported SVG renderer, making all major browsers SVG compatible (save for the above-mentioned firefox bug) Nintendo Maniac 64 04:25, 26 September 2009 (UTC)

If we're including ActiveX plugins like Google Chromeframe, then IE has already had SVG support for a long time in Adobe's SVG Viewer plugin, which actually has far better SVG support than Chromeframe (or Chrome/Firefox/Safari). Unfortunately, both ASV and Chromeframe present (different) issues - ASV (like Firefox) doesn't support SVG <img>'s, and Chromeframe would need to be used to render all of Wikipedia for this to work (which is an entirely different and far more wide reaching proposal). _ɹəəpıɔnı 02:31, 20 December 2009 (UTC)

Batik server revisited

Three years ago User:Ktims started a project called batikd as a means to effectively harness Batik rendering for MediaWiki. It seems that noone ever reacted to his proposal, and his development stopped after v0.1. Now I have been looking into this, and I think the idea has some potential.

SVG image support#Current implementation simply states "better rendering but is *very* slow". Somwhere I have seen the tests this was based on, but I can't find them any longer. Rendering times with different engines had been compared, and at the time Batik came up with half a minute just for one picture - an obvious result of starting up the Java VM every time. Now, I have compared some times using batikd.

Since I was not prepared to rewrite the server just for a test, I used an old version of Simple (it is not backward-compatible), but for Batik the use of the current libraries was possible. The server was on a local machine (AMD Athlon XP 2000+, 757MB, Ubuntu 8.04) and called with Python httplib. All pictures were rendered with a maximum size of 600x600px.

Here are some results: Batik results can differ by factor two. I give lower limits, since I think this is a result of the http protocoll used, and could be improved by a tighter reign between client and server. rsvg results are largely consistent.

File	Batik rendering time	rsvg rendering time
Brain human sagittal section.svg	0.61s	0.35s
Satellite stabilization comparison.svg	1.08s	0.43s
CH-Hinweissignal-Ausfahrtstafel_(3).svg	0.39s	0.25s
Wikimedia-servers-2008-11-10.svg	4.2s	1.94s
Cent.svg	5.3s	15.0s
Bundestag Wahlkreise 2009.svg	4.1s	1.59s

At least you could say, this avenue isn't hopeless. --Hk kng 18:21, 9 August 2009 (UTC)

Consider also posting this at wikitech list. Helder 19:27, 9 August 2009 (UTC)

Hacked version of rsvg

"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."

I saw this on the content page, is it available for download? Since the folks who do all the maintenance stuff on the wikimedia sites have a lot more knowledge about this kind of stuff, I should probably use a hacked version as well to avoid the problems mentioned. Is it available to download? Also where can I find instructions on install rsvg to work with my own wiki?

1. http://www.mediawiki.org/wiki/Manual:$wgSVGConverters
2. http://www.mediawiki.org/wiki/Manual:Image_Administration#SVG
3. http://svn.wikimedia.org/viewvc/mediawiki/trunk/debs/librsvg2/debian/patches/

--Hk kng 10:02, 29 August 2009 (UTC)

Writing an extension for native SVG

Hello all, i like to write my own extension to support the style mentioned here. Thus placing an rendered image inside an object tag. I'm pretty sure this will handle my needs and i can controll the kind of SVG files placed in the wiki. Thus i don't have to fear SVGs without viewboxes like decribed above.

My question is: How to adjust MediaWiki without modifying the standard code? I found out that the rendering is done via media handlers which work with content type. What i can do is pointing the SVGHandler to a different file loading the SVG handling Class from there. Or i may define a new handler SVGNativeHandler. The result is the same, a different image rendering handler class is used.

However the class ThumbnailImage won't help me to save all informations about an SVG image and it's rasterized PNG. Therefore i think i need to add a image class for SVG images.

The second option is using the hook ImageBeforeProduceHTML which is called in the linker. However in this case i have to decide wheter to return true or false. If i return true, i cannot really modify the output. The only option then is to do slight changes to the parameters. But if i return false i llos all the logic after the hook, which means placing the image into a frame or something like this. So i'm sure this hook will not do what i expect.

So back to the first option. I think i need to add the following code:

LocalSettings.php

 $wgAutoloadClasses['SvgImage'] = 'extensions/SVGNative/SVGImage.php'); // instead of ThumbnailImage
 $wgAutoloadClasses['SvgNativeHandler'] = 'extensions/SVGNative/SVGNative.php'; // extending SvgHandler
 $wgMediaHandlers['image/svg+xml'] = 'SvgNativeHandler'; // official
 $wgMediaHandlers['image/svg']     = 'SvgNativeHandler'; // compatible

SVGImage.php

 class SvgImage extends MediaTransformOutput {
   ...
   function toHtml( $options = array() ) {
     ...
     return Xml::tags('object', $objectAttribs,  Xml::element( 'param', $paramAttribs ).
                                                 Xml::element( 'img', $attribs )
                     ).$this->linkWrap( $linkAttribs, 'file info' );
   }
 }

SVGNative.php

 class SvgNativeHandler extends SvgHandler {
   ...
 }

Tried this and basically it works. Firefox shows the svg, IE without plugin takes the png. Thus using the mime types and pointing the media handler to the correct class seems to be a good solution. However need to add some stuff to show a info icon or to hide it. --Darcduck 10:17, 17 March 2010 (UTC)

Horribly outdated

Could somebody rewrite this article, as it's currently written like a talk page and hasn't been relevant or even accurate since 2004? --Stuart P. Bentley 09:48, 15 August 2010 (UTC)

I don't see why. Meta is where these discussions are stored: please don't remove content from pages only because it's "outdated". Updated documentation and technical development discussions are on mw: (well, there isn't much on SVG, but I've created a category, now). --Nemo 16:31, 15 August 2010 (UTC)