# Wikipedia:SVG help

SVG help

Scalable vector graphics is a commonly used file format for providing a geometrical description of an image using basic objects such as labels, circles, lines, curves and polygons. An image can be reduced or enlarged to an arbitrary size, and will not suffer image data loss, nor will it become pixelated. SVG makes an excellent format for artwork, diagrams and drawings. SVG images are defined in XML text files. This means that they can be searched, indexed, scripted and, compressed. Since they are XML files, SVG images can be edited with any text editor, but SVG-based drawing programs are also available.

However, the rendering engine used by wiki is not perfect, and may cause the image to be shown incorrectly, or differently from how it is displayed in your vector editor of choice. This page enables authors experiencing problems with SVG graphics to obtain some help in getting their images into wiki the way they intend.

Further information: commons:Help:SVG

Understanding SVG

• Questions about the SVG format

Using SVG appropriately

• When to (or not to) use SVG

What you see is not what you got

• Missing objects from files
• Random filled boxes in the image
• Images that are the wrong size
• Font inconsistencies
• Other weird and wonderful bugs

Something new

• Questions that you can't find a better place for

### Common problems

#### Missing objects or black boxes

Failure to convert these objects appropriately, which is often not user error, may lead to incorrect Z-ordering, phantom black boxes or missing (not rasterized) objects. If operating on a system with RSVG installed, it may be a good idea to check the image before uploading to MediaWiki servers. If black boxes still appear after converting all objects appropriately, it may be necessary to hand-edit the XML to remove the <flowroot> tags. [1] [2] The issue seems to stem from a mismatch between SVG 1.2 and SVG 1.1 behaviour, and affects several 1.1 programs, such as rsvg. The workarounds that one can employ are either not to use flowed text (by using the text tool without creating a text field), or to stroke the text using "object to path". This can subsequently (and optionally) be cleaned up using "simplify", although this has the negative side effect of smoothing your fonts, particularly at sharp corners. The positive effect of the simplify step is to significantly reduce the filesize required to describe your text components.

#### Font issues

Due to copyright restrictions, MediaWiki cannot use proprietary fonts that are commonly found on several proprietary operating systems. Fonts such as Arial and Times New Roman require licencing fees to distribute. RSVG will not be able to locate such fonts, and the text will fail to appear in the rendered image. There are three solutions to this issue:

• One can substitute a font that is available on Wikipedia. (Facilitates editability.)
• Or, alternatively, one can convert the text into path information in Inkscape. (Better typographical appearance.)
• Group text, and create two copies, converting one to paths and making the other editable text layer transparent. (Compromise)

For ease of subsequent editing and significantly smaller file sizes, substituting the font with an available font is the recommended option. Many of the common fonts have non-proprietary alternatives that are somewhat similar in typographical style, resulting in minimal disruption to existing images during substitution. For a list of fonts available in Wikipedia, see available fonts on Meta.

Here are some suggested freely-distributable replacements for commonly-used proprietary fonts:

Fonts which are available on Meta may or may not be available on a visitor's machine. If the placement or appearance of text in the image is important and there is uncertainty about which fonts are installed on a visitor's machine, then converting text into path information (as mentioned hereinbefore) may be necessary.

