Wikipedia:SVG help

See also: Wikipedia:Graphic Lab/Resources/SVG and Wikipedia:Graphic Lab/Illustration workshop

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. Further information: Help:SVG

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 Testing for problems The following SVG checkers may help you to detect SVG problems before you upload: WMF Labs SVG check Commons SVG Checker w3.org validator flowRoot does not appear a picture containing SVG1.2-valid flowRoot Tracked in Phabricator Task T43424 Declined 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 Tracked in Phabricator Task T180923 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". (This is because "Liberation Sans" has the same letter size as "Arial" [metric-compatible], so it is less likely to mess up the text flow.) Converting the text into paths increases file size and prevents localization and accessibility features like text to speech, and is therefore generally disfavored (except for text logos, etc.). Group the text, create a copy, and convert the copy to paths. Then either: 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 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. font-size issues Rendering anomalies may occur in thumbnail views if small font sizes are used. Declaring font-size="35" (or larger) appears to avoid this problem, depending on the pixel size of your graphic. Fonts should be sized so that they look good as thumbnails on wikipedia pages and so they are easy to view on smartphones, which is how most people access wikipedia. Very few people click images and zoom them in to see them, so avoid using or creating images with fonts that are too small to be legible in thumbnail view. The font size that appears in a thumbnail is a combination of svg width, thumbnail width, and font size. To match wikipedia font size as a thumbnail, use font-size = (63/(your upright value))*((your svg width)/1000). For instance, if the thumbnail will be scaled up to thumb upright=1.35 and your image has svg width of 960, set font-size in the svg to (63/1.35)*(960/1000) = 44.8. Missing embedded JPEG images Tracked in Phabricator Task T193929 Invalid 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. Though Web browsers cope with image tags without width and height specified, librsvg ignores such images. Further issues Further issues can be found at c:Librsvg_bugs or at Commons:Commons:Commons SVG Checker/KnownBugs, and examples can be found at c:Category:Pictures_demonstrating_a_librsvg_bug. However most issues (for files <1MB) can be fixed using https://svgworkaroundbot.toolforge.org/ (enable "run svgcleaner" and enable "run scour" before clicking convert), for a more detailed list check c:User:SVGWorkaroundBot. 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, 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 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 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 tspan x="([0-9]*) ([0-9 ]*)" tspan x="\1" This SVG export procedure has been tested using OO 2.3.0 and OO 3.2.1 with a simple .odg candidate. Further information: Help:SVG Rendering text-editor SVG files 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" 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 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" Use xlink:href=, not href= alone, in <use ___/> statements In Wikimedia projects, <use xlink:href="#myobjectname" transform="translate(10 10)" /> will render properly if you have specified xmlns:xlink="http://www.w3.org/1999/xlink". Be aware that href= by itself will not work on Wikimedia projects even though it might render properly if directly read by your browser. CSS selectors or identifiers must start with a letter or hyphen http://w3.org/TR/css-syntax-3 states, "Property names and at-rule names are always identifiers, which have to start with a letter or a hyphen..."

General concept above; examples below.

Warming stripes (composite)

Warming stripes bar chart

Bar chart (vertical)

Pie chart

Line charts

Scatterplot

I've uploaded .xlsx (Microsoft Excel) spreadsheets that automatically generate XML code for charts in SVG format.

You simply paste or enter your data into the spreadsheet, and specify image dimensions, number of grid lines, font sizes, etc. The spreadsheet instantly and automatically generates a column of XML code that you simply copy and paste into a text editor and save as an ".svg" file. The spreadsheets produce lean SVG code, avoiding the "extra stuff" that Inkscape inserts. They should save you time in creating SVG charts.

Feedback and suggestions on my talk page are welcome. RCraig09 (talk) 23:41, 19 February 2021 (UTC)

Click HOW TO for detailed explanation.

Click HERE (else HERE) to download the spreadsheets.

Example SVG files: Category:SVG diagrams created with spreadsheet.

