This is an archive of past discussions on Wikipedia:SVG help. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.
Can someone take a look at File:Post Luxembourg logo.svg? I was able to get the multiply blending working on wikipedia, but for some reason it introduced some weird artifacts in the rendering. You can see the artifacts in the upper left corner (around the edge of the orange circle) here. Auguel (talk) 06:13, 31 October 2021 (UTC)
I guess the SVG validation is run by a bot, and the validation was run on an old file. Anyway I checked my new file with an external validator and it showed some errors but they were all related to stop elements missing the offset parameter. I uploaded a new file which corrects this issue (and checked it with an external validator to confirm). But the rendering issue is still present. Auguel (talk) 22:16, 31 October 2021 (UTC)
Firstly, backgroundImage is deprecated. However, there is no good alternative as the link explains. I've thus added a workaround for Firefox. As for the immediate issue, it seems RSVG supports backgroundImage but has trouble antialiasing semitransparent pixels (alpha < 255). I thus initially made the background white so that the bug goes away. To retain the transparent background, I used a filter (filter_mask) to make the entire logo white, and set it as a mask. Applying it to the white-background-plus-logo group cuts out just the logo. Can someone please raise a bug report about the trouble antialiasing semitransparent pixels? Let me know if there are more issues, cmɢʟee⎆τaʟκ03:07, 1 November 2021 (UTC)
@Cmglee: Thanks. Definitely a lot to consider there. Unfortunately it doesn't seem your workaround is quite perfect. You have lost the gradient fill of the previous images. Also I don't think tweaking the colors was necessary as the initial svg was taken straight from the source (https://cdn.post.lu/postlu/babel-theme/assets/images/logo-post.svg), the only problem is that it doesn't render correctly on wikipedia. Auguel (talk) 04:01, 1 November 2021 (UTC)
Since Firefox and Chrome support style="mix-blend-mode:multiply", the for_browser group retains this method. To avoid badly rendered SVG appearing in the thumbnail, it is initially invisible, but the set command reveals it in browsers, but not Rsvg, which doesn't support SMIL. Rsvg meanwhile supports BackgroundImage in filters, which the for_rsvg group uses. To avoid badly rendered SVG appearing in Chrome, set hides it.
As in my last message, the logo is placed on a white background to work around the semitransparent-pixel-artifact bug. I then created a mask from a completely white version of the logo to mask the background off.
Demonstration of antialiasing pixel artifacts on elements with a filter using BackgroundImage. On the left half, artifacts appear at boundaries with the transparent background. On the right half, the background is white, and the artifacts are absent.
....except for different colors for different states. I would like to see a map where most of the states are green (#A9FAAD), but all of the following states are yellow (#FFE4E4) - Alabama, Florida, Georgia, Michigan, Mississippi, North Carolina, South Carolina, West Virginia, Wisconsin, Wyoming.
Dark at 200pxBetter at 360px (left faces still black)
Hi SVG experts,
Though the grid in my diagram is white, it is rendered as black at thumbnail sizes under 324px. Would anyone know how to fix the problem for small thumbnails?
Note: I worked around the bug by drawing redundant rectangles to make the smallest pattern every 5 cubelets (instead of every 1 cubelet) so that each pattern cell is bigger than 1 px. cmɢʟee⎆τaʟκ03:42, 23 January 2022 (UTC)
I managed to workaround this problem, see File:Brøndby IF.svg. I still just want to know why it renders so weirdly. When I press "Edit SVG" using c:User:Rillke/SVGedit.js the browser rendering is exactly as it should but the RSVG rendering isn't. Opening the file in Inkscape also just makes it all black. Any clues why?Jonteemil (talk) 03:51, 19 November 2021 (UTC)
@Jonteemil: I've fixed the SVG by renaming CSS class names starting with underscores to "blue" and "yellow". 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...". Is the thumbnail fine now? cmɢʟee⎆τaʟκ00:19, 22 November 2021 (UTC)
Can someone take a look at this file File:Youth Law Australia logo.svg, I can not get it to render on wikipedia, but it renders everywhere else. Even on the Commons SVG Checker. And even in the file history of the same file, but only when the file is not the current version. I really don't understand the wikipedia rendering engine. Auguel (talk) 21:16, 29 November 2021 (UTC)
Hello, I hope this is the right place. I made and uploaded a vectorial file and it doesn't render the text properly. I transformed the text into "path" as it should. Instead of showing the black text in bold letters, it looks simple and less scattered as it should be. The correct version is only visible when you click to see it at the real resolution. Does anyone know how it can be solved?--Kun Kipcsak (talk) 16:48, 1 December 2021 (UTC)
Artifacts when using feSpecularLighting and feDistantLight
Note black pixels around shapes
Hi SVG experts,
I just created this image using an SVG filter to simulate 3D tiles. Strangely, the shapes are surrounded by black pixels. Anyone seen this or know a fix?
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.
@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:
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)
* 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)
— 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.
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:
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)
<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∕Contribs13: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)
@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)
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:
@Sylv1 Durif, is it possible for you to use a syntax highlighted block like this instead of an SVG?
usingSystem;// Exemple avec le programme Hello WorldnamespaceHelloWorld{classProgram{staticvoidMain(string[]args){Console.WriteLine("Hello World!");}}}
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)
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)
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)
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? Fry1989eh?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. Fry1989eh?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:
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)
@Fry1989: As a comparison, here's the same circle drawn using a path element, first using attributes then using properties:
<pathd="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"/><pathd="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.
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. Fry1989eh?17:00, 15 January 2022 (UTC)
For some reason, a bunch of objects are not showing up. I can't figure out why some show up and some don't. If you open the original file, it looks fine. I've reuploaded the file a couple of times with slight modifications thinking it would do something, but it didn't.
I am, here, sincerely requesting you for creation of an svg map of India and Norway's location. Perhaps it might be that a file used to exist, but got deleted, or i fail to get the right svg file name. Utkarsh555 (talk) 16:55, 12 February 2022 (UTC)
I've gone ahead and reuploaded it with outlines but I'm still interested in the cause. I do remember being some rendering issues with tspans. — Berrely • Talk∕Contribs20:27, 25 February 2022 (UTC)
ERROR in <tspan> with id=tspan3766: Text element found with list of coordinates. It will not be rendered properly by Wikimedia's SVG renderer. See https://phabricator.wikimedia.org/T35245 for details.
”
The list of coordinates lets Inkscape position each character individually, but the thumbnail renderer Rsvg doesn't support it. Instead, provide just a single coordinate for each tspan and let the engine kern it to its liking. Hope that helps, cmɢʟee⎆τaʟκ23:24, 25 February 2022 (UTC)
The hatching for the red and green squares in the figure 3 in this thumbnail look strange, even though I'm doing the same thing as with other figures. Commons SVG Checker doesn't find any issues.
Would someone be able to explain why it is so, please?
@Cmglee: I added two times stroke-dasharray="none", which solved the problem. This bug is unknown to me. I could neither reproduce it locally with c-librsvg2.40.21 nor with rust-librsvg2.52.6 — JohannesKalliauer - contrib.02:57, 14 March 2022 (UTC)
Thank you very much, @JoKalliauer:. It seems the stroke-dasharray leaked from the element being filled into the pattern, unlike other attributes such as stroke, and unlike in other renderers.
Hi there. I'm having some trouble with an SVG file of New Jersey's flag in the Eurovision heart logo. The coat of arms is completely covered in black in the PNG preview, but when I click on it to see the SVG file, it appears fine.
The program I used to create this SVG image was Inkscape. Could someone be able to help me figure out what's wrong? Thanks.
How can I see that an SVG image update has been changed?
Good morning,
I wanted to ask if it is possible to know what has been changed from an SVG update, either on Wikipedia or by programs like Notepad++. Thank you! --KajenCAT (talk) 12:08, 26 March 2022 (UTC)
Thank you, @JoKalliauer:! Now I see the diff. I'm updating the Catalan version of File:2022 Russian invasion of Ukraine.svg and and I have already translated and transcribed most of the image (legend, toponyms, ...) to Catalan. I want to do it every few days to keep it updated, but I have to do it all over again from zero. Although I have almost automated this process, I was wondering if it would be possible to simply copy the new changes from the old file to the new file and overwrite them to my translated file, just to speed up the process.
Although this plugin is very useful (and it can help me in small changes), I don't see how I can do this. I searched it on internet, but I didn't understand it very well, as my knowledge in this field is very basic. KajenCAT (talk) 13:35, 26 March 2022 (UTC)
An alternative method without installing any additional software is to use Rillke's SVGedit: after adding
if(mw.config.get('wgNamespaceNumber')===6&&/SVG/i.test(mw.config.get('wgTitle').slice(-3)))// SVGedit on SVG files onlyimportScript('User:Rillke/SVGedit.js');
Hi @Cmglee:, thank you very much! However, I don't see how I could copy the change of this diff to my version language. In other words, how can I overwrite the modifications in another file without modifying what has not been touched? Regards, KajenCAT (talk) 15:55, 31 March 2022 (UTC)
I'm having trouble with rendering this file when using it on a wikipedia page, I'm not sure whether its to do with resolution or if I'm dealing with a corrupt file. In lower scaling all you see is an empty space, but if you select higher scaling, all the shapes in the svg file appear.
@JoKalliauer: You don't need to pull the resolution way down to 43 x 11, because 431 x 110 = 47,410 which is less than half of the maximum permitted 100,000 pixels. --Redrose64 🌹 (talk) 17:26, 19 June 2022 (UTC)
@Redrose64 That's true, but the guideline imho does not directly cover SVG and the actual reason was not the reduction of the preview-size, but the reduction of the numeric precision (less digits in the SVG) — JohannesKalliauer - contrib.19:21, 19 June 2022 (UTC)
Number of bytes in the SVG shouldn't be an issue when you're in the 3-4 KB area - WP:DWAP. It gets converted to a PNG for rendering, in any case, which may well be larger. But it is known that our librsvg utility isn't so good when the <svg> tag specifies small values for the width= and height= attributes. I think that this is because it tries to draw a PNG using integer conversions of the various coordinates, and then upscales it with consequent pixellation. --Redrose64 🌹 (talk) 19:46, 19 June 2022 (UTC)
Preview-resolution: If a viewBox is in the SVG the width&height get ignored if rendered in a given resolution, than the native one. However phab:T35245 does not like small viewBox (or small width&height without viewBox).
Though the link is dead as of now, I have the original file downloaded before the link was deleted. I haven't had a problem uploading NFC images for minimal use on pages before so I'm very much new to this. On the page it was supposed to be on, I have also uploaded two other SVG files and they have displayed as normal. NHPluto (talk) 21:48, 19 June 2022 (UTC)
I'm trying to make an election map for the 1857 WI governor race. There was no map on Commons with the correct county borders for that year, so I downloaded this file and changed a few lines to make the borders right. But when I uploaded the file, the borders I changed didn't render. It looks like the shapes render fine, but there are no borders. BJenkins42 (talk) 02:27, 5 August 2022 (UTC)
Help! I've created a SVG diagram of a circuit diagram in Python using SchemDraw, File:IEC-61000-4-5_Simplified_Circuit_Diagram_of_the_Combination_Wave_Generator.svg. Unfortunately, due to either a compatibility problem or a librsvg bug, the schematic is not rendered correctly. When rendered, the capacitor C_c disappears entirely. More frustratingly, this rendering problem doesn't affect most resolutions but only affects the full-size, 2,560×843 resolution - which is usually the default size in many places.
I've already tried to convert strokes and objects to path, but it still doesn't solve the problem. Could any SVG gurus please help taking a look and suggesting a possible workaround?
Thanks for the tip. This definitely looks like a caching problem, I greatly underestimated the trickiness of caching. I just opened the same page via Tor Browser and found it shows up correctly. But I'm so far still unable to make it show up locally in either my web browser (cache disabled) or via wget in the command line, so it's possibly CDN cache related. I'll keep trying to purge the cache using the advanced options. Failing that, I'll just reload it with a different name... Bieraaa (talk) 11:50, 28 August 2022 (UTC)
Incorrect rendering of SVG circles using "stroke-dasharray" attribute (vs. "Arc" specification)
20221002 SVG Pie chart creation using circle stroke-dasharray attribute
This image uses the stroke-dasharray attribute on a circle to form "wedges" for use in pie charts. This "test image" renders perfectly when directly read by my Chrome, Firefox, and Safari, and no checker reported any SVG structural errors
(w3.org,
Commons SVG checker, and
toolforge svg check).
The file renders correctly when I click on the main image on the file description page and the image fills the screen, but renders incorrectly on the Wikimedia file description page itself, on the Toolforge checker, and on en.Wikipedia. The two "25%" wedges in the left graphic should abut perfectly without a gap and without the left edges "tilting", and the right graphic's wedge shows an anomaly at the vertex. In all cases, there appears to be a "ghost" wedge that is slightly rotated from each original wedge.
Does anyone know what the problem is?
(FYI: A background explanation is provided in the sources linked on the file page, and a copy of the SVG code is embedded in image itself.)
@RCraig09: That's an ingenious way of drawing circular sectors. The bug seems to be a combination of anti-aliasing and rounding error. Though the length of the dash is specified to many decimal places (157.0796326794897), rsvg doesn't exactly render it to that length, so the edge isn't exactly rectilinear. Perhaps the conventional way is still preferable:
<path d="M 0,0 H 200 A 200,200 0 0 0 0,-200" fill="black" stroke="none"/>
@Cmglee: Thanks for investigating. That's what I was afraid of. :-\ I'm not as familiar with the Arc function, and I was planning on making a generalized spreadsheet that automatically generates SVG code for pie charts. It will be a challenge to generalize wedges from 1 through 359 degrees! —RCraig09 (talk)23:09, 3 October 2022 (UTC)
In case anyone is interested, below is code for making a pie chart using SVG's Arc function. Each wedge starts out as a vertical line leading up from the origin, and traverses an arc clockwise per pie chart standards. Arcs are then rotated to be "stacked" in succession around the circle. The large arc flag is 1 only if a particular arc is >180 degrees. The destination coordinates are sin θ,–cos θ. The following code would be placed inside a group <g transform="translate(x,y)"> to locate it appropriately.
Test of formula to draw sectors of a pie chart, given radius, begin angle (rows) and end angle (columns)
Hi RCraig09, My pleasure, and you beat me to it! Your formula is correct. The hardest part is deciding on the large-arc flag. My SVG is drawn by a Python script embedded in it. My assumptions are that angles are increasing anti-clockwise from the right (x-axis) and the entire circle is drawn if the beginning and ending angles are the same (strictly, I reduce the ending angles by a tiny amount so that the path still works).
Good luck with your pie-chart application, though if I may comment, humans are pretty poor at estimating angles except whether it is just above, equal to or below 180°: a percentage bar is easier to interpret correctly.
I see that you use the mathematical approach to coordinate systems, moving counter-clockwise from an axis pointing to the right. My motivation was to make pie charts, which move clockwise from an axis pointing up.
I've updated these files using the Arc specification (previously I used a self-designed Path approach that was so inflexible that I was motivated to try the stroke-dasharray approach which isn't suitable for Wikimedia!). —RCraig09 (talk)22:00, 6 October 2022 (UTC)
This question is more about the Commons file page commons:File:Roving_bridge.svg than SVG code per se, but I'm unsure where to ask.
In the description on Android Chrome both on mobile and desktop views, there is a vertical gap between points 3 and 4. If I remove point 4, the gap appears between points 2 and 3. Would anyone know what is causing it and a fix?
Does anyone know how EclecticArkie creates his graphs?
Does anyone possibly know how: EclecticArkie makes the history of seasons SVG graph for football clubs? I've asked him but it appears he hasn't taken anyone's requests since 2020. I'd quite like to create one myself for: Bath City F.C. However, I have no experience with creating such graphs, But I'd love to learn! If anyone is experienced in this field, I'd appreciate the help or just someone to point me in the right direction. Thank you all so much. Joseph1891 (talk) 16:41, 2 November 2022 (UTC)
@Joseph1891: Have you tried asking EclecticArkie (talk·contribs) directly? They don't edit every day, it is true; but have made edits as recently as yesterday, so are still around. Also, you don't give an example of what a history of seasons SVG graph for football clubs might be. --Redrose64 🌹 (talk) 22:34, 2 November 2022 (UTC)
The clean SVG code with comment <!-- years are 10px wide, positions are 4px high in svg --> and repetitive path commands seem to imply generation with a custom program. It's not too difficult to replicate it with a Python script, given the source data. However, if EclecticArkie is willing to share his or her program and data, that seems the best approach.
PS: This bug is new to me, or at least it is not reported at phab:tag/wikimedia-svg-rendering. I don’t think that adding another librsvg-bug noticiable increases the priority of updating the server. Therefore I currently don’t see much sence of reporting it there, because it is an upstream-Bug (i.e. librsvg-bug), that is anyhow fixed in the current rust-librsvg-version. — JohannesKalliauer - contrib.04:51, 9 January 2023 (UTC)
@JoKalliauer: and @Redrose64: thank you very much for debugging and working around the bug. Amazing how we're still uncovering new bugs. Any idea when rust-librsvg-version will be used throughout Wikimedia? Cheers, cmɢʟee⎆τaʟκ09:14, 9 January 2023 (UTC)
I haven't looked at either file, but is there a chance they have different encodings (UTF-8 with/without BOM, UCS-2 big/little endian, UNIX/Win/old Mac newlines etc)? cmɢʟee⎆τaʟκ19:00, 19 January 2023 (UTC)
@Cmglee: I downloaded svg-file (with “save target as”) and it is “UTF-8 without BOM” and uses “Unix (LF)” Lineforward, so it should be perfect.
Be aware opening svg-files in Firefox and saving the opened SVG might change the context of the file.
I believe it is an old bug. Previously, MediaWiki required an XML prolog or the SVG file would be served as text/plain. The given file was uploaded in 2016, and MediaWiki probably classified the MIME type then.
In the past, I fixed several such files by adding the XML prolog. Today, it may only need a one-character change to upload and get reclassified.
I'm not sure that is the issue. If I query the API, the MIME is correct.
@Sarang: The validator does an HTTP request to MediaWiki to get the file. If MediaWiki responds with the header CONTENT-TYPE: image/svg+xml, then the validator processes the file as SVG. If MediaWiki responds with the header CONTENT-TYPE: text/plain, then the validator does not know what to do with the file (i.e., the validator must get an appropriate MIME type before it examines the file). Glrx (talk) 20:18, 20 January 2023 (UTC)
2010-2070-2100 Climate change threatens venues of Olympic Winter Games
Underscoring of text renders properly if read directly into both Chrome and Firefox. However, on Wikimedia and en.Wikipedia the underscoring does not appear.
I copied another tag from the SVG file to show what other attributes may affect that text. One thing that I notice is that there is no explicit stroke setting, so try adding stroke="none" after the fill="black". --Redrose64 🌹 (talk) 19:10, 5 February 2023 (UTC)
Thanks, @Redrose64: I tried designating stroke="no"strike="none" for Version 3, which was not successful. To avoid the problem, I just moved the text to where underscore isn't needed, in Version 4. Problem not solved, but avoided! A real head-scratcher. — 21:31, 5 February 2023 (UTC) . . . strikethrough added —RCraig09 (talk)22:47, 5 February 2023 (UTC)
stroke="no" is not a valid attribute/value pair. Valid values for the stroke= attribute are exactly the same as documented for the stroke: property, and values that are not explicitly described are not handled by agents consistently. That is to say, some agents might treat a value of no in a similar manner to a value of none, but others might not - and do not need to. --Redrose64 🌹 (talk) 21:40, 5 February 2023 (UTC)
I'm posting a "resolved" template here because this particular problem is avoided. It would be a matter of interest if someone would actually solve the problem for future use. —RCraig09 (talk)00:05, 6 February 2023 (UTC)
I don't understand the reason, but if I put all attributes within the specific <text > specification and do not rely on inheriting group <g > attributes, the underscoring renders properly on Wikimedia and en.Wikipedia. Specifically, the following works:
Ah, a good idea to try... but I just tried it at File: Test.svg(see version 16:54, 7 February 2023) with odd results on Commons or en.WP. Using tspan doesn't help. Odd, but at least there's a workaround. —RCraig09 (talk)17:04, 7 February 2023 (UTC)
Wikimedia/en.Wikipedia do not correctly render the gradient inside a rectangle in "Version 7" (uploaded 04:40, 10 February 2023); it shows up as a solid color, not a gradient. The gradient does render correctly in Chrome directly. The relevant code is:
@JoKalliauer: Thanks once again for your knowledge and strategy. Vielen Dank! Your enhancement of the gradient definition was above my head as Mozilla.org only gives simpler examples. I paste your code here for future reference:
I loaded File:Gear pump exploded-ru.svg into the SVG Translate Tool, copied the Russian text over as "русский", downloaded the SVG file, replaced the text strings without systemLanguage="ru" with English equivalents, tweaked some paths, and uploaded the file as above.
Its Commons file description page doesn't seem to recognise that it has Russian in it: there is no "Render this image in <LANGUAGE> [Go]" beneath "Open in Media Viewer". What did I miss?
Can a multilingual SVG specify that an element not be drawn for a particular language? In this case, I want the leader lines connecting the text labels with the features to appear for all languages except for one denoting "unannotated". I could
Use SVG symbols to draw them for each language except this one, or
Draw a white line over the unwanted elements, [how do I unindent this line without starting a new ordered list item?] but being able to not draw them for one case seems more elegant.
Though the SVG Translate Tool recognises that it has two languages, it doesn't show a field for the second line of "Bushings", which needs only one line in English (and thus I set to a nonbreaking space), but two in Russian. How do I make the tool let the user edit it, yet not show anything in the default render?
at the beginning, because MediaWiki only needs to know which languages are available (due to performance there is a treshold, therfore there exist no bug-report), but the actual text can be at the end. (librsvg reads the whole image) — JohannesKalliauer - contrib.17:48, 6 March 2023 (UTC)
We could report it on phab:, but since it is an upstream-bug no one cares at Wikimedia, so I consider reporting as waste of time&energy. Upstream at rust-librsvg it is not a bug any more, since it is resolved anyhow, so you “can’t” report it on https://gitlab.gnome.org/GNOME/librsvg/-/issues .
Do the characters exist in the DejaVu Sans font as installed on the Wikimedia servers used by librsvg at Commons? --Redrose64 🌹 (talk) 19:24, 24 March 2023 (UTC)
@Nirts: Please add at least one category to this file. If you don’t have the time adding a category (that’s the uploaders duty), then I don’t have the time helping you. If you need help adding a category feel free to ask. — JohannesKalliauer - contrib.14:43, 7 April 2023 (UTC)
I've added the same categories as in the English-language version.
Separately, I'm worried about the claim that Nirts is the original "author" (vs. Ilmari Karonen ?), and its resulting licensing. —RCraig09 (talk)15:35, 7 April 2023 (UTC)
Does anyone know if this an old problem? Or how to solve or avoid it? I'm now afraid to use tspan at all! Thanks for any observations or advice. —RCraig09 (talk)17:43, 25 April 2023 (UTC)
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.
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.
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.
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.
<!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.
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%:
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.
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)
text-anchor="middle" workaround not working
Xc 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.
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)
English translation not rendered in multilingual SVG
Hi again,
This observation is somewhat related to the question above. I translated File:Unfall_Byford_Dolphin.svg into English and Malay (the default language is German). Whereas the Malay version shows with lang=ms, the English doesn't with lang=en (the default German is shown instead):
default
English
Malay
Of course, I could make English the default and add a lang=de translation, but I'd rather not step on the original uploader's toes.
Thanks, @JoKalliauer: on the ticket, hnowlan added a comment on May 10 2023, 3:07 PM, "I think this has been resolved, lingering issues appear to be from edge caching." Might it be a regression on the new renderer? Thanks, cmɢʟee⎆τaʟκ21:26, 11 July 2023 (UTC)
@Cmglee:. Hi. The examples should work, but they have run into problems with a recent upgrade to the SVG renderer. simple is not a valid IETF langtag; en-simple should be used instead. That is, use systemLanguage="en-simple". See Phab:T337139. The SVG spec is happy with simple, but some newer code may enforce legal IETF langtags.
The second file does not have a default rendering in its switch elements. See Phab:T337199. The newer renderer does not set the default language to en. Compare:
Fixed! Thank you very much, @Glrx: "en-simple" works! I tried updating the table on commons:Template:List_of_supported_languages which has "simple" instead of "en-simple" but am unsure how as it just does
The world is more complicated. There are IETF language tags (e.g., en-US; used by SVG). There are MediaWiki language identifiers (usually equivalent to IETF language tags but there are exceptions). There are Unix locale strings (e.g., en_US; they are supposed to be opaque).
The three types are often confused, and several games are played.
Here's another discrepancy. There is an IETF language tag gsw.
MediaWiki uses the string als for that language. Hence there is the https://als.wikipedia.org wiki. Now the IETF langtag als is for a different language (Tosk Albanian). When the als.Wiki includes an SVG file, it uses the correct gsw IETF language tag.
There is an effort to change some MediaWiki language identifiers, but it takes a lot of work. For example, sr-el and sr-ec map to the IETF langtags sr-Latn and sr-Cyrl. I do not know the goals or status of that effort.
It gets worse: locale strings come into play. Old versions of librsvg used the LANG environment variable to pass the accepted language. That environment variable is supposed to be a Unix locale string, but early librsvg used it as an IETF langtag. Then librsvg started using the environment variables as Unix locale strings. So right now MW uses a hack that converts hyphens to underlines and shoves that into the LC_All environment variable; it is not the right thing; I doubt it works for Chinese. Modern versions of librsvg have a command line argument for the accepted languages; that is the right way to do it, but MW is not using those versions of librsvg yet.
If the template is used for MW language identifier support, then the addition is wrong. If the template is used for IETF langtag support, then the addition is correct. The template's apparent purpose is for MW language identifiers (sr-latn and sr-cyrl are not present), so I think the addition is inappropriate.
If it is any consolation, the type confusion creeps into many places.
If the template is a table of IETF langtags, then als should not map to Albanian; simple should not map to English (simple has too many letters for a language: an IETF language subtag should have 2 or 3 letters); cbk is OK but not cbk-zam.
The table is a list of MW subdomains/language identifiers. They are not really subdomains either: there is not an sr-ec.Wiki, sr-latn.Wiki, or zh-hant.Wiki; scripts are not used in subdomains.
Consider how MW interprets the tags.
MW-specific identifiers that are not legitimate IETF langtags
That's all right. Many thanks for explaining what you know, @Glrx: as the template is used on commons:Commons:Translation_possible/Learn_more#Language_codes which educates editors on the use of systemLanguage, I thought that it should be accurate. Perhaps it should have three columns of codes: MW, IETF and ISO 639? I see you've made a good attempt to explain it in the above section, but a layperson would still not be able to know what code to use for edge cases like "en-simple". Cheers, cmɢʟee⎆τaʟκ04:17, 19 July 2023 (UTC)
It still depends on the purpose of the template. I could see a table of MW language identifiers with their corresponding IETF langtags. I'm not sure about the utility of such a list. The important aspect is there are a few WMF sites that use different identifiers (e.g., als → gsw). A list of IETF langtags would be incomplete. MW normally does not distinguish en-GB or en-US.
If the language identifier is used in HTML or SVG, then it should be an IETF langtag. The canonical source for those langtags is the IETF registry. There are some sticky points about usage. For example, Chinese is a mess. MW wants to use zh-hans (macrolanguage-script). Other sites want to use zh-CN (macrolanguage-country; mainland China implies Hans script). Still others want to specify the dialect: zh-cmn (macrolanguage-language; Mandarin) or just cmn (Mandarin; preferred).
There are a few translation MW projects. Those projects may be using the MW identifiers or even a mix of those identifiers and IETF langtags.
"XML, and some XML dialects (SVG and HTML included), don't require a DOCTYPE declaration. SVG 1.2 doesn't even have one. ... Any user agent that identifies XML content using its DOCTYPE declaration is unreliable. The real answer to the question is that XML content tells the user agent which dialect the element names belong to by giving them explicit 'namespace declarations'. ... The namespace declaration is provided by the xmlns parameter."
--Timeshifter (talk) 02:28, 19 July 2023 (UTC)
Beyond the specificities of (X)HTML processing, Doctype declarations in XML languages are only useful to declare named entities and to facilitate the validation of documents based on DTDs. This means that in many XML languages, doctype declarations are not necessarily useful.
The list below is provided only if you actually need to declare a doctype for these types of documents.
”
and lists several SVG doctypes. I haven't seen any issues in thumbnails or browsers with or without it. Cheers, cmɢʟee⎆τaʟκ04:38, 19 July 2023 (UTC)
Commons:Help:SVG is what I needed to find. A detailed SVG help page. From it:
As for cmglee's list, it has four entries. Of these, SVG Basic and SVG Tiny are both stripped-down specs intended for mobile, whereas we use the full spec; our librsvg recognises SVG 1.1; so the only one of the four that is valid is SVG 1.1 Full - DTD:
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
Yes, the DOCTYPE may be left out. But whether it is present or not, the xmlns="http://www.w3.org/2000/svg" attribute should always be used on the <svg> tag; it's difficult to explain, and also difficult to find some clear documentation (section 5.1.1 Overview isn't the easiest part of the SVG spec to understand), but omitting that attribute would either make the rest of the SVG file invalid, or require more complicated syntax for it to be valid. If you really want to read up on it, see Namespaces in XML 1.0 (Third Edition). --Redrose64 🌹 (talk) 23:29, 19 July 2023 (UTC)
Our librsvg doesn't recognises SVG 2, but SVG 1.1, where the attribute is certainly not deprecated. I recall some SVG problems two or three years ago (not necessarily on this page) which were fixed by adding the missing attribute version="1.1". --Redrose64 🌹 (talk) 18:24, 19 July 2023 (UTC)
Yes, but per RsvgHandle Description, Librsvg supports reading SVG 1.1 data, and is gradually adding support for features in SVG 2, therefore, until full SVG 2.0 support is provided, we must not use SVG 2.0 features that are not also explicitly part of the SVG 1.1 spec; similarly, we must not omit syntax that will be optional or deprecated in SVG 2.0 but which is required by the SVG 1.1 spec. --Redrose64 🌹 (talk) 23:44, 19 July 2023 (UTC)
How to remove paths that go beyond the actual vector graphic?
Hello, I have a problem with an SVG file that already exists on Commons:
Basically, the file is very good and should not change if possible.
Unfortunately, the file can only be used poorly in this way. Does anyone have an idea how I can remove all paths that go beyond the actual vector graphic? Bildersindtoll (talk) 07:32, 20 July 2023 (UTC)
First of all thanks for your effort. I use Adobe Illustrator and the paths (like on the screenshots) are still there in your file. But maybe that's not an important point.
My main concern was to use this coat of arms to create an actual vector graphic of the country's flag with the recent details from the coat of arms. This is the PNG on Commons:
Paths that go beyond the actual vector graphic shouldn't be a problem. Indeed, the technique is used quite often, some images being easier to make this way. Consider a very simple example: c:File:BSicon STRr.svg. This has all the appearance of a 90° curve, but in fact it's a circle centred at one corner of the image, so three-quarters of the path is outside the visible area. The SVG spec explicitly allows this in section 7 Coordinate Systems, Transformations and Units, by introducing the concept of an infinite canvas and a finite viewport within that.
cmglee: Inkscape can show the portions of paths outside the viewport, perhaps it's a configuration setting at your end. --Redrose64 🌹 (talk) 18:26, 20 July 2023 (UTC)
Hi @Cmglee Unfortunately it's only an SVG-File but not an actual vector graphic. You can see it if you open the SVG in your browser and zoom in. Basically, I'm trying to put the SVG crest on the flag to make it an actual vector graphic. If you can do that, then of course that would be great. :) Bildersindtoll (talk) 10:24, 21 July 2023 (UTC)
Thank you @Cmglee Looks great, but there's one thing that's not quite right yet. The yellow color no longer seems to correspond to the original. (You can see it compared to the previous versions) I assume you transferred the yellow from the coat of arms to the flag? I think it should be exactly the opposite. I'm not sure if I can change that myself. If it shouldn't be too much trouble for you, I would of course be happy if you could do it. :) Bildersindtoll (talk) 16:24, 21 July 2023 (UTC)
changing EBBD00 to the FCD116 should use the yellow in the "PNG". Other colours are set in adjacent lines.
If there isn't a published guideline, you might want to check with other uploaders to come to a consensus first. Cheers, cmɢʟee⎆τaʟκ22:59, 21 July 2023 (UTC)
@Cmglee I just did it. Thanks a lot again. There is actually a guideline and the color is listed there. By the way, I took a look at your user page and you are doing a really great job here....super interesting. Keep it up. :) Bildersindtoll (talk) 08:52, 22 July 2023 (UTC)
I'm not sure if this is related to the first section on this page, though it may be, and I'm almost certain the issue here is with the tspans. Note how some of the text is incorrectly aligned or flowing off the page compared to the actual file. I would remove the tspans, but I'm unsure of how to do so without manually fixing the location and styles of each piece of text? Any help on correcting the alignment appreciated. – Isochrone (T) 20:21, 23 July 2023 (UTC)
Second, every declaration for the font-family: property should specify one of the five generic family values as the last item in its value-list, as I did with the sans-serif above. So, in the style="..." attributes of the present image, there are over 60 instances having font-family:'Noto Sans'; which should be font-family:'Noto Sans',sans-serif; and also two instances having font-family:Arial; which should be font-family:Arial,sans-serif;
Third, three of the fonts are not recognised by our installation of librsvg - unless a font is explicitly listed at m:SVG fonts, don't expect it to display as intended. --Redrose64 🌹 (talk) 20:58, 23 July 2023 (UTC)
Hi @Redrose64, thanks for your quick reply.Unfortunately that isn't the issue, you're right that Open Sans isn't recognised, and so I removed it and used Noto Sans instead. The redundant style remains (I've removed it) but the actual font families are rendering fine in the SVG file, i.e. not the fallback DejaVu fonts.I know it's not the best SVG, but it renders fine on everything except for rSVG... even if the fonts are falling back I wouldn't expect the positioning to be completely broken(!) – Isochrone (T) 21:09, 23 July 2023 (UTC)
So the issue was this weird nesting of the tspans within groups, I've removed that and it's... somehow working? I'm not really sure but thanks for the help – Isochrone (T) 09:31, 24 July 2023 (UTC)
The latest rsvg ignores text-anchor inheritance, defaulting to start. Try specifying it for each text tag using it. (This fix is not assured as it does not always work.) Cheers, cmɢʟee⎆τaʟκ18:41, 24 July 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Auguel (talk) 16:30, 1 November 2021 (UTC) 
Resolved
.svg)
Done
.svg)
(2).svg)
Done Thanks to Glrx who investigated and filed http://phabricator.wikimedia.org/T322365. I have worked around the bug with an ordered list. cmɢʟee⎆τaʟκ 19:52, 3 November 2022 (UTC)
.svg){kind=small}
cmɢʟee⎆τaʟκ 17:56, 8 January 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. — Johannes Kalliauer - contrib. 17:40, 30 January 2023 (UTC) 
_emissions_per_person_versus_GDP_per_person_-_scatter_plot.svg)
.svg)
_logo.svg){kind=link}
