Wikipedia:SVG help

Jump to navigation Jump to search
Create a new request

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.

Things we can help with

Understanding SVG

  • Questions about the SVG format

Using SVG appropriately

  • When to (or not to) use SVG

What you see is not what you get

  • 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[edit]

flowRoot does not appear[edit]

a picture containing SVG1.2-valid flowRoot

If black box appear, read c:User:JoKalliauer/RepairFlowRoot how to solve this issue, but do not remove those objects since they might contain text. The workarounds that one can employ are either not to use flowed text (by using the text tool without creating a text field), or convert the text to normal text (by Text-editor or sed-comand, or with Inkscape-GUI or with a Inkscape-batch), but to stroke the text using "object to path", since path-text is not recomended and increases file-size.

font-family issues[edit]

Rendering anomalies of small fonts in thumbnail views
Fallback fonts

Due to copyright restrictions, MediaWiki cannot use proprietary fonts that are commonly found on several proprietary operating systems. Fonts such as Geneva require licensing 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. This approach facilitates editability.
  • One can specify a generic font-family such as "sans-serif", "serif", or "monospace", but this can lead to inconsistent rendering. It is better to specify a font available on Wikipedia (such as Liberation Sans) with fallback fonts such as: font-family="Liberation Sans,Arial,Helvetica,sans-serif", in which you define a font-list with similar fonts that at least contain one font for each Operating System such as Wikimedia (e.g. Liberation Sans), Windows (e.g. Arial), Linux (e.g. Liberation Sans), Mac (e.g. Helvetica).
  • Since local rendering should be as close as possible to Wikipedia, it should use locally the same font as it will have on Wikipedia, if available. Therefore always define a Wikimedia-font first. Also, Wikimedia has synonyms for substituting fonts, such as "Arial" for "Liberation Sans"; therefore font-family="Arial,DejaVu Sans" will be rendered by "Liberation Sans" and not (as expected) by "DejaVu Sans".
  • Converting the text into paths increases file size, and is therefore generally disfavored (except for text logos, etc.).
  • Group the text, create a copy, and convert the copy to paths. Then either:
1. move the original, editable non-path text into a separate editable text layer that you make transparent (warning: this might be removed by SVG optimizers), or
2. move the original, editable non-path text outside the visible area (example: File:Essigsäuresynthesen.svg).

For ease of subsequent editing and significantly smaller file sizes, substituting the font with an available font is recommended. Many common fonts have non-proprietary alternatives that are 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.

Wikimedia has default fonts, and will use Liberation Serif for Times New Roman and Liberation Sans for Arial. For further fallbacks see c:Help:SVG#fallback.

Fonts that are available on Wikimedia servers 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 may be necessary.

bad letter-alignment on small font-size[edit]

Librsvg calculates the letter-distances inaccurantly for font-sizes of 20px and below.

For a text like

<svg viewBox="0 0 100 100" xmlns="">
 <text x="20" y="30" font-size="5px">exampletext</text>

you can replace it with:

<svg viewBox="0 0 1000 1000" xmlns="">
 <text x="200" y="300" font-size="50px">exampletext</text>

or with

<svg viewBox="0 0 100 100" xmlns="">
 <g transform="scale(0.1)"><text x="200" y="300" font-size="50px">exampletext</text></g>

Missing embedded JPEG images[edit]

Normal image
Broken image

When a raster graphic is embedded in an SVG it is encoded into base64 data. That data is then assigned a MIME type in the <image> element. In the case of an embedded JPEG, the MIME type is "image/jpeg". Older versions of Inkscape (and possibly other editors) assigned the MIME type "image/jpg". While Inkscape and most web browsers will display such an SVG image just fine, the MediaWiki software that rasterizes the SVG file will have trouble with it. Not recognizing the MIME type "image/jpg" there will simply be an empty space where the image is supposed to be. The fix is to open the SVG file in a text editor, find the <image> element, locate "image/jpg", change it to "image/jpeg" and re-save. At right is an example of this problem. The Commons SVG Checker looks for this problem; see Commons:Commons:Commons SVG Checker/KnownBugs#Checks for details.