1. Warming stripes — Accepts a single dataset and converts to SVG code portraying Ed Hawkins' warming stripes graphics. User chooses vertical or horizontal stripes; normal or reverse data ordering; or from a variety of geometric shapes (updated 17 May 2023). . . . . Click here to see examples of warming stripes embedded in different shapes.
2. Warming stripes bar chart — Accepts a single dataset and creates a conventional bar chart whose individual bars/columns are coloured according to Dr. Hawkins' warming stripes colour scheme. Alternate option: choose one colour for ascending bars and another colour for descending bars. (updated 17 May 2023)
3. Line charts — Accepts up to five datasets. (updated 17 May 2023)
4. Vertical bar charts (column charts) — Accepts up to six datasets. Toggle between clustered and stacked charts; user can adjust "Yfloor"—the Y level (usually=0) from which columns rise or fall; user chooses to keep or ignore negative input values. (updated 17 May 2023)
5. Horizontal bar charts — Accepts up to six datasets. Toggle between clustered and stacked charts; user can adjust "Yfloor"—the value (usually=0) from which bars extend; user chooses to keep or ignore negative input values. (updated 17 May 2023)
6. Scatter plots — Accepts up to five datasets. (updated 17 May 2023)
7. Pie charts — Accepts a single dataset of up to 36 items. (updated 17 May 2023)

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

Text doesn't seem hinted on thumbnail

I'm opening @Timeshifter:'s query to our resident experts. Based on the comparison below:

Comparison of http://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Template_map_of_usa_states_and_dc.svg/400px-Template_map_of_usa_states_and_dc.svg.png (left) and Firefox rendering of the SVG at roughly the same scale (right).

am I correct to conclude that the less-legible text is due to rsvg not doing font hinting? The font size is 18px, slightly under the recommended 20px.

Thanks,
cmɢʟee⎆τaʟκ 12:21, 7 May 2023 (UTC)

cmglee and others who are interested. Only a little while ago before I saw this thread I figured out a way to view the SVG files easily at various sizes.

This is useful for bypassing all the Wikimedia software problems altogether while experimenting with the SVG file.

I put the SVG file inline between HTML and BODY tags in a Notepad++ text file. I change only the percent width setting. Say from 100% down to 30% or 50% or whatever. No need to change the height.

Then I changed the extension to .htm and let my browser open it. I can see what the US SVG map looks like at sizes used in Wikipedia articles. It opens at that smaller size. I am using Firefox browser on Windows 10 Pro on a desktop PC.

I used the HTML code in the top example here:

https://www.w3schools.com/html/html5_svg.asp

<!DOCTYPE html>
<html>
<body>
--- SVG file inline. With width of my choice. ---
</body>
</html>

This way I can test out the various text sizes for state names and values that the template allows one to try out. Also turning font bolding on and off. See: Commons:File:Template map of usa states and dc.svg.

--Timeshifter (talk) 21:34, 7 May 2023 (UTC)

cmglee. Oops. I thought I had tried changing the width in the SVG file before. Without putting it in an HTML file. But I must have done it incorrectly, or tried pixels, or various aspect ratios, or the viewbox width numbers. Without luck. But changing BOTH the width and the height in the SVG file works. Changing it to the same number. If starting at 100% for both, then drop down to any lower percentage for both numbers. The same number. Without putting it in an HTML file. Then open the SVG file in your browser to see the smaller size. Here is the SVG code line in question. After changing it from 100% to 50%:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="50%" height="50%" viewBox="9 -40 945 630">

--Timeshifter (talk) 22:31, 7 May 2023 (UTC)

You can omit either the width= or the height= attribute, whichever one is present is used as-is, and the missing one is calculated automatically from that using the proportions as set by the last two values in the viewBox= attribute. Personally, though, I point my browser directly at the SVG file, and use its zoom feature. Firefox provides both a keyboard method (Ctrl++/Ctrl+0/Ctrl+-) and a mouse method (Ctrl and roll the mouse wheel). Chrome and Opera use the same keyboard method, I don't know about mouse. --Redrose64 🌹 (talk) 00:06, 8 May 2023 (UTC)

Redrose64 and cmglee. Thanks Redrose64. On the unchanged SVG template file Chrome and Edge work with both the keyboard and mouse method. Firefox does something really weird: Image and text is the same size, but the state text values move vertically up and down the screen. The percentage values remain in place. Have to see it to believe it.

