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 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". (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 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. bad letter-alignment on small font-size Tracked in Phabricator Task T36947 Open phab:T36947 Librsvg calculates the letter-distances inaccurantly for font-sizes of 20px and below. For a text like <svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg"> <text x="20" y="30" font-size="5px">exampletext</text> </svg> you can replace it with: <svg viewBox="0 0 1000 1000" xmlns="http://www.w3.org/2000/svg"> <text x="200" y="300" font-size="50px">exampletext</text> </svg> or with <svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg"> <g transform="scale(0.1)"><text x="200" y="300" font-size="50px">exampletext</text></g> </svg> 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. arc flags Tracked in Phabricator Task T217990 Open phab:T217990 If circle-segmentes are distorted it is often due to reduced spaces between arc-to-flags, see phab:T217990 for details. 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 your X-Y 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. It produces lean SVG code, avoiding the "extra stuff" that Inkscape inserts, and should save you time.

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

Click HOW TO for detailed explanation.

• Warming stripes (download v3.8) produces XML code for applications of Ed Hawkins' warming stripes graphics. User chooses vertical or horizontal stripes; normal or reverse data ordering; or from a variety of geometric shapes (updated 3 June 2021).

Click here to see examples of warming stripes embedded in different shapes.

• Warming stripes bar chart (download v1.0) Creates a 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. One dataset only (updated 31 August 2021).
• Line charts (download v2.2)— Accepts up to five datasets for LINE charts (example at right) (updated 12 June 2021).
• Vertical bar charts (column charts) (download v1.1)— Accepts up to six datasets for VERTICAL BAR CHARTS (COLUMN CHARTS)—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 (example at right) (updated 30 April 2021).
• Horizontal bar charts (download v1.0)— Accepts up to six datasets for HORIZONTAL BAR CHARTS—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 9 June 2021).
• Scatter plots (download v1.0)— Accepts up to five datasets for SCATTER PLOTS (updated 14 June 2021).
• Pie charts (download v1.0)— Accepts a series of up to 36 items for PIE CHARTS (updated 25 March 2021).

See examples in Category:SVG diagrams created with spreadsheet.

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

Style specifications, format, overrides, etc

Priority & overrides: I'm trying to use style specifications to avoid repetitively specifying attributes in rectangles, paths, etc in files like this. However, when I want to override the style in a specific instance, the style overrides the specific instance rather than the other way around. Example:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="1600" height="900" xmlns="http://www.w3.org/2000/svg">
<style>
rect { stroke:blue; stroke-width:4 fill:yellow; }
</style>
<rect x="100" y="100" width="200" height="100" fill="green"/>
</svg>

This code renders the fill as yellow. :-\

Format: I'm not sure if the format difference fill="green" versus fill:green; is involved (the x="100" format is needed for some attributes). That area is still mysterious to me.

Explanations or advice will be appreciated. Thanks in advance. —RCraig09 (talk) 17:50, 19 December 2021 (UTC)

@RCraig09: Attributes always have the syntactical form name="value". Some attributes, known as presentation attributes, may alternatively be specified by means of a declaration, which may be part of a declaration-list. Declarations always have the syntactical form name:value, and a declaration-list may be given either as the value of a style="..." attribute, or by means of style sheets, as in your example. When both methods are used, and there is a conflict, the behaviour is undefined and may vary between user agents. You should be consistent within the document and stick to one form or the other. You should note that your example lacks a mandatory semicolon after the stroke-width:4. One thing that you can try is a style sheet with two rules, one more specific than the other:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="1600" height="900" xmlns="http://www.w3.org/2000/svg">
  <style>
    rect { stroke:blue; stroke-width:4; fill:yellow; }
    rect#greenrect { fill:green; }
  </style>
  <rect id="greenrect" x="100" y="100" width="200" height="100" />
</svg>

--Redrose64 🌹 (talk) 22:38, 19 December 2021 (UTC)

Many thanks, User:Redrose64. I would never have arrived at this structure looking at internet forums etc. I'll try your suggested approach. —RCraig09 (talk) 23:01, 19 December 2021 (UTC)

Additionally RCraig09 I'm not sure if there's something wrong with you client, but it renders fine for me... — Berrely • ^Talk∕_Contribs 13:05, 20 December 2021 (UTC)

The SVG diagram on Commons

@Berrely: Thank you for your help. I think this may be what Redrose64 meant when saying "behaviour is undefined and may vary between user agents".

Everyone: I've updated the SVG file to have Style Sheets for rect and path elements (but not for text elements since there were so many variations of font-size, italics, bold, and color). In running through various SVG checkers, I've found:

* W3.org checker gave 46 warmings and 46 errors revolving around the fact that the new version has many duplicate ID Values of identifiers (R for red, G for green, etc etc)

* Toolforge.org said "No issues found."

* Commons SVG checker said "Successfully parsed XML structure. Check finished!" but ONLY after it advised a workaround to revise the style specification to be <style type="text/css">

Given the uncertainty, I didn't want to risk uploading the new "style"-ized version to Commons, but could any of you tell me if the new version at this Dropbox link has any rendering issues compared to the "correct" 18 December Version 1 at Commons, at right? (Be aware that for the new version I purposely reduced the outline around "Global warming, climate change" and fixed the arrowheads a bit; ignore those changes; they're intended.) If the new version doesn't have issues, I'll upload to Commons as Version 2. Thanks for any feedback you give. —RCraig09 (talk) 05:52, 21 December 2021 (UTC)

Thanks for your contribution, RCraig09. May I make an unrelated comment about text readability? The green and blue text has rather low contrast. Is it possible to make them darker? Wikipedia:Manual_of_Style/Accessibility#Color has guidelines. Thanks, cmɢʟee⎆τaʟκ 10:43, 21 December 2021 (UTC)

— Hello again, @Cmglee: The original chart was the result of long collaborations on Talk:Climate change. Any discussion re color was to move away from primary colors toward more subdued colors, which (upon reading your suggestion) may translate to less contrast. I'll do some experimenting, though.

— Separately, did you happen to notice any discrepancies or issues in the Version 2 from Dropbox? —RCraig09 (talk) 15:06, 21 December 2021 (UTC)

Please do not send us off to external sites that require registration, such as Dropbox or Imgur. If you wish to provide a screenshot, approved methods exist. --Redrose64 🌹 (talk) 19:52, 21 December 2021 (UTC)

Apologies; I think the Dropbox link lets people download without registration. In any event, I have uploaded Version 2 (made with internal Style Sheet for path and rect elements) to Commons. My request now would be whether anyone sees rendering issues on Version 2, or whether there is truly any problem with the duplicate ID values that w3.org found objectionable. —RCraig09 (talk) 20:38, 21 December 2021 (UTC)

I didn't intend my example above to be read that id= was the only method available. No element may have the same id as any other element, this is just as true in SVG as it is in XML or HTML. I had assumed that you would only want one green rectangle, all the others being yellow; if I knew that you wanted there to be more than one, I would have written my example thus:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="1600" height="900" xmlns="http://www.w3.org/2000/svg">
  <style type="text/css">
    rect { stroke:blue; stroke-width:4; fill:yellow; }
    rect.greenrect { fill:green; }
  </style>
  <rect class="greenrect" x="100" y="100" width="200" height="100" />
</svg>

As for type="text/css", this is mentioned at c:librsvg bugs#List of open Phab SVG bugs and c:COM:Commons SVG Checker/KnownBugs, both pages being linked from #Further issues above. --Redrose64 🌹 (talk) 21:55, 21 December 2021 (UTC)

Thanks again, User:Redrose64, for your concise explanations. I sense that victory is in sight! —RCraig09 (talk) 23:15, 21 December 2021 (UTC)

Resolved

SVG not rendering properly by Wikimedia.

Moved from c:Commons:Graphic_Lab/Illustration_workshop#SVG_not_rendering_properly_by_Wikimedia.

Hello world for C# for French pages

Request

My SVG not rendering properly when exported to PNG by Wikimedia, some idea ? --Sylv1 Durif (talk) 22:27, 24 December 2021 (UTC)

@Sylv1 Durif, is it possible for you to use a syntax highlighted block like this instead of an SVG?

using System;

// Exemple avec le programme Hello World
namespace HelloWorld
{
   class Program
   {
      static void Main(string[] args)
      {
         Console.WriteLine("Hello World!");
      }
   }
}

Floogan (talk) 06:44, 25 December 2021 (UTC)

I think that part of the problem is the declaration font: bold 3px / 1.25 Courier, monospace which may be too complicated - try splitting this down into component properties, such as font-weight: bold; font-size: 3px; line-height: 1.25; font-family: Courier, monospace;. But the main problem that I see is that Courier is not a supported font; per c:Help:SVG#fallback, try Liberation Mono instead, which must be quoted because it contains a space - font-family: 'Liberation Mono', monospace; --Redrose64 🌹 (talk) 17:42, 25 December 2021 (UTC)

@Floogan: I note there are some <tspan recitations that aren't cleanly matched with </tspan> recitations, and the transform="matrix(. . . "> recitation adds needless complexity. If you want me to do an SVG from scratch (not a big project), let me know. —RCraig09 (talk) 18:05, 25 December 2021 (UTC)