Rendering files[edit]

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 SVG files, and does not recognize some formats in text-editor SVG files. The file manager GNOME Files or c:Commons:Commons_SVG_Checker relies on librsvg, so it can be used to check the quality before a SVG is uploaded.

Rendering Inkscape files[edit]

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 librsvg 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 SVG files[edit] 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 Draw.

SVG code replacement guide (executing replace all using Nedit regular expressions)[edit]
Original text Replacement text
Sans embedded DejaVu Sans
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.

Rendering text-editor SVG files[edit]

SVG files created from scratch in a text editor may make use of any valid SVG syntax, so long as your browser supports the given version of the SVG specification. On Wikipedia however, SVGs are interpreted by the librsvg-library to create PNG previews at different image sizes. That library only recognizes a subset of all valid SVG syntax, and may render your SVG without many features. In order to bypass these deficiencies in the library, there are certain parameters that need to be formatted in specific ways or be assigned a workaround value in order for librsvg to accurately render views of your SVG file.

<mask> parameter maskUnits="userSpaceOnUse"[edit]

The librsvg-library does not interpret the value of "userSpaceOnUse" for the parameter maskUnits correctly. To bypass this issue, replace maskUnits="userSpaceOnUse" with maskUnits="-10% -10% 120% 120%", and the SVG mask will render properly on Wikipedia.

parameter stroke-dasharray[edit]

The librsvg-library does not accept a stroke-dasharray parameter with values separated by spaces. Replace all spaces with commas to bypass this issue: e.g. stroke-dasharray="2 3 2 4"stroke-dasharray="2,3,2,4"


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[edit]

Create a new request

Problems with the image[edit]

Hello. I've tried to upload this file to Wikimedia Commons. But it says Found unsafe CSS in the style element of uploaded SVG file. Also the SVG checker says the font is unsupported, but it's listed here. What should I do? Mike like0708 (talk) 17:19, 13 July 2020 (UTC)