And thanks for the syntaxhighlight fixes.

Removing just the height works, but not the same as within an HTML wrapper.

The zooming method is a great help. --Timeshifter (talk) 01:29, 8 May 2023 (UTC)

Has the discussion has been sidetracked: I thought @Timeshifter: was more interested in why the text appears worse in rsvg's rendering than browsers', rather than how to get an SVG file to display at a given size on a browser? cmɢʟee⎆τaʟκ 03:31, 8 May 2023 (UTC)

cmglee. I wrote: "I want to bypass all that. Is it possible to add a user-editable way to set a thumb size in the SVG code?" I didn't even think of the zooming method. Or I maybe I tried just the scroll wheel without secondary buttons. Or I used the wrong secondary buttons. I don't remember. But in any case I was trying in the wrong browser (Firefox). But I am very happy about the zooming method in Edge and Chrome. I need to install Opera too. I hope someone answers the rsvg stuff, too. The more methods the better. --Timeshifter (talk) 07:36, 8 May 2023 (UTC)

Someone correct me if I'm mistaken, but the size of thumbnails as they appear on Wikipedia articles cannot be set in the SVG: articles will just use the size specified in the [[File:...svg|thumb|...px|...]] wikitext (if any) or the default. cmɢʟee⎆τaʟκ 09:35, 8 May 2023 (UTC)

cmglee. Sorry. I was assuming people knew that I just wanted a preview of what a map looked like at article sizes. So I could experiment and find my preferred maps before uploading to the Commons. I was more clear in our past discussions, but this is a new discussion thread, and it needs to be clear. --Timeshifter (talk) 10:53, 8 May 2023 (UTC)

@Timeshifter: if you just want to see what the SVG looks like rendered in a browser at a given size (not a Wikimedia thumbnail in an article), replace

width="100%" height="100%"

with

width="300" height="200"

or whatever size you want in pixels. I used the former so that it would fit the browser window as much as possible. cmɢʟee⎆τaʟκ 05:22, 9 May 2023 (UTC)

SVG filter and text trouble

Blocks are much lighter and "Tu" is displaced

I tried to tint some cubes in File:Extended_two_cube_calendar.svg with SVG filters and it came up very light. The text "Tu" has also been shifted right.

Though the texture looks poor in http://svgcheck.toolforge.org , the colour and text are correct.

After several attempts at fixing it, I reverted it to the 01:31, 16 February 2022 version but the bug persists. Both versions of the SVG look fine rendered by Firefox.

Can someone please help? Thanks, cmɢʟee⎆τaʟκ 03:57, 8 May 2023 (UTC)

Rather than using

<text transform="translate(50,50) rotate(90)"  y="0.7ex"><tspan>T</tspan><tspan dx="-0.3ex">u</tspan></text>

to draw the two letters individually with different offsets, try drawing them together, use the attribute text-anchor="middle" and specify the centre. --Redrose64 🌹 (talk) 20:27, 8 May 2023 (UTC)

Thanks, @Redrose64. I worked around the text shift using letter-spacing and no tspan.

The texture is still very light, though. I wonder how rsvg has changed since Feb 2022... cmɢʟee⎆τaʟκ 05:12, 9 May 2023 (UTC)

SVG text rendering, again – image displays differently in two en.WP articles!

20230529 Inconsistent simultaneous displays of same image in two articles

1. Red arrows show simultaneous inconsistent renderings between two articles of File:20220823 Public underestimation of public support for climate action - poll - false social reality.svg
2. Separately: Blue notation arrows show consistently incorrect renderings between two articles of File:20220629 Public estimates of scientific consensus on climate change - horizontal bar chart.svg, even after removing font-weight="bold" specification once thought to have caused the rendering problem
3. Anomaly may be related to anomaly found in earlier versions of File:200012 Suicide methods in order of lethality - variable-width bar chart.svg, which was discussed at Wikipedia:SVG help/Archive 9 at en.WP

At the present moment, sometimes the files display correctly for me on Commons but still not on en.WP. —RCraig09 (talk) 19:12, 29 May 2023 (UTC)

• 

  20220629 Public estimates of scientific consensus on climate change - horizontal bar chart.svg – BLUE notation arrows

