Wikipedia:SVG help

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:SVG Help)
Jump to: navigation, search
Ark-icon.svg
Create a new request
Ark-icon.svg

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 that can be helped with on this page


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]

Missing objects or black boxes[edit]

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 (based on the librsvg library which is used by Wikimedia to rasterize SVG files), 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[edit]

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

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.

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

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

Assistance[edit]

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

World Map Is Outdated:[edit]

Can somebody help me with two different world map .svg files on Wikipedia? These two maps are outdated and I want to update them and add sources, but I do not know how to open the file. In Correct (talk) 08:50, 2 February 2017 (UTC) c:File:Global_Map_of_Male_Circumcision_Prevalence_by_Country.svg c:File:Global_Map_of_Male_Circumcision_Prevalence_at_Country.svg

@In Correct: Go to the file description pages on Commons (I've modified the links above accordingly), and at the top of each you should find a "Download" link, which will allow you to save the SVG source to your machine. You can then edit it using a plain-text editor, or with suitable software such as Inkscape. If you don't feel confident, you can put a request at WP:GL/MAP. --Redrose64 🌹 (talk) 15:28, 2 February 2017 (UTC)

Problems with the PNG renderer?[edit]

There seem to be some issues with the PNG render (though obviously we could be missing something) (discussion here). The text on this automatically converted SVG does not display properly when rendered into PNG (there are/were problems with the text placement, kerning, etc.). Some work has been done to mitigate the issue, (by manually retyping the text) though this of course isn't ideal since it isn't totally fixed and will need to be done again every time the image needs to be updated (which is regularly).

Is this a known issue? What can we do about it? Is there a more specific place I can direct this technical question?

(Pinging @Cherkash:) Thanks for your help. ♫CheChe♫ talk 12:02, 8 February 2017 (UTC)

Fonts have been a long-standing issue. To some degree you can mitigate layout problems by downloading to your own computer free fonts which you know are on the Wikimedia RSVG server, and using such fonts in your vector editor (Inkscape etc.), though that's by no means guaranteed to fix all font-related problems. The one quick-and-dirty fix which almost always works is "convert text to paths" (though at the expense of reuseability/translatability)... AnonMoos (talk) 01:17, 9 February 2017 (UTC)
The issue is not only with how fonts get rendered (which could potentially explain kerning issues), but also with text placement (which has nothing to do with actual font rendering, which should affect shape, but not position). cherkash (talk) 05:08, 9 February 2017 (UTC)
I have seen SVGs converted from PDFs where the "text" contained no words at all. Each individual letter had its own <tspan>...</tspan> element, each of these in turn was wrapped its own <text>...</text> element. One of these (I forget which) had the x= and y= attributes to position the letter concerned. It wasn't the fault of the PDF→SVG conversion, since the PDF also positioned each letter separately. Very inefficient. --Redrose64 🌹 (talk) 11:22, 9 February 2017 (UTC)

Problems with subtitles[edit]

Hello everyone! I translated tow maps (file:Polska 992 - 1025-pt.svg and file:Kabyle-Roman camp-pt.svg) and I'm having the same problem with both. The subtitles of them are wrong, always when I try to fix them they continue appearing as you see now (the letters are unreadable and unconfigured). I tried many times and for the first one I asked Rowanwindwhistler (talk · contribs)'s help, but even him could't find the problem. If one of you could help with it I will appreciate very much.

Cheers, --Renato de carvalho ferreira (talk) 23:49, 23 February 2017 (UTC)

Something is odd, I played around with the second file and tried opening it directly in a browser (which in firefox produced some really odd results). I do note that the font-size is very small according to the actual file, e.g, "font-size:0.27726999px" and transformed. --Erp (talk) 04:42, 24 February 2017 (UTC)
I really don't know what the author of the second map did because I can't even erase parts of the map. It's like there is a kind of "protection" against such edition. About the text, I tried many times copy and past my subtitles thinking that the problem could be that the text was in a wrong layer, but the map has one layer anyway.--Renato de carvalho ferreira (talk) 05:11, 24 February 2017 (UTC)
Cplakidas (talk · contribs) - Constantine, do you have any idea?--Renato de carvalho ferreira (talk) 05:13, 24 February 2017 (UTC)
As Erp has said, the problem is really the font-size being is too small. Librsvg on Wikimedia for rasterizing SVG into PNG is extremely inaccurate (to the point erroneous) to upscale text. Do not attempt to use transform="scale(x,y)" to upscale the text, the result is exactly the same. You need to restore the font-size to like 20px and then downscale with transform/scale and reposition all text manually.
If you can't edit the SVG in your vector graphic editor, save a "Plain SVG" copy in Inkscape and open the "plain" version to try again. -- Sameboat - 同舟 (talk · contri.) 07:09, 24 February 2017 (UTC)
The first file is simply huge, unnecessarily so, since there is not enough detail to require that, and the font size to small; you could simply rescale the file to something smaller and at the same time increase the font size. After that, I'd also suggest converting the text to paths for better scaling. I've edited the second file in Inkscape, and with a few tweaks it has worked fine. Constantine 07:18, 24 February 2017 (UTC)
For my edification, what tweaks did you use? --Erp (talk) 16:40, 24 February 2017 (UTC) Followup: I handedited the file to remove the width, height, and viewbox at the beginning. Opened in Inkscape, select all, scaled to a reasonable size, reset page size under document properties to match size of drawing, and reset all the text to a font and font-size combo. --Erp (talk) 17:15, 24 February 2017 (UTC)

Problem with File:Flag of the Philippines.svg[edit]

Resolved

I am trying to troubleshoot why File:Flag of the Philippines.svg does not display properly at Template:Country_data_Philippines. As far as I can tell, the template code is essentially the same as Template:Country data Japan, but the default flag does not display when the {{flag}} template is used (see the template documentation for examples of the "broken image" icons).

Could there be a problem with the SVG file? I looked at the SVG file code but did not see anything that I understood. Thanks. – Jonesey95 (talk) 19:54, 28 February 2017 (UTC)

What are these "broken image" icons and where exactly are they? --Redrose64 🌹 (talk) 20:02, 28 February 2017 (UTC)
You can see one at User:Jonesey95/sandbox3 and many at Template:Country_data_Philippines. The broken image links to https://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Flag_of_the_Philippines.svg/23px-Flag_of_the_Philippines.svg.png. Strangely, other px sizes like 20, 25, 30, 50, and 100px all work fine, but 23px is broken. Is that a clue?
https://upload.wikimedia.org/wikipedia/en/thumb/9/9e/Flag_of_Japan.svg/23px-Flag_of_Japan.svg.png works fine. – Jonesey95 (talk) 20:29, 28 February 2017 (UTC)
And... now it's working for me. Either something changed, or I just had to clear my cache. Strange. – Jonesey95 (talk) 20:38, 28 February 2017 (UTC)

Issue with image scaling[edit]

I've just uploaded an SVG image but it is not displaying properly when a thumbnail is generated. It is displaying as black when scaled. Can anyone help?

The file is File:Conmebol.svg.

TheBigJagielka (talk) 19:04, 17 May 2017 (UTC)

@TheBigJagielka: You have this element:
<style
       id="style2">.a{fill:#fff;}.b{fill:url(#a);}.c{fill:url(#b);}</style>
but it lacks the type="text/css" attribute which (although not required by the SVG spec) is necessary for some agents to correctly process the enclosed rules. I'd also put in some newlines and spaces for clarity, giving
<style id="style2" type="text/css">
  .a { fill:#fff; }
  .b { fill:url(#a); }
  .c { fill:url(#b); }
</style>
Try that, WP:BYPASS your cache, and let me know if it worked. --Redrose64 🌹 (talk) 14:30, 18 May 2017 (UTC)
@Redrose64: Thanks. It worked! TheBigJagielka (talk) 18:24, 21 May 2017 (UTC)

Black boxes in SVG[edit]

I've been trying to create some SVGs in order to make it easier to translate images. I've used the object to path function to convert the text into shapes, but this does not seem to be helping.

P.S. I found this previous discussion Wikipedia:SVG_Help/Archive_6#Black_boxes_in_wikimedia_PNG_render_but_not_in_SVG_original_file, which mentioned empty flowtext boxes? I've looked and not been able to find anything like that.

Thanks, Carl Fredrik talk 07:52, 12 June 2017 (UTC)

@CFCF: The thread that you link to misdescribes the problem ("flowtext" should have read "flowRoot" throughout), but looking at old versions of the image discussed there, it is the same problem that you are having. Your image contains the following structure:
<flowRoot
       xml:space="preserve"
       id="flowRoot4168"
       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
       transform="scale(0.26458333)"><flowRegion
         id="flowRegion4170"><rect
           id="rect4172"
           width="136.37059"
           height="58.588848"
           x="291.93408"
           y="22.463564" /></flowRegion><flowPara
         id="flowPara4174" /></flowRoot>
the black box is that <rect /> element, but you should remove the whole of the <flowRoot>...</flowRoot> element and everything that it contains.
Please note that at the top of this page, we have the section "Missing objects or black boxes", and at Commons, there is c:Help:SVG#Black rectangle (Flowed Text bug). --Redrose64 🌹 (talk) 10:05, 12 June 2017 (UTC)
Problème
Once uploaded on commons, black square appears. See this archive.
Cause 1
The element <flowRoot...></flowRoot> is not supported. It was proposed in a svg 1.2 draft documentation, but never became standard. Inkscape use it (but it's not valid).
How it happen
When you create a text-box by clicking and dragging the text tool in inkscape, you create a flowroot box.
Solution 2 (recommanded)
1. Open svg file in text editor
2. Use the following regex :
<flowRoot(.*\n)*?.*<\/flowRoot>
3. Delete all matches.

--Yug (talk) 15:36, 13 June 2017 (UTC)

  • @CFCF:. Please do not make images with the text converted to curves. It bloats the SVG file and makes subsequent translation difficult.
Translations should be simple text strings; they should have plenty of room because other languages may take up more space.
Choose a font that Wikimedia supports and include an appropriate fallback. See Commons:Help:SVG#Fonts / text.
Please get the attribution right. The original artist was User:jeremykemp; he put it in the public domain, but it is still appropriate to give attribution. User:Jado did nothing. All User:Jalo did was transfer the file to Commons.
It is not an own-work. It is sourced from Kemp.
Glrx (talk) 22:48, 13 June 2017 (UTC)
The only reason I converted them to curves was because of this persistant bug. As for Jalo, that is from the old file description — that it was inadequate is not my fault — even if I now will go ahead and change the description. Please try to be less adversarial, and if you find that there are errors in the attribution page, just fix them. :) Carl Fredrik talk 06:14, 14 June 2017 (UTC)
We (French wiki graphists) where doing the same, converting text to curve in order to avoid this black square / flowRoot bug.
Now, we delete the flowRoot part :D --Yug (talk) 12:07, 19 June 2017 (UTC)
The W3C validator checks SVG 1.1. It can be run by including {{Invalid SVG}} on the Commons file page and clicking the hyperlink. The validator complains about the flowRoot at line 73:
Commons:Commons SVG Checker should also find this error (and other problems). The code at Commons:MediaWiki:CommonsSvgChecker.js looks for flowRoot, but don't believe the result unless it prints the termination message "Check Finished!". The code may quietly throw an exception; check the F12 console log.
Glrx (talk) 15:15, 19 June 2017 (UTC)

Removing Minus (-) letter from a SVG image map[edit]

Hello, may I ask for your experience in resolving a problem I am having? A .svg country map contains the numbers 1 to 14. However, a certain number, the number 7, has a minus (-) displayed before it, (it shows like -7 on the map) which is not intended and has no purpose in that map and it must be removed.


File links:

Wikipedia

Commons


I could edit the .svg myself and remove that minus (-) symbol from number 7, however, I can't, because the minus symbol is not present when opening the .svg with an editor.

Lets say, when I am editing that .svg file with Incscape (an .svg editor - I have tried both online programs and desktop programs), but the minus (-) is not present in the .svg editor at all, not even next to number 7. However, when the .svg file is viewed through Wikipedia, the minus symbol is still there, next to number 7.

What is causing this visual glitch?

I do not know what else to do. I am at a loss, because this map is really beautiful, and yet, it is ruined by the minus symbol which was not meant to be there at all.

Any help is appreciated. --SILENTRESIDENT 18:05, 20 June 2017 (UTC)

In the SVG source code, remove the following block:
      <flowRoot
         style="font-style:normal;font-weight:normal;line-height:0.01%;font-family:'Bitstream Vera Sans';fill:#000000;fill-opacity:1;stroke:none"
         id="flowRoot9791"
         xml:space="preserve"><flowRegion
           id="flowRegion9793"><rect
             y="3013.1572"
             x="200"
             height="75"
             width="262.5"
             id="rect9795" /></flowRegion><flowPara
           id="flowPara9797"
           style="font-size:40px;line-height:1.25"> </flowPara></flowRoot>      <text
         id="text5962"
         y="625.65692"
         x="4556.25"
         style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';fill:#000000;fill-opacity:1;stroke:none"
         xml:space="preserve"><tspan
           y="625.65692"
           x="4556.25"
           id="tspan5964"
           sodipodi:role="line"
           style="font-size:40px;line-height:1.25"> </tspan></text>

It's the "rect" element in the middle of this block that gets rendered as a rectangle by the Wikimedia renderer (but remains invisible in Inkscape). Fut.Perf. 21:09, 20 June 2017 (UTC)

By the way, it happens to be the same technical issue as the "black boxes" problem treated in the thread immediately above. Fut.Perf. 21:13, 20 June 2017 (UTC)
Noted. You have my sincere thanks for your quick response and help. --SILENTRESIDENT 04:35, 21 June 2017 (UTC)