MediaWiki provides rasterized previews of SVG images. If those are only images needed by a visitor, then no portability issues may arise. If the visitor retrieves the SVG image to render it directly in their browser (perhaps to zoom in and see more detail than provided in MediaWiki's rasterized preview), it may not display as intended unless the referenced fonts have been installed on the visitor's machine.

Some fonts like Times and Helvetica have problems with resizing, replacing them with Liberation Serif and Liberation Sans, respectively, should fix the issue.

The slightly outdated RSVG version used in Mediawiki requires the presence of x="0" y="0" to correctly calculate the bounding box for the object. Failure to have this can mean that the image will appear to be stretched or compressed in one direction when uploaded. Simply insert x="0" y="0" into the opening SVG tag to remedy this. Newer versions of RSVG do not appear to be affected by this problem (confirmed for RSVG 2.16.1).

### Rendering files

MediaWiki (the software from which Wikipedia is run) uses the librsvg-library to rasterize all of its svg files. The version of the RSVG program that is installed on wiki does not always correctly raster the Inkscape or OpenOffice.org SVG files. The file manager GNOME Files relies on librsvg, so it can be used to check the quality before a SVG is uploaded.

#### Rendering Inkscape files

There is a simple work-around for the scarcities of librsvg. The operation "Stroke to Path", to be found under Menu>Path in Inkscape or via Ctrl+Alt+C, can be applied to all of the objects that are not rendered correctly. To keep the SVGs editable, this should only be done to the files intended for upload, and these files can be deleted afterwards.

As of February 2014, the objects that must be modified to render correctly by libsrvg include:

• Lines with arrow heads (the arrows need to be converted)
• Text, that has been transformed, e.g. "Text on Path"
• Compound objects created with the binary path tools (union, intersect etc.)

#### Rendering OpenOffice.org SVG files

OpenOffice.org SVG files may require manual modification before being uploaded to Wikipedia. To achieve this:

• Change all fonts to Wikipedia supported fonts as mentioned before. (E.g. change "Sans embedded" to "DejaVu Sans".)
• Add "px" to all font-size references. (E.g. change "font-size:100" to "font-size:100px".)
• Remove all additional x coordinate references in tspan elements. (E.g. change <tspan x="17583 17917 " y="10943"> to <tspan x="17583" y="10943">.)
• [Not required for OO 2.3.0] Explicitly colour all text (e.g. black) by replacing relevant "stroke:none;fill:none" instances with "stroke:none;fill:rgb(0,0,0)" (note that simply explicitly colouring text black in OpenOffice 3.2.1 does not appear to work).

NB: Vector graphics line widths may also need to be set explicitly in OpenOffice.org Draw.

##### SVG code replacement guide (executing replace all using Nedit regular expressions)
Original text Replacement text
Sans embedded DejaVu Sans
font-size:([0-9]*); font-size:\1px;
tspan x="([0-9]*) ([0-9 ]*)" tspan x="\1"
<g style="stroke:none;fill:none"><text> <g style="stroke:none;fill:rgb(0,0,0)"><text>

This SVG export procedure has been tested using OO 2.3.0 and OO 3.2.1 with a simple .odg candidate.

Further information: commons:Help:SVG

## Assistance

If you have a tricky SVG file with a problem not described, or can't quite figure out what the previous section was talking about, you can simply ask for assistance by posting a quick note hereafter that outlines the problem, as well as providing links to the files that are exhibiting these problems. Don't forget to sign your name with four tilde symbols (~~~~) and an editor will attempt to reply here to help!

When you are happy that a request has been fulfilled, just leave a note so that the request can be archived later, as needed.

An alternative source of help is Commons:Graphics village pump.

# Current requests

Create a new request

Resolved

Recently I modified an image for Radioactive decay (today, in 2013). Apparently some users can't view the modified form in the article in this section (only the old version from 2009, or the new 2013 version on the actual file page). Can others see the new or old one in the main article? How to fix? I can see the new version perfectly (on Windows 7, Internet explorer 8), there can't be any internal problems with the image... Thanks, if this is the wrong place just point to the right one... M∧Ŝc2ħεИτlk 22:21, 3 January 2013 (UTC)

Probably a caching problem (Wikimedia has been having several problems with this during recent weeks). People in Europe have been having fewer problems seeing updated image thumbnails than those elsewhere. If purging and reloading doesn't work, then you may have to just wait a few days. However, one trick that sometimes works is to change the width slightly to a size which hasn't been generated before (e.g. 221px instead of 220px, etc.). AnonMoos (talk) 09:08, 4 January 2013 (UTC)
Thanks, SBHarris made the image a bit larger [3], it should be ok now. M∧Ŝc2ħεИτlk 10:08, 4 January 2013 (UTC)

Most peculiar. ?action=purge doesn't clear the cache.

[149px thumbnail - correct version]
[150px thumbnail - old version]
[151px thumbnail - correct version]
Stigmatella aurantiaca (talk) 10:26, 4 January 2013 (UTC)
I do see the correct version also in the case of 150px. --Leyo 11:02, 4 January 2013 (UTC)
Very, very, very strange! I still see the old version! It's like we are accessing different, incompletely sync'ed servers on a server farm. Stigmatella aurantiaca (talk) 16:53, 4 January 2013 (UTC)
Now I see the correct version. So it seems that we just need to wait until all of the servers sync up, and purging can't always be relied upon to speed things up. Forcing the creation of a new image just a little bit different in size is a good trick to remember. Stigmatella aurantiaca (talk) 21:35, 5 January 2013 (UTC)

Resolved

Hi; when I want to download an svg image in png format, the downloaded image's transparent (i think at least it is) color (white) becomes black, which is very bad because the already black texts thus disappear. For example in this image: http://en.wikipedia.org/wiki/File:Wiens_law.svg all white becomes black; but in all others as well. What am I doing wrong? Thanks Hoemaco (talk) 10:40, 23 February 2013 (UTC)

The transparent parts stay transparent when saved to PNG. Most software either recognize the transparency or convert it to white, but some may not. So what software are you using to open/edit the png? And what exactly do you want to do with it? More details will help us pinpoint your problem. Cheers! -- Orionisttalk 11:41, 23 February 2013 (UTC)
I tried opening it in Irfanview, Acdsee, Neopaint and Powerpoint. Curiously, it only worked in Powerpoint (just realized I have to check it), even though it's the 2001 version. I know Neopaint is a very old software, but it can actually do transparent png, but says for these new images that they aren't transparent. Did they change the format of png some time ago? Hoemaco (talk) 12:07, 23 February 2013 (UTC)
Well, when inserted in PowerPoint and all other MS Office programs it's working perfectly and keeping the transparency. Irfanview has its default bkgd color set to black, you can change that be going to Options-->Properties/Settings-->Viewing then changing "Main window color" to white, while making sure the first option "Show PNG/TIF/TGA/DDS alpha/transparent color" is checked, then close and reopen the program and it should work just fine. I tried to download NePaint but it's timing out so I can't help with that. The Acdsee Pro 3 I tried converts it to white, but as you might have a different/older version keep in mind that in general, image viewing software have a background color option similar to Irfanview and that may cause such a problem. You can also use Firefox or Chrome to open and view all kinds of images, if all you want is viewing. If editing is what you want to do, I recommend that you check out GIMP which is a very good free software. And if you tell me exactly what you want to do with the image I can recommend you a workaround. Cheers! -- Orionisttalk 13:41, 23 February 2013 (UTC)
Hoemaco -- Your programs probably can handle palette-based or indexed transparency; it's an alpha channel that they're having problems with. In late 2006, I added opaque white backgrounds to many of my SVG uploads which consisted solely of black on transparent because of various then-persisting difficulties and inconsistencies (see File:Hebrew Chai Symbol.svg and many others). But nowadays most of the glitches seem to have been ironed out, as long as you're not using completely out of date software... AnonMoos (talk) 14:43, 23 February 2013 (UTC)
Thanks folks! I stick with my old software because I know how to use them :D I tried Gimp once, but for me it was similarly complicated as Photoshop etc; a bit too much for me. Of acdsee I'm also using a very old version - a few MB only, but it's fast and easy to use; unlike the new versions. For editing I'm just using some enhanced paintbrush stuff :) I'll try and find some newer ones, also look up this alpha channel. 188.6.71.34 (talk) 18:32, 23 February 2013 (UTC)

## Ghost path in BlankMap-World-Microstates.svg

Resolved
BlankMap-World-Microstates.svg

I noticed a ghost path id="path11370" in the file BlankMap-World-Microstates.svg Is this a mislabeled territory or something else?

Thanks. — Preceding unsigned comment added by Gabriel Radic (talkcontribs) 18:12, 14 March 2013

I looked at the file history and that path was introduced when one user edited the shape of the Aral Sea in the 7 December 2012 edit, most probably by mistake. I'll go on and delete it. -- Orionisttalk 20:50, 14 March 2013 (UTC)

## Lines with rgba values do not rasterize correctly

Resolved

Lines with an alpha channel in stroke colour render as solid opaque lines in thumbnails and PNG versions, instead of the expected transparent appearance.

Due to this bug, it is hard to see that significantly more lines are clustered under the robot and not under the other two doors.

screenshot of how the image should look

I'm sorry if this has been asked before. I don't expect that Wikimedia servers will change the SVG rasterization engine any time soon so I'll appreciate any suggestions for making these lines using a way that will be rendered correctly. dllu (t,c) 08:40, 24 March 2013 (UTC)

The alpha channel in your file is not only causing issues with our thumbnail engine, but also when opened in both Inkscape and Illustrator, neither of which recognized it. I guess it's not yet universally supported. I fixed it by removing the rgba values and using instead the "opacity" property by adding opacity="0.2" to each line. I've uploaded this version to your file and it's working now. Cheers! -- Orionisttalk 09:47, 24 March 2013 (UTC)
Thanks! Now I will go and do the same thing for the other 8 images in the set. dllu (t,c) 18:21, 24 March 2013 (UTC)
You're welcome! -- Orionisttalk 23:39, 24 March 2013 (UTC)

## Subscripts do not rasterise correctly

Notice the subscript in $\theta_0$ in the PNG versions of these files.

My SVG diagram contains some subscripts for $\theta_0$. However, in the rasterised version, the baseline seems to be not aligned to subscript even though I specified

   <tspan baseline-shift="sub">0</tspan>


which should shift the zero lower regardless of font.

Screenshot (svg on left, PNG on right)

The markup for the SVG was generated with code I wrote myself and is valid SVG.

It's not a major issue but I should like to fix it nonetheless. Thanks! dllu (t,c) 20:00, 27 March 2013 (UTC)

Don't feel like downloading and looking through the source code of these SVG files at the moment (may do so later), but it sounds like a fairly frequently encountered incompatibility with text in an element not all being at the same tagging level. E.g. in <text>TEXT<tspan>SUBSCRIPT</tspan>OTHERTEXT</text> the "SUBSCRIPT" text has an additional layer of tag embedding with respect to "TEXT" and "OTHERTEXT", and the Wikimedia SVG rendering software doesn't like this.... AnonMoos (talk) 23:01, 27 March 2013 (UTC)
• Oh, it is true that I used nested elements. Here's one of the 31 lines:
<text transform="translate(620.167,115.419)rotate(-87.6169)" style="fill:rgb(0,96,136);font-size:16px;font-family:sans-serif;text-anchor:start;dominant-baseline:middle;"><tspan font-style="italic">θ</tspan><tspan baseline-shift="sub">0</tspan> = 3.1</text>
What's the way to fix that? Should I put the TEXT and OTHERTEXT inside <tspan> elements too? dllu (t,c) 01:43, 28 March 2013 (UTC)
In that one, it's the " = 3.1" text which is not in a tspan, while the rest is. Adding a dummy "tspan" around this (i.e. <tspan> = 3.1</tspan>) will probably help (though I can't absolutely guarantee that it will fix the problem). AnonMoos (talk) 01:58, 28 March 2013 (UTC)
• After doing some research, I found that baseline-shift="sub" doesn't work in some programs (e.g. Firefox). I've changed that code to:
<text transform="..." dy="0 10 -10"><tspan font-style="italic">θ</tspan><tspan>0 = 3.1</tspan></text>
after being inspired by the superscript in File:US Natural Gas Production.svg. But it still seems to be not rasterising correctly (it is the case for the natural gas graph too). Oh well, nobody can read the text in the image in the thumbnail anyway. dllu (t,c) 08:08, 28 March 2013 (UTC)

## request

Is there anybody who can convert this image into SVG? Ischa1 (talk) 11:47, 3 April 2013 (UTC)

I pulled it into CorelDraw, did a trace detailed logo, and readded the text. Colors are a bit off, and I cannot get Commons Upload Wizard to respond right now. Glrx (talk) 20:23, 3 April 2013 (UTC)

Finally uploaded, but text placement on generated PNG different from my Corel and FireFox SVG rendering.... Glrx (talk) 20:45, 3 April 2013 (UTC)