• 

  20220823 Public underestimation of public support for climate action - poll - false social reality.svg – RED arrows

• 

  200012 Suicide methods in order of lethality - variable-width bar chart.svg (previously discussed)

I've resolved to avoid use of italics and bold text, but... even that doesn't seem to avoid the problem(s).

Is there a central place to report such bugs? —RCraig09 (talk) 19:12, 29 May 2023 (UTC)

@RCraig09:

1. Did you try c:Help:Purge ?
2. Wikimedia Bugs can be repoted at phab:maniphest/task/edit/form/43/

 — Johannes Kalliauer - contrib. 04:12, 30 May 2023 (UTC)

@JoKalliauer: Many times I've tried Shift-Reload (Chrome for Mac), and I just tried ?action=purge as you suggested. The problem remains—same on my iPhone's Safari browser.

Are you (or any other readers) seeing the anomalies also? (below and on the en.Wikipedia pages:)

• Climate change in the United States#Public opinion about climate change
• Public opinion on climate change#Public surveys

It's not just my one device. Thanks for any feedback. —RCraig09 (talk) 04:58, 30 May 2023 (UTC)

In File:20220629 Public estimates of scientific consensus on climate change - horizontal bar chart.svg I think I've found a work-around: avoid <tspan> specifications. Part of the code change is shown below:

• Version 6 incorrectly renders the two title text elements off center to the right:

<switch>
<text x="525" y="50" fill="#0099aa" font-size="45px" id="trsvg22-ja" systemLanguage="ja">
<tspan id="trsvg1-ja">一般市民による評価</tspan>
</text>

<text x="525" y="50" fill="#0099aa" font-size="45px" id="trsvg22">
<tspan id="trsvg1">Public estimates</tspan>
</text>
</switch>

• Version 7 replaces the <text> and <tspan> with <g> and <text> specifications:

<switch>
<g fill="#0099aa" font-size="45px" id="trsvg22-ja" systemLanguage="ja">
<text x="525" y="50" id="trsvg1-ja">一般市民による評価</text>
</g>

<g fill="#0099aa" font-size="45px" id="trsvg22">
<text x="525" y="50" id="trsvg1">Public estimates</text>
</g>
</switch>

The changes to Version 7 appear to avoid the problem—in the first file. —RCraig09 (talk) 17:13, 30 May 2023 (UTC)

However, there is no <tspan> specification in the second file, File:20220823 Public underestimation of public support for climate action - poll - false social reality.svg.

      <g font-size="40px" font-family="Liberation Sans,sans-serif" text-anchor="middle" fill="black">
<text x="700" y="50">Public's underestimation of support</text>
<text x="700" y="95">for action against climate change</text>

(other text specs)

      </g>

So I still don't know a solution. —RCraig09 (talk) 17:26, 30 May 2023 (UTC)

Update: For Version 3, I made text-anchor="middle" explicit in each <text> specification (not just inherited from group <g>), and that seems to have avoided the problem in the only article that was having a problem before (Climate change in the United States).

 <g font-size="40px" font-family="Liberation Sans,sans-serif" text-anchor="middle" fill="black">
<text x="700" y="50" text-anchor="middle">Public's underestimation of support</text>
<text x="700" y="95" text-anchor="middle">for action against climate change</text>

</g>

Problem avoided; bug not solved. —RCraig09 (talk) 17:58, 30 May 2023 (UTC)

text-anchor="middle" workaround not working

X^c badly spaced

Re the advice in the previous section, I added text-anchor="middle" to each problematic text in the attached SVG but the spacing is still really poor compared to before the latest rsvg change.

Can someone please refine the guidance?

Thanks,
cmɢʟee⎆τaʟκ 00:27, 5 June 2023 (UTC)

User:cmglee: Sorry, I don't understand all the coding in File:Punnett_square_colour_blindness.svg. I can only suggest experimenting with avoiding <tspan > specifications altogether, for example to achieve superscripting. Instead, manually place each character in a separate <text > specification. It's crude and time-consuming, I know, but <tspan > specifications been involved in several text-related SVG rendering problems. Sorry I don't have a solution, only a work-around. —RCraig09 (talk) 01:05, 5 June 2023 (UTC)