The link you give is not an SVG image. It seems to be a Javascript-heavy web page, with buttons and things. Once the first popup appeared, I backed out - no way am I going to go further with that. What is the actual URL of the SVG image concerned? --Redrose64 🌹 (talk) 19:30, 13 July 2020 (UTC)
I'm sorry. Here it is: [1]
The problem is not the Droid Sans font, it's the entire content of the style element - this is it, in part:
<style id="droidsans700normal">
    @font-face {
    font-family: "Droid Sans";
    font-weight: 700;
    src: url("data:font/ttf;base64,");
I've omitted most of it - in between the base64, and the next quote there is 56,640 bytes of binary data.
Anyway, this uses the @font-face { ... } at-rule, which was introduced in CSS Fonts Module Level 3 (proposed 2013, not formalised until September 2018), but librsvg can't handle anything that doesn't conform to CSS level 1 (with the exception of certain CSS level 2 features). The src: property here seems to be describing the Droid Sans font, but you shouldn't need to do that - the two <text>...</text> elements both have the font-family="Droid Sans" attribute, which should be quite sufficient. I suggest that you remove everything between <style>...</style> inclusive of those tags. --Redrose64 🌹 (talk) 20:57, 13 July 2020 (UTC)
It helped. Thank you so much! Mike like0708 (talk) 09:27, 14 July 2020 (UTC)
.. but it's still rendered using another font. Also the letters move up. Looks like this. The black line is Г's part. Mike like0708 (talk) 10:02, 14 July 2020 (UTC)
Is Commons still refusing to upload it? If so, what error messages are you getting? If it uploads, what is the filename? --Redrose64 🌹 (talk) 16:52, 14 July 2020 (UTC)
The Commons tell everything's OK, the filename is not changed. Mike like0708 (talk) 14:21, 16 July 2020 (UTC)
But what's the filename on Commons? At no point above is that stated. --Redrose64 🌹 (talk) 22:13, 16 July 2020 (UTC)
Sorry for a long offline. That's called fixed2.svg. Here's a link to Commons if that helps you. Mike like0708 (talk) 20:36, 24 July 2020 (UTC)
I don't know if it helps the de-bug but I downloaded the .svg file and then opened it in my Edge browser. It looked fine, that is with a large gamma to the left of a small M, all within a grey-filed circle. For some reason the gamma gets turned into a little streak of black above the circle when viewed on Commons. Neither the .svg validators at Commons nor at "". see any errors, although the Commons validator does show the "wrong" image. Michael D. Turnbull (talk) 14:38, 25 July 2020 (UTC)
Also it looks fine if you open it in a separate tab. That's really weird. Mike like0708 (talk) 11:59, 30 July 2020 (UTC)
@Mike like0708: That file is the raw SVG being served directly to your browser, it hasn't been passed through librsvg on the way. Hence, if you use a modern browser which recognises all of the different constructs that you have used (the file contains XML, SVG and CSS) your browser will display it as intended.
When SVG images are included in Wikipedia pages, what is served is a PNG conversion from the SVG (for example, this 240px version) - this conversion is performed by librsvg, not your browser. librsvg recognises XML only if it is well-formed and valid; it reconises SVG 1.1 but nothing later; and it recognises CSS 1 (and parts of CSS 2). So if there is something in the raw SVG file that librsvg doesn't recognise, it will provide only a partial conversion to PNG. --Redrose64 🌹 (talk) 08:23, 31 July 2020 (UTC)
To continue. I'll break parts of the file down element by element, with observations. It begins with
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">
- these two lines are pure XML. The first is mandatory, the second is valid but not recommended - try removing that one. From that point on, it's all SVG apart from the content of the style="..." attributes, which are CSS. I won't comment on every element. The two <text>...</text> elements both have the attribute font-family="DejaVu Sans" - try altering that to font-family="'DejaVu Sans',sans-serif" - note the nested quotes of differing types. These elements also have the attribute style="line-height:100%" which contain the only CSS in the file, and it's valid CSS 1 so no problem there. The two <tspan>...</tspan> elements both have the attribute dy="0em" but the em unit isn't used elsewhere, so alter those to dy="0". The tspan also enclose literal text - the Greek letters Γ and Μ, it's possible that these are being misinterpreted, so alter them to numeric character references &#x0393; and &#x039C; respectively. There are eight <g> tags with no attributes, those may safely be removed together with with their balancing </g> tags. --Redrose64 🌹 (talk) 08:57, 31 July 2020 (UTC)
Just for fun, I used Inkscape to create a version of your file and loaded it to my Google cloud "here".. The export from inkscape was their "optimised" .svg file, which minimises the size to 3 Kb. I used just four elements: The outer black circle, the fill, a large text gamma and a small "M". If you look at the file in notepad, it's pretty easy to see how to alter each individual component but this still doesn't give me a clue about what went wrong with your original. Michael D. Turnbull (talk) 14:15, 30 July 2020 (UTC)
I've done all of your advice [1][2] but it still looks the same as it was. All the SVG checkers say it's completely fine. Mike like0708 (talk) 11:56, 31 July 2020 (UTC)
Well, I'm stuck then. --Redrose64 🌹 (talk) 14:09, 31 July 2020 (UTC)
Anyway, I appreciate your help. Looks like I'll have to use PNG instead. Bye! Mike like0708 (talk) 15:14, 31 July 2020 (UTC)

Poor rendering of image.[edit]

I've created several maps that share the similar features, all of their thumbnails have poorly rendered parts of image and I wondering how to deal with this issue.
Files: Map of the London Assembly election 2016, 2012, 2008, 2004 and 2000
specifically, the images see a blurred image for the map of London within the at-large seat area and the rectangles with the graph for seats. JDuggan101 talk. | Cont. 12:48, 2 August 2020 (UTC)