It seems to me that in the current version, the text does not even show up on Google Chrome Version 26.0.1410.43 m on Windows. I tried fixing it but the situation with the text in the PNG got even worse. Anyway, I prefer the new set of colours... the contrast between black and the new shade of blue is much easier to read. dllu (t,c) 18:33, 4 April 2013 (UTC)
Yes, the letters don't show up in Chrome. I think what is happening is CorelDraw spits out dimensions in inches; usually it appends the units (such as for the bounding box), but for the font sizes its seems to have neglected to specify inches. Firefox renders OK but Chrome does not. I suspect that Chrome is assuming the text-height is a fraction of a pixel rather than a fraction of an inch. I have not looked at the SVG spec to see if there is a default unit spec. I will try adding units to the SVG file to see if it renders correctly in Chrome.
The other issue is the text baseline alignment. The svg-to-png converter apparently assumes a top of the text alignment where CorelDraw and Firefox are using a baseline alignment. That means the svg-to-png rendered text is below what I see in CorelDraw and Firefox. I looked briefly at the SVG 1.1 spec, got the impression that baseline alignment is the default, but I did not see a firm statement. I've had svg-to-png baseline issues on other images.
In my experience, Firefox rendering follows the spec. I've reported a number of Chrome SVG problems, but the last time I checked they had not been fixed.
CorelDraw did not map the colors as given in the PNG. I don't know if that is a colorspace issue or not. A light green went to saturated green. I tried to match the colors within CorelDraw, but when I viewed the resulting SVG in Firefox, the colors were again skewed (light green went to yellow). I then jimmied the colors to come out reasonably in Firefox. I chose lighter colors to make the text stand out.
BTW, I was pleased with how CorelDraw did the bitmap to vector conversion. My previous attempts using bitmap-to-vector conversion have been failures.
Glrx (talk) 00:28, 5 April 2013 (UTC)
Yes, the CorelDraw vectorisation of the diagram is quite good. The SVG output is surprisingly clean and readable (compared to horribly verbose things created by Inkscape). It seems that many things about text baseline alignment is poorly interpreted by RSVG. One way to mitigate the issue is to make the text smaller so that no matter where the baseline is, it will still stay within borders. Unfortunately that makes it hard to read in a thumbnail. dllu (t,c) 07:21, 5 April 2013 (UTC)
Yes, I was pleased with the clean CorelDraw SVG. I expected a lot of useless trash.
I looked at Google SVG rendering, and the issue is not clear to me. The text instead of being super small may be super large (and therefore off screen).
I'm leery of uploading SVG with explicit baseline instructions because I think RSVG ignores them. I should make an SVG test image that addresses text alignment.
Glrx (talk) 16:35, 6 April 2013 (UTC)

Uploaded an SVG 1.1 text alignment test that uses alignment-baseline and text-anchor. Firefox does not do baseline alignment; Google does. Glrx (talk) 20:59, 8 April 2013 (UTC)

## Any automated approach to internationalization/localization?

I've created an SVG file that uses switch to internationalize text for EN/DE. Of course, the PNG conversion drops the DE.

Is there some WP mechanism for generating localized PNG for separate WP?

Is there some WP mechanism for generating localized SVG? (For example, using an XLIFF file?)

My impression is the current method is copy a file to a new name and then manually localize -- which means subsequent corrections are not propagated to other files.

Thanks. Glrx (talk) 19:19, 3 April 2013 (UTC)

This has been discussed several times on Commons, but I haven't heard that any implementation is imminent. There's an SVG text caption translation tool for people who don't know SVG on the toolserver, but the last time I looked at it it had some strange bugs... AnonMoos (talk) 19:06, 5 May 2013 (UTC)
Is your "SVG text caption translation tool" this?. I have added another "localization" entry below sketching a very simple multi-language scheme (layers) with a possibly simple rendering scheme (filter). --A Pirard (talk) 00:21, 16 October 2013 (UTC)

P.S. Something now seems to be in place -- see commons:Commons:Village pump... -- AnonMoos (talk) 08:09, 21 December 2013 (UTC)

Yes. Trying out advice in Commons:Translation possible/Learn more#Multiple translations within one SVG file. Hooray! Glrx (talk) 17:57, 21 December 2013 (UTC)
Status report. Other editors had added ionization energy figure to other WPs. I added some translations gleaned from wiktionary and other feeble sources and added the lang= field into several other WPs; I also added the figure to other WPs. Recently, a user added significant Chinese dialects and added the image to the Chinese WP. It warms my heart. Glrx (talk) 23:25, 27 January 2014 (UTC)

## w3c-validation gone haywire

I tried to fix LA_County_Incorporated_Areas_Beverly_Hills_highlighted.svg. I cleaned up the file. Checked it on W3c. And it was W3c-valid. Then I uploaded the file. Checked it again. But now I get a negative. Something is wrong:

• Downloaded the file from the net again. Checked the code. Compared it to the code given by W3c. It differs.

I purged the page. Then I did the Shift+renewal button. To no avail.

What could I be doing wrong? Or is it W3c? Have you had similar experiences? Wereldburger758 (talk) 11:08, 7 April 2013 (UTC)

Purge doesn't always successfully sync all of the servers on the server farm. So it is possible to upload to one server and view your image from another server which hasn't been sync'ed with the upload server.
Wait a day or two and try again. Stigmatella aurantiaca (talk) 13:51, 7 April 2013 (UTC)

## Invisible "put on path" text

Hello, it may be a well-known issue but it is pretty new to me and a bit frustrating. I have translated this map turning the text of the original into real, editable text. I tried keeping the curves in the original text and so used inkscape "Text->Put on path" option and uploaded the result. Unfortunately, the text that has been forced to follow a certain path does not show up (actually, it seems only to show up in inkscape itself, it is missing from geeqie or display as well, though I can see it in the SVG file if I open it with vi...). My goal is to keep the new text as text (not an image, so that it can be easily translated into other languages) and at the same time, keep the curved effect if at all possible. Is it? Any option I can use to achieve this? Thanks in advance.--Rowanwindwhistler (talk) 17:07, 22 April 2013 (UTC)

Looks like text on a patch is a feature that WP's RSVG does not support.
Viewing your SVG file in Google Chrome (v 26.0.1410.64 m) shows the text on curved lines works as expected.
Viewing your SVG file in FireFox (v 11.0) renders the text on curved lines as horizontal text (not a bad fallback).
WP's RSVG PNG file renders ordinary horizontal text but throws away all text on curved lines.
RSVG does not claim to support all SVG 1.1 text options ("http://www.w3.org/TR/SVG11/feature#Text"). See Feature strings and file:SVG Test TextAlign.svg. Since RSVG does not claim feature#Text, then RSVG need not support text on a path.
I don't know what WP recommends in this situation. To first order, supplying the SVG file with curved text seems appropriate. When RSVG gets upgraded, then the image will work. What to do until then is not clear. Your SVG could be used, but viewers would have to click through to the actual SVG file to view most of the labels in the map. Not an attractive option.
For the time being, you could render the text as curves; I don't know if Inkscape has that option, but it would be expedient. That's probably why the original SVG file does not use text. The modified file could be used until WP supports text on a path; then the file could be reverted to your current version. It would work, but it would make further localization awkward.
Alternatively, edit the file so all the text is on straight lines. The picture won't be as pretty, but further localization would be simple.
An exotic workaround is to include a switch within the SVG file that tests for feature#Text; if present, then the curved text is used; if absent, then render as horizontal text. The problem with that approach is the file may become impossible to maintain as I doubt most SVG editors handle the conditional editing. (I'm ignorant of Inkscape's abilities.) The next person who tries to edit the SVG file would probably quietly delete the conditional code. Consequently, this option would be a lot of work with little advantage.
Glrx (talk) 18:12, 22 April 2013 (UTC)
As Glrx said: RSVG doesn't support text paths. The best solution until this is fixed (if it will be ever fixed) is probably to upload the original version with editable text (which is easily translatable) and then upload a second version were you convert the text to path (Path -> Object to path in Inkscape). Clearly state in the upload comment that you converted text to path for one version and that the original version should be used for creating derivative works / translations. -- Patrick87 (talk) 18:32, 22 April 2013 (UTC)
Thanks a lot for the clarifications and the very thorough testing! In the end I chose an intermediate solution: I removed the curving text and tried to mimic it as closely as possible by rotating straight text labels. Not as nice looking as the original but similar and the text remains as real text. Let us hope the feature will be implemented some time in the future so that these maps can look as well in SVG as they do in older formats.--Rowanwindwhistler (talk) 19:42, 22 April 2013 (UTC)