@RCraig09: Feel free to fix/remake the SVG if that makes sense -- I was just checking first whether an SVG is necessary since WikiText syntax highlighting is already designed for this (e.g., here). I'm very new to the Wikiverse, so I'll defer to your judgement! -- Floogan (talk) 20:09, 25 December 2021 (UTC)

Alrighty then! I'll do an SVG. —RCraig09 (talk) 20:34, 25 December 2021 (UTC)

I just finished my upgrade, but it looks like User:Glrx on Commons did an update shortly ago without informing here. My version uses proper fonts (see Redrose64's comments above), and is simpler and clearer in formatting for humans to read, so I'll upload it as Version 3. The most appropriate one can be used. Are you sure you wanted to say "Hello world" and not "Bonjour monde"? —RCraig09 (talk) 22:06, 25 December 2021 (UTC)

@Sylv1 Durif: Please reply so we know whether to close this topic. Do you intend this image to be used in an encyclopedia article? —RCraig09 (talk) 20:07, 27 December 2021 (UTC)

Hello World in French has no sense, the English version is more known, that why I keep the English version… I traduce only the comment… For the code block, I can't, it's for a title and need to be as an image. Also we can close the topic, thanks to Floogan, Redrose64 and big up to RCraig09 to finish this SVG ❤ ! I will change the image on the C-sharp page now! --Sylv1 Durif (talk) 13:37, 31 December 2021 (UTC)

 Done

Resolved

 – —RCraig09 (talk) 05:52, 2 January 2022 (UTC)

Monmouth Coffee Company logo

I am trying to add an svg logo to the infobox in the article I have written on Monmouth Coffee Company using Wikipedia:File Upload Wizard. It is text only so it should be public domain, but possibly not suitable for Commons. I have had the following error messages, which I don't understand, any ideas what I am doing wrong? When linking to a downloaded copy on my computer

Upload failed: elements can only link (href) to data: (embedded file), http:// or https://, or fragment (#, same-document) targets. For other elements, such as , only data: and fragment are allowed. Try embedding images when exporting your SVG. Found "<image http://www.w3.org/1999/xlink:href="254193f5893e51a7.jpg">". (uploaded-href-attribute-svg, image, http://www.w3.org/1999/xlink:href, 254193f5893e51a7.jpg)

When linking to copy on MCC website https://www.monmouthcoffee.co.uk/wp-content/themes/monmouth/library/images/logo.svg

<a> elements can only link (href) to data: (embedded file), http:// or https://, or fragment (#, same-document) targets. For other elements, such as <image>, only data: and fragment are allowed. Try embedding images when exporting your SVG. Found <image http://www.w3.org/1999/xlink:href="254193f5893e51a7.jpg">. TSventon (talk) 11:12, 27 December 2021 (UTC)

TSventon it seems that your SVG contains a raster graphic that's linked, not embedded. Wikimedia does not allow requesting images from external sites (for obvious reasons). It seems the SVG you're trying to upload is a "fake" SVG; simply a raster graphic in a SVG wrapper. — Berrely • ^Talk∕_Contribs 13:05, 27 December 2021 (UTC)

Berrely, thank you for the explanation, what can I do about it? This is my first attempt to upload an image and I have no technical knowledge about image formats. TSventon (talk) 13:14, 27 December 2021 (UTC)

I have now snipped a png copy of the logo and successfully uploaded it as file:Monmouth_Coffee_Company_logo.png. TSventon (talk) 14:02, 27 December 2021 (UTC)

@TSventon: Following my teahouse comment, the solution is as simple as deleting the part of the SVG from the line <g id="Layer_1" display="none"> to its closing </g>. That's where there's a call to an external .jpg which isn't needed and gives the error. You may be just as well off with the .png, however. Mike Turnbull (talk) 16:14, 27 December 2021 (UTC)

I went ahead and uploaded the version without the image reference File:Monmouth Coffee Company logo.svg. Auguel (talk) 16:16, 27 December 2021 (UTC)

Thank you Michael D. Turnbull, Auguel, I have previously given other editors a link to the instructions for uploading a logo, so it is good to have had a chance to upload one myself, even if it was quickly replaced with a better version. TSventon (talk) 16:32, 27 December 2021 (UTC)

Wikipedia:Village pump (technical) discussion on SVG maps

Looking for additional knowledgeable people in this SVG discussion:

• Wikipedia:Village pump (technical)#"Our World in Data" logo overlapping dates in SVG maps, but not PNG maps

I see one person, Redrose64, posting here and there. Need more people there at the Village Pump. --Timeshifter (talk) 03:12, 31 December 2021 (UTC)

Distortion effect with circle shapes

Hello. I recently became more familiar with using a text editor for more simple images, with inkscape being my previous main tool of choice. I still use inkscape to inspect my images after encoding them in text script, and have noticed a problem with my circles. When rotating a "perfect" circle it should always stay in the same measurements, for example a circle set to 500px should always be 500px no matter the degree of rotation. However when a circle is set as a stroke, it becomes distorted when rotated. This peculiarity can be observed with this file. The red circle is set as a stroke of the yellow one, instead of placing two path circles one over the other. When rotating the image in inkscape, the red circle that should remain at 500px instead distorts to other measurements such as 499.922px and 500.017px. This is only happening to circles set as strokes, the path circles behave as expected. I am observing this in other files as well. Is this just a peculiarity of text encoding? Placing two circles set as paths would solve the issue and I have no objection to using it, but some other users might find it objectionable because it would increase the code in a way they see as unnecessary. Is there any other solution? Fry1989 ^eh? 16:25, 13 January 2022 (UTC)

@Fry1989: I've experienced similar micro-distortions using Inkscape, though they never made a difference big enough to be noticeable in my projects. I hypothesize the micro-distortions may be Inkscape's rounding errors in complex calculations like trigonometry. If accuracy and precision are that important, I use a text editor to correct. —RCraig09 (talk) 17:19, 13 January 2022 (UTC)

The level of importance depends on the user. I am guilty as charged being a perfectionist, so it matters to me. Since it doesn't affect paths, as I stated I am perfectly fine using only paths. In fact, that was my standard way of going about it for the longest time. I just didn't know if it was my fault or a fault of text editing or something else. Thank you. Fry1989 ^eh? 18:51, 13 January 2022 (UTC)

@Fry1989: You appear to be mixing up two different concepts. path is an element of SVG (as is circle); stroke is an attribute that may be used on several SVG elements, including path and circle. Here are the relevant documentation pages:

• The 'path' element
• The 'circle' element
• The 'stroke' property

Attributes and properties are different ways of specifying the same information. This element

<circle cx="251" cy="251" r="212.5" fill="#ffd700" stroke="#d40000" stroke-width="75"/>

uses attributes, and may alternatively be specified as

<circle cx="251" cy="251" r="212.5" style="fill:#ffd700; stroke:#d40000; stroke-width:75;"/>

which does exactly the same thing using properties instead of attributes. Which you choose is largely personal preference. --Redrose64 🌹 (talk) 19:09, 13 January 2022 (UTC)

Thank you for the further assistance. I'll have to play around and see how it goes. I am still learning. Fry1989 ^eh? 19:41, 13 January 2022 (UTC)

@Fry1989: As a comparison, here's the same circle drawn using a path element, first using attributes then using properties:

<path d="M 38.5,251 
  a 212.5,212.5 0 0,1 425,0
  a 212.5,212.5 0 0,1 -425,0
  z" fill="#ffd700" stroke="#d40000" stroke-width="75" />
<path d="M 38.5,251 
  a 212.5,212.5 0 0,1 425,0
  a 212.5,212.5 0 0,1 -425,0
  z" style="fill:#ffd700; stroke:#d40000; stroke-width:75;" />

Each one is drawn as two semicircles, because I don't think that it's possible to use a single path command draw a non-point shape where the start and end points are coincident. The newlines are optional - I put them in to help distinguish the four path commands.

@Fry1989: Not sure if this is the effect you're seeing, but some renderers appproximate circles with cubic Bézier curves. The error is under 0.1%, though. Another possible effect is the anti-aliasing. I've found that if the same shape is drawn multiple times (on top of one another), the boundary starts looking ugly (e.g. in File:SVG_highlight_on_hover_template.svg, shapes are drawn multiple times to achieve the hover effecct). Cheers, cmɢʟee⎆τaʟκ 00:45, 15 January 2022 (UTC)

Your example appears to be a slightly different issue. That file appears to have the exact same shapes drawn on top of themselves. My issue with File:Romanian traffic sign - II-02 Circulatia din ambele sensuri interzisa 1950+1957.svg (and similar images) is choosing between drawing a solid red circle and then a smaller solid yellow circle on top of the red one, or drawing a solid yellow circle and using a stroke to create the outer red circle. I am alright using the first method, although some other users won't like it because it does come with a larger file code than the second method. I also tried the code provided above, and in that case both the red circle and yellow one become distorted when rotated, so using <circle> instead of <path> appears to be the only way to avoid the problem. Fry1989 ^eh? 17:00, 15 January 2022 (UTC)