## Help editing an SVG file. Not a real SVG?

Hello, I was trying to translate this file (using inkscape but I also tried using a text editor with no luck at all) but it does not seem to be a real SVG (I cannot select any points, any text, etc). It seems to be a mere container of the original png map. Am I missing something here (some sort of file protection that may prevent the editing of the file...) or it is really a "fake" SVG? Just asking in case I may be overlooking something. Thanks in advance for your opinions and advice.--Rowanwindwhistler (talk) 20:06, 3 May 2013 (UTC)

That's what it is, a PNG image imported and saved as an SVG. --[[ axg ◉ talk ]] 20:13, 3 May 2013 (UTC)
You are right, this SVG only contains an embedded PNG raster graphics. There's no vector data included. The PNG should be extracted and reuploaded with the correct extension. --Patrick87 (talk) 20:16, 3 May 2013 (UTC)
I think the PNG is the one mentioned as the source of this derivative file. It does not seem to be much of an improvement from the original I suppose. Thanks for confirming there is no such thing as a quick translation for this map.--Rowanwindwhistler (talk) 20:59, 3 May 2013 (UTC)
I actually overlooked the source file initially since it wasn't linked correctly. It's identical. Therefore I marked the SVG version as duplicate and changed articles to use the PNG version instead. --Patrick87 (talk) 22:58, 3 May 2013 (UTC)

## SVG versions of technical bitmaps

The QR code article has several two-dimensional barcodes (which are fundamentally bitmaps: square pixels with no text) that have been converted to vector SVG (and thus turning pixels into verbose vectors). For example,

File:Qr-code-ver-40.svg (796 kB) is a vector version of
File:Qr-code-ver-40.png ( 4 kB)

My sense is that the transformation is pointless (except for a possible additional metadata issue). I'm tempted to propose deletion of the SVG files, but want a sanity check. Glrx (talk) 15:27, 4 May 2013 (UTC)

This SVG has multiple issues:
1. It's only a traced SVG. Therefore a rectangular pixel is a path with many nodes instead of a simple rectangle. That blows up the size of the SVG and makes the quality worse than the original.
2. QR codes should be displayed pixel perfect since every pixel carries binary information (black or white). The raster graphics allows this if displayed in it's native size. The SVG version is scalable in theory but produces grey pixels if a black rectangle happens to be aligned somewhere between two pixels of the rendered graphics.
1. could be solved by doing a proper vectorization (that would be very time consuming). 2. would still be an issue, though. Pixel perfect rendering could be achieved for a given size (and multiples of this widht/height) but there wouldn't be a notable advantage over a raster graphics in the end. --Patrick87 (talk) 01:13, 5 May 2013 (UTC)

The only real advantage is being able to scale up smoothly. The pre-existing SVG was rather loose and inexact (the minute you see a bezier curve you know something has gone wrong, and there are thousands in the file); I uploaded a better conversion... AnonMoos (talk) 19:00, 5 May 2013 (UTC)
Your SVG conversion is OK now (although it's file size is still about 20 times larger than the PNG version's!). Howewer I still have to disagree with you regarding scalability. Consider the following scaled examples:
 219px 220px (native size) 221px
When rendered only 1 pixel smaller or larger than the original size, scaling breaks the QR code (no matter whether the image is an SVG or not). --Patrick87 (talk) 23:04, 6 May 2013 (UTC)
I see no inherent scaling advantage for SVG. Bitmaps can be scaled, too. Scaling either with a non-integal factor will produce artifacts. Glrx (talk) 01:29, 7 May 2013 (UTC)
When I spoke of "scaling up", I really did not have 221px in mind (and definitely not 219px, which is scaling down!), but something more like 500px or 800px... Since 221px and 219px are artificially-chosen worst cases, I'm not sure they have much to say about the general situation.
As for filesizes, SVG is an uncompressed text format, while PNG is a compressed binary format, so any SVG file which codes individual pixels will always be at a filesize disadvantage. AnonMoos (talk) 16:02, 7 May 2013 (UTC)
And that's exactly what I was saying in the beginning: As long as we do not want to render the file at really large sizes (and we certainly do not want to do that in articles) there's absolutely no benefit in using SVG compared to PNG in this case. There are even some disadvantages like file size that can never be brought down to comparable values for the reason you mentioned.
However this discussion doesn't really lead somewhere and is more or less academic, since QR codes are quite a special case. For most other uses SVG is far superior (and I'll never claim anything else). --Patrick87 (talk) 16:55, 7 May 2013 (UTC)

## my questionable svg editing techniques

I was recently informed that a series of maps I made (all the maps in Category:SVG maps of Tibet) had an error relating to a prefecture level boundary. As there are 9 maps in total based on the same original svg, and they all had the same error (only effecting 2 paths) I wanted to expidite the editing of the images. Here's what I did:

1. opened one of the maps in inkscape made the edit
2. found the path id of the paths in question
3. opened the file in a text editor, and copied the paths
4. opened the other SVGs in a text editor
5. pasted in the new version of the two paths replacing the unedited version of the paths
6. saved and uploaded the new versions of the files.

This seems to have worked for all the SVGs, as they are rendering without issue (with one exception -- not uploaded), however I'm wondering if I may have messed up the SVGs. The originally uploaded in 2008, and I'm pasting the paths in after editing with version 0.48.3.1 of inkscape. That is, I'm only changing 2 paths in a text editor, without updating any of the metadata. When I ran one of the updated files through a svg optimiser it produced a version that was missing those paths.

Should I be worried, or do anything to fix this?

thanks --Keithonearth (talk) 22:01, 7 May 2013 (UTC)

You don't have to worry. Every thing looks fine. It's valid SVG and renders correctly in Wikipedias SVG renderer librsvg. Probably the SVG optimizer you talked about is broken (maybe it doesn't handle the <desc> tags correctly you put in that path).
Besides that you can always test your SVG on http://validator.w3.org/ to check your SVG code's validity regarding W3C standards and on https://toolserver.org/~jarry/svgcheck/stable/ to test rendering on Wikipedia before uploading. --Patrick87 (talk) 00:05, 8 May 2013 (UTC)
Thank you! Much appreciated. --Keithonearth (talk) 01:45, 8 May 2013 (UTC)

## Santander logo colour

File:Banco Santander.svg needs to be changed to a brighter shade of red, as seen here [4]. There is also a slight shadow or border along the top of the file, which should be removed. Cloudbound (talk) 00:21, 9 May 2013 (UTC)

Done – Should be fixed now. --Patrick87 (talk) 01:07, 9 May 2013 (UTC)
Thanks, that's much better. Cloudbound (talk) 20:30, 9 May 2013 (UTC)

I made this image with linking on the svg: http://www.micropedia.asia/wiki/File:Roads.png I want to make my article on the wiki as detailed as possible but I need linking working on the page. I added links for all roads, And if you click on it, It will go to the page of the road. But I need this working on the page. I would thank anyone for helping me. :) -- 14:49, 8 June 2013‎ 62.234.104.86

Unfortunately, this does not appear to be a request for help with an SVG file. AnonMoos (talk) 13:35, 11 June 2013 (UTC)
If you created an SVG please provide us with the link and try to describe as close as possible what you want to do with it, and what doesn't work.
If you're talking about links included in the SVG I'm afraid it won't work on Wikipedia. The SVG is pre-rendered as PNG, therefore all potential links are lost. You could use image annotations however to include descriptive links in the image. -- 14:38, 11 June 2013‎ User:Patrick87

## SCAS Logo sharpen

File:SCAS Logo 2006.svg

Can you smoother the logo for me? Its too sharp enough. FreshCorp619 (talk) 20:17, 22 June 2013 (UTC)

Sorry, you uploaded a raster graphics, embedded in an SVG. There's no vector data included. That's why the scaled image looks "too sharp". Just upload the image as PNG or search for real vector data. --Patrick87 (talk) 21:16, 22 June 2013 (UTC)
I extracted the included PNG and saved it to Commons as {{PD-textlogo}}, see File:SCAS Logo.png --Patrick87 (talk) 20:20, 27 June 2013 (UTC)

## Inkscape, layers and text in Indian Rashtrakuta Empire map.svg

Hello, I am trying to create a translation of Indian Rashtrakuta Empire map.svg for the Spanish wikipedia using inkscape but I am running into a series of problems I would need the community's help with if at all possible:

• I cannot open the original file using inkscape. I get an error saying: Indian_Rashtrakuta_Empire_map.svg:12: namespace warning : xmlns: URI &ns_svg; is not absolute xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" xmlns:a="http://ns.adobe.com/AdobeSV I managed to open it by running xmllint --noent Indian_Rashtrakuta_Empire_map.svg > Indian_Rashtrakuta_Empire_map-es.svg, a command I found in the web somewhere (no idea what it really does but it works...).
• Then I tried to start translating the map that seems to have no layers, but once I try to add one to put all the text there, a layer magically turns up. It seems my new layer becomes a sublayer of the hidden one and I cannot raise or lower mine from that one. Any idea where this layer comes from and how to turn it into a regular layer I can move up and down?
• I then try to change some text in the upper right hand legend (Modern India...) but if I delete the last word of the first line of that text box the wrapping of lines breaks and I get the second line on top of the first one... Could this be the particular font (ArialMT) this text was using? Is it the text box itself? Inkscape? Any logical reason you see in this?
• Then I tried forgetting about the old text, removing it and creating a new one. No luck, the new one was created beneath the map so it was invisible. I tried the "Object/Raise to the top" option but I had no luck, the text remained below the yellow background...
• I finally tried moving the yellow background into a new bottom layer. No luck either, even if I tried to create a new lower layer the background covered all other layers (the hidden one I cannot move and my new text layer) so I ended up with a yellow "map"...

My main goal is to know if there is an easy way to turn this map into something I can easily edit under inskape, tame it into behaving like most maps do... Anything you can think of? Many thanks in advance!--Rowanwindwhistler (talk) 07:20, 6 July 2013 (UTC)

The SVG file is depressing large at 450 kB. I haven't looked at the file because I'm on a lousy internet connection.
The problems with xmlns="&ns_svg;" suggest that there was a DOCTYPE tag at the head of the file, but the DOCTYPE was removed or some ENTITY definitions within the DOCTYPE were removed. Consequently, the entities ns_svg and ns_xlink are undefined. Typically one might see definitions such as
<!ENTITY ns_svg "http://www.w3.org/2000/svg">


I would just replace the ampersand entity references with the URLs. You can do that in a text editor.
I cannot speak to the layer and text issues. Glrx (talk) 17:04, 8 July 2013 (UTC)
Thanks for your tip, Glrx. Looking at the file content, however, I think the definitions are there:
<?xml version="1.0" encoding="utf-8"?>^M
<!-- Generator: Adobe Illustrator 12.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 51448)  -->^M
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [^M
<!ENTITY ns_svg "http://www.w3.org/2000/svg">^M
]>^M
<svg  version="1.1" xmlns:x="&ns_extend;" xmlns:i="&ns_ai;" xmlns:graph="&ns_graphs;"^M
width="1638.55" height="1852.41" viewBox="-491.5 -522.36 1638.55 1852.41"^M
overflow="visible" enable-background="new -491.5 -522.36 1638.55 1852.41" xml:space="preserve">^M



Those are the first lines of the file and it seems to me the lines you suggested are indeed in the DOCTYPE part or are they incorrect? Thanks again.--Rowanwindwhistler (talk) 18:12, 8 July 2013 (UTC)

Rowanwindwhistler -- I removed most of the Adobe Illustrator garbage, so now there should be a better chance of opening the file with another program. The lack of layers is because what structure there is is through plain unadorned "<g>" elements, without the additional tagging that Inkscape uses to identify layers... AnonMoos (talk) 02:55, 9 July 2013 (UTC)
Right you are, it works in inkscape now so it must be some incompatibility between the two programs, thanks a lot. I will try to see if I can start slowly moving objects to separate layers so that I can handle them easier. I still wonder about the reason for the non-wrapping text...--Rowanwindwhistler (talk) 07:12, 9 July 2013 (UTC)
Inkscape "flowed text" is based on an old draft of the SVG standard which was not formally adopted, and is completely incompatible with the software on Wikipedia/Commons. "Flowed text" should be stringently avoided in all SVG files uploaded here... AnonMoos (talk) 09:27, 9 July 2013 (UTC)
The header lines look fine, so then my guess would be Inkscape either does not process ENTITY definitions or got confused in processing them. Glrx (talk) 17:43, 9 July 2013 (UTC)
Doing a bit of cut and paste (using the new image) I managed to do the translation and get the different parts into different layers so that you can put some objects out of the way when editing. Thanks!--Rowanwindwhistler (talk) 21:08, 10 July 2013 (UTC)

## clipping issue from matplotlib graph

Shouldn't have the curves' tails sticking outside of the axes. And indeed when the original SVG is viewed in Inkscape, Firefox, Chrome it looks good. Is rsvg known for having problems with clipping? --Nanite (talk) 21:58, 1 August 2013 (UTC)

RSVG is known for its random bugs. I fixed it by unclipping and reclipping (but some of the thumbnails have yet to update.)—Love, Kelvinsong talk 00:22, 2 August 2013 (UTC)
Woo! Thanks. I was just looking at your cell graphics, amazing stuff! --Nanite (talk) 06:30, 2 August 2013 (UTC)

I'm trying to upload a file (File:St Philip Howard Catholic School logo.svg) which is saved as an svg but when I upload to Wikipedia, the top line of text goes. I am sure that the one I am trying to upload has these, but it doesn't show in the uploaded version. I don't have a clue why because I never saved a version of it without the top text. See also WP:Help desk#All of file not uploading. Rcsprinter (yak) @ 15:19, 5 September 2013 (UTC)

The file has text along a curve, which the SVG rendering software here doesn't understand; you need to "convert text to paths"... AnonMoos (talk) 16:32, 5 September 2013 (UTC)
I don't know how.. I'm trying 'object to path' but getting message 'no objects to convert to path in selection', whether the letters are grouped or not. I'm not such a pro with SVGs. Rcsprinter (rap) @ 16:56, 5 September 2013 (UTC)
That's more of an Inkscape question than an SVG question, so I can't really help you (I only use Inkscape to test and convert SVGs, not really to edit SVGs)... AnonMoos (talk) 02:38, 6 September 2013 (UTC)

## Hessen 1900.svg

Actually two questions: (1) Is there any way to increase the maximum output size to more than 2000 pixels width? At that size the text of the communities, cities and villages is not yet readable.

(2) Under some circumstances the file is outputted with different fonts, any way to prevent that from happening?

Thanks, --79.206.233.48 (User talk:David Liuzzo) 12:43, 22 September 2013 (UTC)

At one point 2000px was a hard limit, but I'm not sure that's the case any more; you could try experimenting (change "2000" to a larger number in https://upload.wikimedia.org/wikipedia/commons/thumb/3/3d/Hessen_1900.svg/2000px-Hessen_1900.svg.png and see what happens). As for annoying font inconsistencies, see the open unresolved issues on commons:Commons:Graphics village pump... AnonMoos (talk) 00:02, 23 September 2013 (UTC)

## File:Brescia Province Map.svg

Could you help me with the text of this map. Thaks Lkcl it (talk) 13:46, 5 October 2013 (UTC)

Resolved: Thanks. --Lkcl it (talk) 11:40, 6 October 2013 (UTC)

## I need to update the gay marriage world map, to reflect Vietnam's co-habitat status. I need help please.

How does one go about filling in blue for Vietnam?

## SVG text languages (internationalization)

A single SVG file can contain the picture texts for many languages in layers called e.g. nnn.language=ll. Displaying a particular language is a matter of its layers visibility. The [[File: syntax could contain "|language=ll" to make the relevant SVG layers visible. The daring ones could even switch the layers on automatically according to the page language (as such a name would hardly be used for anything else). The feature would probably become a standard. While waiting for renderer support of this feature, the SVG file could be passed through a simple filter to switch on/off or even remove the layers before passing it to the renderer. --A Pirard (talk) 00:00, 16 October 2013 (UTC)

## Weird smudging thing

Resolved

This was done in Inkscape. I achieved the glow effect by placing copies of the objects underneath and setting their fills to blur. For some reason I can't understand, the two blurred curly brackets on the left are coming out with a sort of smudge, as you can see. This is only evident in Wikipedia's PNG renders, as Firefox renders the actual SVG perfectly (click the image on its description page to see it raw). I can't figure out what's different about those two elements. I think what might be happening is that the blur is only occurring vertically and not horizontally on those elements (although I have no idea why). PS. All text elements are already converted to paths.

I've tried a bunch of things to fix this, as you can see in the file history. I re-produced the two gitching elements by copying and mirroring the "good" ones, but the same thing is happening. I also tried going into the XML code and copying the style attributes from the "good" blurred elements and copying them over, but no dice. Anyone have any suggestions? equazcion 11:45, 18 Oct 2013 (UTC)

So apparently if you blur something that's been mirror-flipped, it renders with these smudges in MediaWiki. I re-created objects from scratch and blurred them, and they're now fine. Thanks anyway. equazcion 14:22, 18 Oct 2013 (UTC)

## Black box when viewed as PNG (I didn't understand the above explanation)

I know that above, there was an explanation of how to fix this, but I don't understand SVGs and I don't have any vector editing software. I found this image while browsing and I do not know how to fix it. It shows up fine when I Open the SVG but when I open the PNGs, they all have a big black box on one of the keys. Thank you.Joshua1995 (talk) 21:39, 20 December 2013 (UTC)

It's due to the old Inkscape "flowtext" nonsense; I fixed the problem by opening the file in a simple text editor... AnonMoos (talk) 08:05, 21 December 2013 (UTC)

## PNG renderings of SVGs don't clip to axes

I'm getting consistent bugs with my (matplotlib) SVGs figures in which drawing is not being clipped to stay within the axes of the figure. Points within the figure are not clipped, and points outside the figure are drawn in full, as illustrated in this figure:

In all other tools I use (including the SVG itself here on Commons), points are clipped to the axes, but the Commons PNG renderings draw outside the bounds of the axes. What can I do to prevent this? -- 02:54, 21 December 2013‎ User:Aldaron

I don't know, but I looked at the SVG file and didn't like what I saw. Characters are flattened, and definition sections are scattered throughout the file instead of being at the top; some defs are inside graphics constructs. There's a lot of cruft. It turns out the definition of the clip-path is at the very end of the svg file -- after all the uses:
 <defs>
<clipPath id="p7ff5b81e1d">
<rect height="345.6" width="446.4" x="72.0" y="43.2"/>
</clipPath>
</defs>

My guess is the PNG renderer wants the definitions before the first reference to the def.
Glrx (talk) 06:20, 21 December 2013 (UTC)
That seems to have been the problem... AnonMoos (talk) 08:17, 21 December 2013 (UTC)
Thanks. So This means that matplotlob is generating bad SVG. Any thoughts on how I might get matplotlib to do a better job? Or is there a *simple* SVG repairer I could post-process my matplotlib-generated SVGs with before uploading them? AldaronT/C 12:26, 21 December 2013 (UTC)
It's generating incompatible SVG (not sure what the formal standard is). I opened the file in a text editor and consolidated the lower <defs> area with the upper one, which seems simple enough (unless you have a large number of SVGs to upload). AnonMoos (talk) 13:09, 21 December 2013 (UTC)
Thanks. I hope I'm not reduced to that as a standard part of my workflow. It seems none of the tools I've tried generate SVG that's bug-free though, so perhaps such repairs are an inescapable part of the SVG workflow. AldaronT/C 14:20, 21 December 2013 (UTC)
Note: I'm reverting the fix so I can link to a version that demonstrates the problem. AldaronT/C 13:05, 21 December 2013 (UTC)
Wikimedia uses RSVG to render SVG file which is different than other SVG standard. The reason that loading the link of the SVG file clip the axes is because you're opening the SVG in your browser natively instead of opening PNG rendered by Wikimedia. You can't blame matplotlib for generating "bad" SVG, but you could say it's unconventional to have defs after the object which applies its content. According to W3 SVG specification, clippath data doesn't have to be contained within defs.[5] If you want more accurate SVG preview before uploading to Wikimedia, try SVGcheck. -- Sameboat - 同舟 (talk) 14:54, 21 December 2013 (UTC)
I've uploaded a version generated with a different matplotlib backend (Agg) as EPS, which then convert to SVG. Can someone have a look at the SVG now and see if it still has the issues raised by Glrx? AldaronT/C 15:36, 21 December 2013 (UTC)
I haven't been able to look at the whole file (network problems), but it looks like a bloated, flattened file. It's sad when an SVG file loses to an uncompressed bitmap. Somebody should start grading SVG output.... Glrx (talk) 02:35, 22 December 2013 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Thanks for taking a look. I'd appreciate it if you could have a look at another file I'm experimenting with (closer to the ones I'll be contributing) and tell me what you can about the SVG you see there:

I'm not experienced with SVG issues, so I'd be grateful for a bit of explanation of what the issues are that you see (for example, what do "bloated" and "flattened" mean), and what I might do about them without editing the text directly — for example in Adobe Illustrator I have quite a range of export options to choose from (font embedding, export formats, etc.) as well as the ability to do some grouping and ungrouping of content before exporting, that might improve the resulting export. AldaronT/C 14:56, 23 December 2013 (UTC)

It also appears bloated and flattened. I haven't been able to load the file to look at how the point plotting was done, but I expect drawing primitives rather than using symbols.
Bloated means the file is huge for what it's trying to do. The file is 470 kB.
Flattened means the hierarchy of the original source has been removed. Instead of displaying a text string such as "Hello world." in a particular font at a specific location, the individual characters have been converted to filled curves (each character is drawn as a geometric figure rather than text). That takes a lot more space; one character gets turned into hundreds of bytes of curve information. It makes the file immune to font substitution, but it also means the file cannot be easily edited or translated to another language. Hierarchy is lost in other places, too. SVG objects can inherit properties such as stroke-width from an ancestor; if there's no hierarchy, then there's no ancestor, therefore all the relevant properties must be specified in the SVG object. Flattening the hierarchy helps bloat a file.
I don't have any recommendations about what to do because there are advantages and disadvantages. Font embedding would make the file larger because the font is stored in the file; it makes the actual appearance of the figure more repeatable because there's no font substitution (font height and character spacing are troublesome issues). Font embedding can also mean a couple of different things; it may imply converting characters to curves rather than supplying an honest-to-god font. Grouping may help retain some hierarchy, but then it may not; I'd guess that it has little practical effect with most applications.
Generally, I've used pedestrian Unicode fonts. I don't embed fonts, and I don't convert characters to curves. I allocate plenty of space for the displayed strings so there's room for some font size and spacing variations, but I still get burned. Left, center, and right text alignments work in most renderers, but baseline alignment does not. I use the baseline alignment that I think is best for the illustration, and then I hope the renderer does a passable job. I live with the failings and hope that they are fixed in the next release.
Glrx (talk) 18:58, 24 December 2013 (UTC)
Unless you're making fine art, for graph like this there is absolutely no advantage by converting text to path shape. Technically speaking there is no "font embedding" in the said SVG files as each glyph object contains path data individually, so for example, the path data of the glyph "2" is repeated 8 times in Exo_Test.svg. The small color dots also share the same problem with text for repeating the same path data whenever the shape duplicates at different position. The source shape should be contained within defs and used outside to reduce the repeated path data. Also I am amazed at the dot shape that is created by a fiddly path data like this: "c 0.796,0 ,1.559 -0.316,2.121 -0.879 c 0.563 -0.563,0.879 -1.326,0.879 -2.121 c 0 -0.796 -0.316 -1.559 -0.879 -2.121 c -0.563 -0.563 -1.326 -0.879 -2.121 -0.879s -1.559,0.316 -2.121,0.879 c -0.563,0.563 -0.879,1.326 -0.879,2.121 c 0,0.796,0.316, 1.559, 0.879,2.121 C 384.1,325.767, 384.863,326.083, 385.659,326.083 L 385.659,326.083 z", which can be easily replaced by the circle element. I've seen enough SVG files created by Illustrator which defeat the purpose of using this format. -- Sameboat - 同舟 (talk) 13:27, 1 January 2014 (UTC)
Agreed. Unfortunately, I don't have control over what Ai does. It seems to take no advantage whatsoever of the semantics of the objects in the file — or perhaps the problem is with the EPS or PDF that I start with? AldaronT/C 23:23, 1 January 2014 (UTC)
An idea that may work is opening the file in Inkscape, and then resaving as a plain SVG. I believe Inkscape will automatically consolidate and put defs up at the top. For me, at least, that would be less tedious than editing the files by hand. — trlkly 18:36, 13 January 2014 (UTC)

## Best practice for "upgrading" to an SVG

What is the best practice for replacing a PNG on commons with an SVG version? For example, ideally it would be possible for all uses of somefile.PNG to be automatically replaced by a new somefile.SVG without having to edit all the articles where the PNG is used. Can a redirect or move be used for this purpose? What are the correct steps to accomplish this? AldaronT/C 18:53, 24 December 2013 (UTC)

My understanding is limited, but here's how I understand the practice. Redirects are not used. On the PNG page, the template {{vector version available}} is used to tell editors that there is a replacement SVG file. (Also see instructions at {{Should be SVG}}.) For example, File:Erste Ionisierungsenergie PSE color coded.png uses that template to point to File:First Ionization Energy.svg. If the SVG file is a suitable replacement, then the pages that link to the PNG may be edited to link to the new SVG file. I believe that is a manual process now, but there is some assistance now and there may be more robot assistance in the future. The template also puts the PNG in Commons:Category:Vector version available so editors interested in upgrading images can easily find them. Those editors or editors reading an article may click on the PNG file link, notice there's an SVG, and decide to do the replacement. In the FIE.svg case, I changed some links on the en.WP but left other links alone; other editors then linked the file to articles in six other WPs; a few days ago I changed one PNG link on the de.WP because SVG language localization now works (previously, the original PNG was better there because it had German titles and the SVG would only display English titles). Glrx (talk) 19:34, 24 December 2013 (UTC)

## Color v. black and white

Can SVG be sensitive to the surface upon which it renders?

Many technical drawings are bilevel images and use cross hatches to show sectioned material. On a color display, it's convenient to use color fills, but if a color-filled image is printed on a black and white printer, the result can be poor. Is there a good SVG method so that color fills are used on color surfaces and pattern fills on black-and-white surfaces? I do not see any appropriate feature for a switch. Is there a reasonable CSS approach?

I also have some oscilloscope illustrations. On a color display, they are white lines on a blue background. For a black-and-white printer, the rendering should switch to black lines on a white/transparent background.

Glrx (talk) 18:04, 31 December 2013 (UTC)

SVG is basically a "declarative" language, so don't expect too many "imperative" programming constructs. However, SVG does have a switch element, and recently Commons has been set up to allow a single SVG file to have different renderings for different languages. I don't know whether it can do what you want it to do... AnonMoos (talk) 01:48, 2 January 2014 (UTC)
My impression is that SVG won't do what I want unless I use scripting or select an alternate CSS. The switch element (which I've used a lot) does not have a feature string for bilevel/grayscale/full color, so it cannot do what I want. Even if it did have an appropriate feature string, it would still be awkward because switch cannot be used to select a def (defs are not in rendering tree). Personally, I don't think images should have eval/imperative; that's a Pandora's box that PostScript has. Glrx (talk) 03:08, 2 January 2014 (UTC)

## Implications of differing approaches to font handling

My SVG generation workflow gives me three options for handling fonts in SVGs, each of which produces figures with different shortcomings, and I'm looking for guidance on which approach is "best" from a MediaWiki upload point of view:

1. 'svg.fonttype' = 'none', which "assumes fonts are installed on the machine where the SVG will be viewed" (or rendered in the present case), and results in an "original image" that does not display the correct font;
2. 'svg.fonttype' = 'path', which "embeds characters as paths" and preserves fonts in the original, but, I expect, at the expense of a bloated file; and,
3. 'svg.fonttype' = 'svgfont', which "embeds characters as SVG fonts".

I'm wondering which of these three settings is best for use here. (I also wonder why the gridlines present in the upload, and which appear in the MediaWiki rendered PNGs, don't show up in the "original"). AldaronT/C 03:28, 12 January 2014 (UTC)

In my opinion option 1 is the best – you should however pick a font which actually is available on Wikipedia to allow the correct rendering of the file (you can use generic families like sans-serif though, or font stacks like Arial,Liberation Sans,sans-serif if your SVG generation worflow allows for it). If you don't want to care about fonts and need an accurate rendering you have to stick with option 2 (which produces bloated files as you noted and – even worse – makes it impossible for others to modify any text, fix spelling errors, create translations, etc.). Option 3 doesn't work on Wikipedia since the SVG renderer used (RSVG doesn't support SVG fonts. --Patrick87 (talk) 04:15, 12 January 2014 (UTC)
I agree with User:Patrick87. Glrx (talk) 05:16, 12 January 2014 (UTC)
Excellent, thanks to you both! AldaronT/C 12:55, 12 January 2014 (UTC)
One thing that confuses me though is that the font in question (Bitstream Vera Sans) is available on Wikipedia. AldaronT/C 18:27, 12 January 2014 (UTC)
Your svg file specifies "font-family:Bitstream Vera Sans;font-style:normal;"; the font list does not include "normal"; "normal" may be different from "Roman". It's odd that WP's sans-serif font has a "Roman" style. Glrx (talk) 20:20, 12 January 2014 (UTC)
Any idea why "Bitstream Vera Sans" seems to be ignored? AldaronT/C 21:49, 12 January 2014 (UTC)
Glrx -- sometimes in font names, "roman" can mean non-bold, non-italic...
Aldaron -- as you're discovering, option 2 is the only one which is guaranteed to work all the time with Wikimedia software... AnonMoos (talk) 00:22, 13 January 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Yes, unfortunately. It seems that to work reliably with Wikimedia rendering, paths (option 2 above, bloated though it may be) are the only way. AldaronT/C 01:42, 13 January 2014 (UTC)

## Macrons not rendered correctly

I just uploaded . It has macrons in it, but when Wikipedia rendered the image as png they turned into an IPA character. How do I get it to render correctly? The file was declared as UTF-8. Thanks! Garfieldnate (talk) 05:29, 15 January 2014 (UTC)

The original version of the SVG file had some issues, but no character encoding problems, so I really don't know where the "fi" ligature nonsense came from. The most-recently uploaded version (as of now) is straight 7-bit ASCII, but still doesn't fully work... AnonMoos (talk) 14:59, 15 January 2014 (UTC)
Finally figured it out -- you specified a TeX font, which was apparently using a weird TeX-internal character encoding (not even ASCII-compatible). I changed this to a non-TeX font, and now it works... AnonMoos (talk) 16:43, 15 January 2014 (UTC)

## Glencairn whisky glass

I'd like to request a silhouette be created for the "Glencairn whisky glass" seen here: [6] 71.236.253.188 (talk) 10:12, 16 February 2014 (UTC)

## Clickable hotspots?

I created this image as a replacement for this fuzzy one. It has wikilinks embedded in it so if you click an Apple II model, it jumps to the article (just like the original does). But when it displays on wikipedia, as below, the hotspots are disabled and instead, the whole image becomes clickable and it brings the user to the wikipedia page for the image.

Clicking through, the user eventually gets to the raw SVG (like here), where the hotspots are clickable, but this is not the desired behavior. Is there any way to correct this, so the Apple II models are actually clickable when embedded in an article? — Frεcklεfσσt | Talk 16:51, 25 February 2014 (UTC)

Dynamic and scripting features of SVG file are generally not carried over to the PNG renderings. There are other ways to do this; see links from Category:Wikipedia image maps etc. AnonMoos (talk) 18:12, 26 February 2014 (UTC)

## Black boxes in wikimedia PNG render but not in SVG original file

https://commons.wikimedia.org/wiki/File:Singapore_MRT_and_LRT_System_Map.svg
SVG shows up correctly in wikimedia but blackboxes still appear in the PNG render.
Aforl (talk) 03:48, 26 February 2014 (UTC)

Mysterious black rectangles in rendered PNGs are almost always due to Inkscape "flowtext" nonsense, which can be diagnosed at commons:Commons:SVG Check. Sometimes empty "flowtext" elements can be left behind in a file, which can be hard to detect or delete in Inkscape, but which nevertheless still show up as black rectangles in rendered PNGs. I'll take a look at the file in a minute or two. AnonMoos (talk) 04:59, 26 February 2014 (UTC)
Thanks. Problem resolved, help appreciated Aforl (talk) 08:11, 26 February 2014 (UTC)

## Image not seen in Chrome, visible in IE

https://en.wikipedia.org/wiki/File:Brochosome_model1.svg This image is not properly shown (invisible or instantly disappears) when viewed in my Chrome browser, although perfectly visible in Internet Explorer v. 11. Please help! -- 22:28, 4 March 2014‎ User:Roman Rakitov

Actually the linked file is not a vector graphics at all. It's only a raster graphics embedded in SVG. Why it isn't shown in Chrome is not really worth figuring out therefore. As a start it's not even using valid SVG syntax. Shame on Adobe Illustrator with it's inferior SVG support... You should try to export a real vector version if possible which will possibly also fix the rendering problem. --Patrick87 (talk) 00:33, 5 March 2014 (UTC)
Roman Rakitov -- If you don't have a way to make a real vector version, it would be best to upload the 64k JPEG as a JPEG file (filename extension ".jpg")... AnonMoos (talk) 00:49, 5 March 2014 (UTC)

## Rendering SVG at small sizes

I made this (and other) SVG files by hand and they're definitely valid and simple. However, at small (thumbnail) sizes, I'm getting an all black rectangle:

250 pixels
200 pixels
150 pixels
100 pixels

Any ideas? I'm guessing it has to do with the handling of patterns, but I'm not sure. Thanks, 04:15, 9 March 2014 (UTC)

commons:User:Sarang could probably say something about this; see File:Star of the Solomon Islands.svg etc... AnonMoos (talk) 10:40, 9 March 2014 (UTC)

Funny: Sarang used a straight path with huge width which runs vertically across the image. This path is set to be dashed to create the stripe pattern. Might be a workable workaround then, since the issue you're observing seems to be an RSVG bug after all.
P.S. Here's a template you can use to create the image. --Patrick87 (talk) 14:19, 9 March 2014 (UTC)
Perfect. Thank you both! 14:34, 9 March 2014 (UTC)

## Question on editing SVG files

Hello. I was wondering if anyone can answer me a couple of question. I've downloaded one SVG file recently with intention of doing some minor edits, namely changing the colors. However I noticed that even though I am not changing anything in the files (except replacing one color with another) that the size of the SVG file increases for some reason when I save the changes made, why is that? Also one other "stupid" question, does the SVG file loses quality when copied or edited in any way? Thank you. Shokatz (talk) 18:28, 13 April 2014 (UTC)

Most often, such a size increase means that your SVG editor is inserting a lot of constructs specific to that editor, which can help if the file is repeatedly re-edited using the same program, but will have no meaning to other programs (including RSVG on Commons). In Inkscape, you can cut down on some of this by choosing to save as "Plain SVG", not "Inkscape SVG". SVG files can lose quality if edited poorly, but quality loss is by no means mathematically certain (as is the case with JPEG generation loss)... AnonMoos (talk) 08:54, 15 April 2014 (UTC)
P.S. SVG files are actually text files, so you can open them in a text editor to compare before and after versions. AnonMoos (talk) 09:01, 15 April 2014 (UTC)
Ok, thank you for answering. That explains it...I was in fact editing the image in Inkscape, seems it's adding some additional info every time I edit, even if very simple and minor edits. Thanks again. Shokatz (talk) 08:52, 26 April 2014 (UTC)

## font scaling problem at some thumbnail sizes

I recently converted all the path-text in [[:File:]] to proper text. I have had a lot of problems with it, however. Throughout the editing process, I kept having problems with the text being a different relative size in the thumbnails. The text seems to change alignment depending on the image size. I even originally used Liberation Sans, which explicitly is stated to not have scaling problems.

I've never had this much problem with text before. Even right now, the text is not properly aligned on the file page, even though it is perfectly centered on my machine. And I'm afraid to mess with it since it's the first time I've gotten it to look right at 300px--the size used in the articles.

Note, the fact that I used groups to declare common text styles does not seem to be the problem, as I've tested versions that did not use the groups. So I'm not sure what to do. Is it really an rSVG bug, as I assumed when I uploaded, or is there something else that can be done? — trlkly 07:40, 20 April 2014 (UTC)

I assume you are referring to File:Diagram Damage to Cancer Wiki 300dpi.svg (the link is missing)? I can't see an obvious problem there but there are two points to consider:
• libRSVG uses Font hinting. That means the text's relative size slightly varies with rendering size to better align letters on physical pixel boundaries.
• Therefore when generating SVGs for Commons/Wikipedia you should
a) include some "safety distance" to borders to account for potential changes in text size compared to the rendering of your SVG editor and
b) set all text alignment to "centered" (at least in the example above) as it will make sure text will always be positioned in the center of the textboxes, even if it changes size.
Those two hints make also sure the SVGs are rendered well in other software using hinting (e.g. Firefox) and increase compatibility across systems (e.g. if the specified font is not available and a slightly different variant is used). --Patrick87 (talk) 00:09, 21 April 2014 (UTC)

## Is it possible to flip an SVG image?

I want to vertically flip File:Royal Coat of Arms of the United Kingdom-Lion.svg. Is it possible to use wiki-markup or any template? I don't want to flip it in a program and upload again. --Thmmrth (talk) 14:01, 21 April 2014 (UTC)

I'm pretty sure that SVG source code edit is the only way... AnonMoos (talk) 14:55, 21 April 2014 (UTC)
Use style="transform:scale(x,y)" in the div element and nest the object (anything within will be affected including text and image). P.S. you can actually add scale(x,y) in the transform attribute of the layer1 "g" element of the SVG file for the similar effect, but it also requires readjusting the translate values to reposition the object within the canvas properly. -- Sameboat - 同舟 (talk) 15:37, 21 April 2014 (UTC)
Note that the plain transform attribute does only work for current current browsers though! See [7] for the compatibility list. Older versions support transform attributes only via native extensions, very old browsers not at all. In this case I assume editing the SVG is the best approach (at least if you're aiming for highest compatibility). --Patrick87 (talk) 17:20, 21 April 2014 (UTC)
Thank you for your help. --Thmmrth (talk) 01:32, 22 April 2014 (UTC)

## Problems with switch translation displays

The file file:First Ionization Energy.svg has several language translations via switch. On Commons, there's a drop down box to display the various languages. That works for most languages, but when I select zh-Hans or zh-Hant, the drop down resets to en and displays the English version. If I modify the URL by appending &lang=zh-hans, then the Chinese version displays.

The light is beginning to dawn. If I append &lang=zh-Hans, then English displays. Looks like the combo box is flexible about capitalization, but another agent is filtering the IETF language tag for case. I need to check proper capitalization. Glrx (talk) 20:25, 20 August 2014 (UTC)

proper script variations are "Hant" (Han traditional) and "Hans" (Han simplified).
regions are all cap CN HK SG TW (but I don't think they are effectively used in the file)
I'll have to check the file, too.
Glrx (talk) 20:33, 20 August 2014 (UTC)
zh-Hans and zh-Hant are listed as "redundant" in the language subtag registry but don't have a preferred value.
Glrx (talk) 21:00, 20 August 2014 (UTC)