Help talk:SVG

	Please remember that this talk page is not for questions about SVG.
	It is intended for discussing improvements to the Help:SVG page.
	The best place for questions and discussion about SVG is the
	Graphics village pump
	2007…2009

Multiple Language SVG

Hi,

I made a SVG-file with support for multiple languages, so it can easily be translated and used in other languages IN ONE FILE. With the code:

<switch>
 <text y="20" systemLanguage="de">vor</text>
 <text y="20" systemLanguage="fr">avant</text>
 <text y="20">before</text>
</switch>

every language can be added and depending on the language setting of a SVG-supporting browser you'll have the image in your language. ([Example]) Unfortunatly, by the conversion of SVG to PNG the chosen language is always english. Will there be a possibility to include real multi-language-SVGs in WikiCommon? --Ffsepp (talk) 15:36, 8 September 2008 (UTC)

That's a good question. The text without the systemLanguage attribute, English in this case, is considered the fallback measure when the language of the software program cannot be determine. A PNG converter probably doesn't have a language key so this is why the switch element uses the English text, in your example, as the default text. Wgabrie (talk) 21:17, 8 September 2008 (UTC)

Yeah, the behaviour is right, but especially for a page like commons the multi-language-feature is great. Are there any plans to remove the converter since every browser exept IE is now supporting natively SVG? --Ffsepp (talk) 22:05, 8 September 2008 (UTC)

It would be nice, but probably no (or at least, not yet). Many SVGs run into megabytes compared to bitmaps which probably would be smaller. Spadeparty (talk) 06:14, 6 November 2008 (UTC)

Are there any news for this? Is Commons supporting this feature now? That would be really great!!! --Perhelion (talk) 11:01, 13 May 2010 (UTC)

I looking forward for this feature. It would be very easy to implement. It is possible to use "uselang" URL parameter to make things happen. But will they? BPK (talk) 01:15, 8 August 2011 (UTC)

If size matters, the server may compare and send the smaller one (which in case my svg files is the svg ;-)

There may be an opt-in mechanism for registered users. – Rainald62 (talk) 16:08, 9 October 2011 (UTC)

This is supported now. (Thanks to user:Jarry1250). You can now use syntax like [[file:Foo.svg|lang=de]] Bawolff (talk) 03:12, 11 November 2013 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:19, 22 April 2021 (UTC)

Vector magic no longer free

The help page says that Vector magic is free, but it is no longer so. If an editor here is using this tool anyway, an explanation of the charges would be helpful. Apparently, they do offer a few free conversions to allow potential customers a chance to try their service.

• Vector magic: An online free raster to svg converter.--Davidt8 (talk) 12:23, 11 May 2009 (UTC)

The link above doesn't seem to work. Was found here:

http://vectormagic.com

Perhaps they can't be bothered to provide a redirect page to their for-profit product.

May be fine print elsewhere; the home page says:

Free to try, no signup necessary, and results ready right away.

Is a link to this site linkspam if they are truly providing what appears to be this free service?

-Wmc824 (talk) 15:11, 30 January 2011 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:19, 22 April 2021 (UTC)

Undesirable Restrictions

The section Help:SVG#Creating_SVG_images_for_Wikimedia_Commons makes a generalization that Help:SVG#Bitmaps are a bad thing, inserting the opinions of a third party who is neither the image's author nor it's consumer. Should all of mankind's uses of imagery be restricted to those uses that have been witnessed and understood by a group of programmers? Some examples of svgs with bitmaps:

1. map of Arid Badlands includes the reference image from which it is vectorized. In this capacity, the bitmap provides a measurement of accuracy, and a way for the consumer of the image to visually verify/validate the information presented.
2. A vector graphic of the constellations, with bitmap renderings of the stars.
3. A map of teeth in a mouth, with x-rays for each tooth.
4. It might also be possible to use a self-contained bitmap as a thumbnail in future versions of the SVG interpreters.

AngleWyrm (talk) 16:48, 4 December 2009 (UTC)

Agreed that there are valuable uses, though I’d caution that it can easily be misused or done from expedience rather than because a bitmap is actually useful or necessary. I’ve re-written it more even-handedly in this revision.

—Nils von Barth (nbarth) (talk) 05:40, 23 June 2010 (UTC)

Ponor (talk) 02:42, 26 May 2020 (UTC)

I got quite upset recently when a few of my illustrations got tagged as BadSVG (?!) because they contained bitmap images. Well, let me remind you that all raytraced pictures are bitmaps; also a lot of scientific data comes from cameras and is inherently pixelated. If I need to annotate those, or add paths to them I'd rather have those as vectors on top of the bitmap and not rendered. Scaling the latter produces far, far inferior figures. The editor who tagged my illustrations as BadSVG and recommended deleting them would, I'm guessing, be perfectly happy with every pixel vectorized (1px = many lines of code in svg), or with a badly scaled PNG. Finally, maybe it's time to let browsers render the SVGs and abandon this buggy, unpredictable svg2png conversion for good.

—Ponor (talk) 02:42, 26 May 2020 (UTC)

@Ponor:

Files such as File:ARPES energy-analyzer angle map around normal emission angle.svg should not be tagged with {{BadSVG}}. It is reasonable for some continuous tone images to be present in an SVG file, and you give an excellent example of labeling a photograph. The name of the template is poor because it connotes a bad image. A more neutral name would be something like Mixed Bitmap and Vector SVG. There are well intentioned editors trying to fix SVG files that have inappropriate bitmaps. The simple thing to do here is just grin and bear it. Glrx (talk) 23:11, 26 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:19, 22 April 2021 (UTC)

How SVGs work in MediaWiki

In this section there is a broken link to rsvg-view. Also, it says "If you want the SVG file you must save the link to the image instead of the image itself." But how do you do this?--RockMagnetist (talk) 14:11, 5 October 2010 (UTC)

I have added "by right mouse clicking on the link under the image". For example File:Example.svg‎ has the line "Example.svg‎ (SVG file, nominally 600 × 600 pixels, file size: 10 KB)". You would right-mouse click the blue "Example.svg‎" link. -84user (talk) 17:03, 5 October 2010 (UTC)

Oh - I misunderstood the statement. I thought it was telling me how to access the SVG file from a Wikipedia article. I would like to do that because the PNG conversions are terrible.--RockMagnetist (talk) 17:40, 5 October 2010 (UTC)

I could not find a way to do this using the existing gadgets in Wikipedia:Special:Preferences. You would need to create a link using the Media:namespace to "link directly to a file". I made a quick example at Wikipedia:Extended image syntax#Link. -84user (talk) 18:21, 5 October 2010 (UTC)

MediaWiki talk:Stockphoto.js is now tracking feature requests for the recently installed Share this feature, and it has "Version for Wikipedias to show on transcluded pages" which *might* give what what you are asking for, if transcluded is extended to include thumnbnails. -84user (talk) 18:49, 5 October 2010 (UTC)

I tried using your syntax (and some variations from Wikipedia:Images linking to articles) and I don't get a direct link to the SVG image. One difference I see between my media page and yours is that I have an explicit link to the SVG and you don't. I would really appreciate it if you would look at my link to Media:SingleDomainMagneticCharges.svg in Wikipedia:Demagnetizing field and show me how to fix it.--RockMagnetist (talk) 18:56, 5 October 2010 (UTC)

My placing of the example in the "link=" section was misleading: Media:Example.svg does not gives a direct link when used after "link=", only when used in plaintext so to speak. I tried a clunky workaround using imagemap to create a direct link to the SVG file in Wikipedia:en:Demagnetizing field#Single domain but this link will not update when a new version is uploaded.

I do not think Mediawiki has a way to force the link= to be a direct URL to a media file like this (even hard-coding the full url fails). But are you also asking for the wikimedia server to send your browser the actual SVG file so that the browser performs the rendering? That desirable feature has been requested in long-standing bug 3593, linked from Wikipedia:Wikipedia:Village pump (technical)/Archive 36#Serving SVG images themselves instead of rasterizations. One possibility is some javascript such as prototyped by User:TheDJ in 2008 being added to wikipedia's Monobook.js. Try asking at Wikipedia:Wikipedia:Village pump (technical). -84user (talk) 00:19, 6 October 2010 (UTC)

Thank you for your help, 84user. This all sounds so tricky! Would I be better off uploading PNG files? I have made scores of images for peer-reviewed publications and I have never had so much trouble getting them to look good. Usually I create PDF files.--RockMagnetist (talk) 01:46, 6 October 2010 (UTC)

This section could also have some explanation of the dimensions of the PNG images. For example, File:CategoricalProduct0x0Test0.svg has the sentence "This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px." More correctly it should be "other widths" rather than "other sizes". Where do these widths originate? Why not 100 px wide also? Are all SVGs rendered to these widths? Regards, ... PeterEasthope (talk) 17:37, 10 October 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:19, 22 April 2021 (UTC)

SVG software tagging

When is it appropriate to use those tags? Is it ever appropriate to specify what software was used? I think not! Many files are only converted. The same is, if someone makes a (minor tweak) editing tweak with other software? -- πϵρήλιο ℗ 01:15, 3 August 2011 (UTC)

I never use them. The only tag of real importance is valid SVG. I agree it should only be used if it is either vectorized or created from the ground up. -- RE rillke questions? 09:48, 3 August 2011 (UTC)

@Rillke: I don't consider tagging valid SVG is anyhow imporant. You should e.g. read User:JoKalliauer/Optimization#Invalid_elements_that_should_be_kept what invalid elements are essential and should not be removed.  — Johannes Kalliauer - Talk | Contributions 16:19, 22 April 2021 (UTC)

"upcoming SVG 1.2 standard"

It's not "upcoming" any more -- "SVG 1.2 Tiny" has now been changed to be completely independent from "SVG 1.2 Full", while "SVG 1.2 Full" itself was never officially adopted (and the current working draft hasn't been updated for over seven years), and the next official standard will apparently be called SVG 2.0... AnonMoos (talk) 16:36, 4 July 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:24, 22 April 2021 (UTC)

Scrubbed with http://codedread.com/scour/

Isn't it worth while to establish a template and a hidden category for these optimized files? --Maxxl2 (talk) 19:12, 15 September 2012 (UTC)

I really think not. I see really no reason, for example in contrast to Category:SVG Simplified!? -- πϵρήλιο ℗ 23:00, 15 September 2012 (UTC)

There is a difference. The intro of Category:SVG Simplified says: This category is intended to show examples of manually drawn SVG graphics .... Isn't that reason enough to form a new category? --Maxxl2 (talk) 11:05, 16 September 2012 (UTC)

 Oppose Yes for sure, I know that there is a difference, the difference is that this category is usefully. Can you please more characterize this reason!? I still can not see them. There is no comparable category "automatically saved/optimized ... graphics" ... Thats like a job for a bot, so this is like a hidden bot category!? Anyway if we assume only hypothetically, that there is this category who will all inspect and maintain? And in general I've always automatically saved with Scour. So I would have to categorize all my SVG files afterwards? And alone, what are the real reasons to optimize with Scour? Also then this category should have another pointless template for all this SVG. -- πϵρήλιο ℗ 13:53, 16 September 2012 (UTC)

Thanks a lot for the enlightment. I've learned from your experience and explainations today. Yes, you are right, it was just an idea to be discussed and that is sufficiently done by now. --Maxxl2 (talk) 12:08, 17 September 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:24, 22 April 2021 (UTC)

new rsvg

This should purge a lot of thumbnails and we now have a new rsvg on one imagescaler out of seven (?), so please give a look to Category:Pictures showing a librsvg bug to see if there are more/less/new errors. --Nemo 06:15, 11 October 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:24, 22 April 2021 (UTC)

Not all layers renders, Inkscape

I have a pretty complicated image download here that has some problems. When I try it in the tool for check rendering in wikimedia it doesn't render all my layers. It's the same with the thumbnail in a folder when I view it as icon (ubuntu 12.04). I have tried to find out which layers that is the problem but they all work one by one but not together. I "think" the problem could be in some of those layers; 8, 1 from left,right top side, text 14pt lines, number 26pt lines but I'm really not sure. I have used Path/Union, Difference and so on (read that this could be a problem) and there are gradients, maybe 20 or so.
Path/Union, Difference and so on and gradients have I used in most of the stuff I have made here so I can't really understand this.
I have tried to save it as Plain svg, less layers and a other things but nothing helps.
If anyone have any idea of what to do or look for I would be very very thankful. --Goran tek-en (talk) 13:50, 27 February 2014 (UTC)

 Done I found the problem after some deep search. --Goran tek-en (talk) 17:00, 2 March 2014 (UTC)

Hello Goran tek-en, can you please tell more!? Thank you -- Perhelion (talk) 21:06, 2 March 2014 (UTC)

It will be some of a story. I run ubuntu 12.04 so from my understanding this uses the same lib as wikimedia does for rendering svg to bitmap.

• I started of with an empty Inkscape document with EXACT (I had to adjust it in the code (opened as text)) the same page size as the one with the problem.
  
• Then I had both documents open and a window with the folder containing the two documents viewed as icons.
  
• I then copied one layer at the time from the document with the problem pasted it into place in the new document and saved a copy into that same folder and looked at the icon. If the icon rendered OK then I had no problem in that layer.
  
• I then added layer by layer and when saving a copy making sure all of the added layers was visible so I could see if it rendered well. When I found a layer with problem I removed "half of that layers drawing" and saved a copy. Did it save OK I knew the problem was in the half removed (or the other way around) and I then had to remove half of that and so on until I found the path or what was the problem.
  
• So it was basically a slow tidies work to break down each layer into parts to be able to find the piece that was the problem. If you don't run ubuntu you can use this tool svg check because it does exactly the same thing when it comes to rendering.
  

I'm not sure if I made myself clear on how I did it but if not just ask what and I will try to explain in some other way. --Goran tek-en (talk) 22:50, 2 March 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:24, 22 April 2021 (UTC)

Onmouseover effects - script?

I recently tried to upload an SVG, which was blocked by a warning that it contained code or scripts which might not be displayed property with all browsers. It looked like a warning but acted as an absolute block.

I know that scripts are not permitted in images. Using Inkscape I added to an SVG image an action "onmouseover", which comes out in the XML code for the object as:

onmouseover="this.style.opacity=0" onmouseout="this.style.opacity=1"

I was not aware it would be deemed a script, if indeed it is. Is it?

Mouseover effects can be an effective way to display information. They can be misused: it would be possible to hide a pornographic image beneath an innocent scene, to be revealed when the mouse passes over, and this would not necessarily be spotted by those who vet new uploads. (I was just getting areas of a map to light up.)

Does this mouseover effect count as a blocked script?

Hogweard (talk) 20:21, 1 April 2014 (UTC)

Yes, this is an interactive event handler, although the same can be resolved in HTML also by employing CSS only. For putting information up you can use the Help:Gadget-ImageAnnotator. -- Perhelion (talk) 13:26, 11 April 2014 (UTC)

@Hogweard: Blocked patterns are reported at User:JoKalliauer/IllegalSVGPattern#script  — Johannes Kalliauer - Talk | Contributions 16:24, 22 April 2021 (UTC)

#Cleaning up SVG-files to W3C-valid

Cross-link: I completely disagree with most, see → User_talk:Wereldburger758 -- Perhelion (talk) 13:10, 11 April 2014 (UTC)

I've requested Help:SVG/basic3 for deletion. ↔ User: Perhelion (Commons: = crap?)  14:37, 5 July 2015 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:56, 22 April 2021 (UTC)

Further categorization clarification

Since the SVG categories do not seem to be going away - I suggest expanding on the documentation on categories a bit more. There does not seem to be much consistency and confusion remaining over how overcat'ing applies. Right now this page suggests files should not be solely in SVG categories, but does not really clarify beyond that. Does the overcat wording apply only to the SVG categories themselves or does it apply to SVG categories and non-SVG categories overlapping? Also, the SVG categories mentioned as examples are hidden categories, but that is not consistent. My understanding is that the hidden category usage applies well here and that similar to over hidden categories are not factored into overcat consideration with non-hidden categories. Thoughts? --Varnent (talk)^(COI) 04:51, 6 August 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:56, 22 April 2021 (UTC)

Quotes

@AnonMoos: , IMHO you're right, ordinary quotes will do, but @Perhelion: simply adopted the style already in use for “vacuum” etc. At the moment it's a messy mixture. –Be..anyone (talk) 05:44, 1 November 2014 (UTC)

I would doubt that there's an official Commons policy on the matter, but en:WP:MOS tends to discourage the use of smartquotes. I'll look over the page... AnonMoos (talk) 12:54, 1 November 2014 (UTC)

@AnonMoos and Be..anyone: I admit I was not aware of this recommendation on the enWP. Anyway it is a bit illogical to remove the real(? curly – smartquotes) quotation mark. There is also no source, substantiation or any piece of evidence for this recommendation.

But here in the Edittools are also only the “real” quotation marks, so we can clear say the enWP recommendation has not really validity here!? ↔ User: Perhelion (Commons: = crap?) 12:22, 1 December 2014 (UTC)

The rationale could be, that technical texts should stick to ASCII or Latin-1 if that makes sense (in a context using other Unicode points anyway that wouldn't be the case.) The WP:MOS guideline offers other reasons. This could be obsolete, UTF-8 is now widely supported (and even the Windows variant of Latin-1 has those quotes, working for any Latin Windows installation since at least Windows 95). Just ignore me and change everything back if you like that better; as long as it tries to be consistent I'm fine with it. –Be..anyone (talk) 12:43, 1 December 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:56, 22 April 2021 (UTC)

Category:SVG multilingual

Hi. Should all svg with text be multilingual ? Some svg has a few language versions, like this. I think about templetate : "This is a text svg. It should be converted to multilingual." Is it a good idea ? --Adam majewski (talk) 14:59, 30 November 2014 (UTC)

Hello Adam, good question and short answer no. The category is relatively new, the meaning is not fully elaborated. Any suggestion are welcome. But first:

This cat means SVG with the switch-element like Category:Translation possible - SVG (switch) (not every SVG with other language copy) — so I propose to merge both.

So maybe another suggestion, the template: Translate could get a new parameter to tag SVG language copies to merge!?

Anyway the SVG should be tagged with {{Translate}}. ↔ User: Perhelion (Commons: = crap?) 11:59, 1 December 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 16:56, 22 April 2021 (UTC)

Request for someone to update "Fonts / text" for 2015

Comparison of Liberation Sans and Arial

Comparison of Liberation Serif and Times

Someone please update "Help:SVG#Fonts_.2F_text" section. I'm a SVG newbie editor, though I've done a lot of English-Wikipedia editing. I'm trying to EASILY understand the EXACT fonts that I need to use in my SVG drawings, including LINKS to download the EXACT fonts that I should be using for Wikipedia. I especially need to know exactly which monospaced font that I should be using. I'm editing with Inkscape on Windows 7. Thanks! • Sbmeirow • Talk • 14:07, 8 February 2015 (UTC)

This is actually a very complex topic because there is no "correct" answer (because every system is different – Wikipedia is yet another one – and not every solution works equally well on every system). There are some basic rules however that you can stick to:

• If it's reasonably possible stick to the generic font-families (serif, sans-serif and monospace). Every system picks it's preferred font which fulfills those generic characteristics then, therefore this approach offers the best compatibility. However you have to consider that appearance might change across systems (e.g. font size and letter-spacing might change) and have to design your SVG accordingly (e.g. leave some space around the font and align it correctly, so it doesn't overlap the image when it changes size).
• If you want a more consistent look take a font that is widely available, (e.g. Liberation is a very good choice).
  It's good practice to define a font stack (that is a list of fall-back fonts which are used in case the specified font is not available). However this is not possible with Inkscape at this time (you would have to hand edit your SVGs in a text editor and replace font specifications like font-family:Liberation Sans; with a font stack that will work well on a multitude of systems, e.g. font-family:Liberation Sans,Arial,sans-serif;).
• If you don't want to stick with the default fonts and don't care about compatibility with other systems you can use a specific font from the list of installed fonts (the one from you link). There's also a graphical overview of SVG fonts on Meta (which is slightly outdated though).

Hope this helps. Regards, --Patrick87 (talk) 15:02, 8 February 2015 (UTC)

Follow-up question, why Liberation instead of DejaVu fonts? As Windows user I don't want to overload my box with free fonts only because they are free, and IIRC I picked DejaVu precisely for the reasons discussed here. –Be..anyone (talk) 20:28, 11 February 2015 (UTC)

The biggest advantage of the Liberation font family is, that the metrics of all font faces (Sans, Serif and Mono) are equal to a popular equivalent by Microsoft (Arial, Times New Roman and Courier New). This means you can easily switch from Liberation to the Microsoft equivalent (or vice versa) because the size/position of text in the SVG won't change. By specifying fallbacks appropriately (as described above) this already allows for a consistent look on Windows, Linux and on Wikipedia/Commons (which are based on Linux servers). --Patrick87 (talk) 00:41, 12 February 2015 (UTC)

Liberation Serif shares nearly identical metric as Times New Roman. Because modern MacOS[1] and iOS[2] include Times, making Liberation Serif an ideal choice for serif replacement. -- Sameboat - 同舟 (talk · contri.) 09:04, 12 February 2015 (UTC)

This turned out to be rather exciting for a Windows user: RedHat/Fedora apparently offers two versions, 2.00.1 (2013) and 1.07.4 (2014). The latter are w:Liberation_fonts with a GPL license, the former are newer w:Croscore fonts based on Google's Arimo (sans-serif), Tinos (serif) and Cousine (mono) with an Apache license. Apparently there are more glyphs in the 2.00.1 fonts. They have a good download page. –Be..anyone (talk) 20:48, 14 March 2015 (UTC)

I'm surprised that Arimo has slightly more compact vector data than Liberation Sans because when I convert my SVG to PDF, the PDF size is few KB smaller when using Arimo instead of Liberation Sans. I wonder if Wikimedia has these fonts installed on the server. -- Sameboat - 同舟 (talk · contri.) 02:28, 16 March 2015 (UTC)

@Sbmeirow, Patrick87, and AKosiaris (WMF): I understand your concerns about fonts. I recommend to use fonts listed in https://meta.wikimedia.org/wiki/SVG_fonts#Latin_(basic)_fonts_comparison. However we are dependent on on WMF-Developers proving this list, particularly because they consider to drop it: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/681665 .  — Johannes Kalliauer - Talk | Contributions 16:56, 22 April 2021 (UTC)

@Majavah:  — Johannes Kalliauer - Talk | Contributions 17:19, 22 April 2021 (UTC)

When to use PNG over SVG?

The main page featured image today (File:Vatican City map EN.png) has an SVG version available, but it also has a template that reads "SVG version available, but please use PNG files in articles." Can someone explain to me why this is the case? I was under the impression that SVG was always preferable. Certainly the png file is 2.14 MB versus 418 KB for the svg. I'm not trying to argue that the SVG should be displayed instead, just trying to understand. Thanks. - Themightyquill (talk) 07:19, 11 February 2015 (UTC)

Only if superior (or as replacement for render problems, see {{Technically replaced}}) see Commons:Transition to SVG for more. ↔ User: Perhelion (Commons: = crap?)  08:36, 11 February 2015 (UTC)

(ec) The SVG version is based on Italian PNG, also it seems that the SVG rendering isn't quite identical to the author's intention. The major culprit is that the map uses "textpath" to render curved text like "Via del Seminario Etiopico" and "Via del Governatorato" so text would bend alongside the designated path. Textpath sadly isn't supported by librsvg, the SVG rendering engine used by Wikimedia, so any text wrapped inside textpath like "Via del Seminario Etiopico" disappears from the SVG render on WM. -- Sameboat - 同舟 (talk · contri.) 09:06, 11 February 2015 (UTC)

Thanks, Sameboat, that makes perfect sense. Would it not be a good idea to have a template to mark SVGs using textpath, and maybe put them in a category? Firstly, it would explain why those SVGs should not be used (in preference for PNGs) on wikipedia. Second, if/when librsvg does begin to support textpath, then those SVGs could be swapped in. Themightyquill (talk) 20:41, 11 February 2015 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 17:03, 22 April 2021 (UTC)

Killing font dependencies for SVG tiny

@Sameboat: Your tip sounds plausible, but shouldn't that be also a feature request for librsvg-convert, arriving in some unofficial Windows librsvg-convert.exe   port before 2020? –Be..anyone (talk) 16:49, 8 April 2015 (UTC)

You may make the request there. To me I never really bother converting text to path. That tip is just a recap of the previous discussion in Village Pump. -- Sameboat - 同舟 (talk · contri.) 22:55, 8 April 2015 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 17:03, 22 April 2021 (UTC)

Text box altered when uploaded

When the svg is edited locally the text box maintains its size, but when uploaded the text in the box does not maintain its size and just becomes a single line. Thanks. File link — Preceding unsigned comment added by MaryroseB540 (talk • contribs)

librsvg and most browsers do not support SVG v1 text box, not until SVG v2. Rework it without text box please. -- Sameboat - 同舟 (talk · contri.) 14:42, 11 June 2016 (UTC)

Thanks i worked it out. — Preceding unsigned comment added by 46.198.49.49 (talk • contribs)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 17:03, 22 April 2021 (UTC)

Linking svg files to data

Can someone direct me to any conversations / projects on automating the colouring of maps, charts etc on the fly, through linking to a database. For example the recent election map File:2017 UK General Election map.svg could autmatically be coloured in by linking the colours / constituencies to a database. I'm sure that this is done locally, on the user's computer; however, for transparancy, it would be better if it was done on the fly, on wiki. I think it would be very handy when census data is published to automatically generate svg files. Llywelyn2000 (talk) 05:55, 14 June 2017 (UTC)

Generally, no. If the processing is done in the SVG file, then it must be done with a scripting language, and WM does not allow scripts in SVG.

Furthermore, MW does not serve the SVG but rather a PNG derived from the SVG. The program used to paint the PNG does not allow scripting. I believe the program also does not use external CSS files, so coloring districts with external CSS data is off the table, too.

In the case of the UK GE map, it is very piggish at 3.75 MB. It could be unreasonable to serve such a large file. SVG files can be animated (e.g., to show districts over time), but the animations are lost in the served PNG, and browsers are thinking of dropping SMIL animation in favor of script animation.

MW SVG files are limited, and it is probably a good thing that they are right now.

Glrx (talk) 23:30, 16 June 2017 (UTC)

@Llywelyn2000: External content is, as Glrx said, not allowed see also User:JoKalliauer/IllegalSVGPattern#external_content  — Johannes Kalliauer - Talk | Contributions 17:03, 22 April 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 17:03, 22 April 2021 (UTC)

Thanks both. I'll turn to using wiki code, updated on a daily basis by a bot. Llywelyn2000 (talk) 19:56, 28 April 2021 (UTC)

How to download and open an svg

I could not find an instruction on the help page for how to do this. · · · Peter (Southwood) ^(talk): 16:39, 27 June 2017 (UTC)

Did you try, on any «File:···.svg», clicking on the large rectangle with the rendered (PNG) image and then using the browser’s menu to save the file? Also, you can enjoy the Media Viewer for this purpose. Incnis Mrsi (talk) 17:05, 27 June 2017 (UTC)

In the file description page, right-click on the image and select "save link as..." to download the source SVG. You can open it in your browser tab to view it in real-time or any text editor to read or edit the XML source code. Today many vector graphics editors can open SVG file natively but be careful of the exported SVG from these applications can often be rendered incorrectly on Wikimedia, c.g. help:Illustrator. -- Sameboat - 同舟 (talk · contri.) 03:57, 28 June 2017 (UTC)

The intention was to edit the file on Inkscape. I found that the only way that I could do it was to open Inkscape, then open the source file in Inkscape, using the url on commons, and then save. I could not find a way to save the svg direct to my drive. This does not seem right. I can view an svg on Firefox, but cannot download it. · · · Peter (Southwood) ^(talk): 20:23, 28 June 2017 (UTC)

Most browsers (Mozilla Firefox included) offer the [Save Page As] option in the File dialog on any page, being it HTML, SVG, or JPEG. Just save what you currently browse. But some people make up a problem where at least one intuitively evident solution exists, supplemented by many others. Incnis Mrsi (talk) 09:00, 2 July 2017 (UTC)

Perhaps not as intuitively evident as you assume. Cheers, · · · Peter (Southwood) ^(talk): 19:15, 2 July 2017 (UTC)

What I found particularly counterintuitive is that when I select and open an svg file there is a menu bar across the top. The first item is download, bur when I click on download, I get a dialog box in which there are a couple of urls, an attribution link and several size options for downloading "Download image file: 32px | 64px | 128px | 256px | 512px | Full resolution." I do not expect an svg file to be associated with a size in pixels. All of these options except full resolution specify a size in pixels, and are unsurprisingly png renders. Only the last one does not specify anything except full resolution, which to me, would suggest it is also a bitmap, as there are no variable resolutions in a vector image. At this point I assumed that only bitmap downloads were possible. · · · Peter (Southwood) ^(talk): 07:51, 10 July 2017 (UTC)

Thanks but no thanks to your edit in the help page. First, many users (including me) have disabled that file page download helper bar. Second, every wiki file description page provides the same way to download the very source of the file by right-clicking on the central image preview. For downloading SVG source, as long as the URL displayed in the bottom browser bar while hovering on the central image preview ends with ".svg" instead of ".png", it's unmistakably the source SVG. I can't let such basic wiki page usage clutter the SVG help page which is for more specific technical instruction. -- Sameboat - 同舟 (talk · contri.) 12:59, 10 July 2017 (UTC)

The instructions were not intended for people who have disabled functionality, they are for people who have difficulty working out how to use the not quite so obvious default setup. I am not going to make a big deal of this, though I do think that the system is not as obvious as some would like to make out, and that either the software or the instruction should be improved. Since I cannot do anything about the software, I did what I could with the instructions. Having a system which is not easy to use reduces the availability of the material on Commons for re-use, defeating the object of the project. · · · Peter (Southwood) ^(talk): 16:40, 10 July 2017 (UTC)

Error template for SVG files that can't be viewed

What kind of error template should be used for files that won't display in the browser when viewed directly? For example, Coat of Arms of East Prussia.svg has a PNG preview but when you try to look at the SVG file itself, you get the error "This XML file does not appear to have any style information associated with it. The document tree is shown below." When I try to download it, I get a file that is zero bytes, but I don't know if it just won't download it or if it is actually a blank file that somehow generated a PNG preview during upload. Is {{InvalidSVG}} specific enough? Wikimandia (talk) 03:46, 13 September 2017 (UTC)

Wikimandia I would say the {{InvalidSVG}} and possibly {{Browserwarning}} is the best in this situation. Whether a SVG renders or not regardless if there are errors would be browser specific, so some users may see a problem while others may not. I've confirmed the SVG file does have errors that need to be corrected but I tested viewing the SVG in Chrome (on Windows 10), Firefox (on Windows 10), Internet Explorer and Microsoft Edge and none of them gave that message when viewing the SVG and all appeared to render the SVG correctly for me at least. The SVG file is 6+ MB so it could be that your web browser/computer had problems handling processing that large of a file (large in terms compared to the average sizes of most SVG files) which is why I also suggested adding {{Browserwarning}}. - Offnfopt^(talk) 04:07, 13 September 2017 (UTC)

I'm using Chrome on Mac, but it can't be browser specific, especially because I can view larger ones. WikiCommons own SVG checker (Commons:Commons SVG Checker) won't validate it and spits out the same error: File size is: 0 bytes. WARNING: XML declaration not found and is strongly recommended. Successfully parsed XML structure. Not a SVG XML structure. Check finished! Wikimandia (talk) 04:21, 13 September 2017 (UTC)

Fallback fonts

WARNING in <g>: Font type Bitstream Vera Sans is not available in Wikimedia software. It will be rendered with minor differences by Wikimedia's SVG renderer. See https://meta.wikimedia.org/wiki/SVG_fonts for details

— Commons:Commons SVG hecker

I sometimes edit files of others (I am a part of the german Graphics Lab), and I would like to replace the fonts with minor changes, therefore I would like to know which are the fallback fonts, or the fonts which will be used instead of the original font.

For example (Help:SVG#Font_substitution_and_fallback_fonts):

• Arial => Liberation Sans
• Times New Roman => Liberation Serif
• Courier New => Liberation Mono
• Bitstream Vera Sans => ...?
• Sans => ...?

 — Johannes Kalliauer - Talk | Contributions 19:52, 22 October 2017 (UTC)

Replacing font names is a bad idea. The MW renderer already substitutes for Arial and Times New Roman, so the change is pointless for MW. A Commons SVG Checker warning such as that is not serious on its face. Down the road, the substitution has dubious value. The MW renderer may know "Liberation Sans", but most of the user agents out there will not know it; they do know "Arial". Even changing the string to "Arial, Liberation Sans" is pointless. An appropriate change might be to append a generic font to unusual font names. For example, "Bodoni" could go to "Bodoni, serif" if you know that, but even then most user agent font substitutions are close enough. So some labels show up as sans-serif when they should be serif; what's the big deal? The problem that users confront with fonts are layout issues that are much more subtle. A user selects a condensed font to make a label fit, but that font isn't available, so text overruns on librsvg.

Currently you are making SVG edits that allegedly "fix" errors, but end up deleting RDF. Leave metadata alone; there should be a lot more of it rather than less. Deleting metadata can easily be a copyright violation. I have no qualms about removing most inkscape:, sodipodi:, and Adobe namespace items, but there are exceptions; it can be a bad idea to remove attributes such as inkscape:stockid="DotM". Deleting some Adobe namespace items implies removing a switch element. It is also a bad idea to compress paths the way you have doing. Changing 0.123,0.456 -0.789,0.123 0.666,0.777 to .123.456-.789.123.666.777 may save space, but it is overkill. XML is a crappy format, but it is supposed to be human readable. LZW is very good at compressing structured spaces and repetitious style strings.

Glrx (talk) 21:17, 22 October 2017 (UTC)

Tanks for the answer. I'm working in the de:Wikipedia:Grafikwerkstatt and sometimes users whish new grafics. Therfore I use elements from different *.svgs. I would like that the new svg created on my computer (use Linux or Windows) looks the same as the picture created by the MW renderer. I could take new ones, but I would like to keep it similar to the style of the existing svg. I don't want to change fonts of existing svgs created by others.

 — Johannes Kalliauer - Talk | Contributions 15:29, 24 October 2017 (UTC)

The simplest approach is to use common font families with an explicit fallback to a generic font. Even simpler is to just specify the generic font.

For example, File:Globe valve diagram.svg uses font-family="Bitstream Vera Sans"; MW displays it sans-serif even though Bitstream Vera Sans is not in the font list. If I click on the image to look at the SVG in my browser, the text displays with a serif font. The font shift is a surprise, but it doesn't make much difference to the result. If the font is important, then the font specification should have been font-family="Bitstream Vera Sans, sans-serif".

If I were merging several images into one, then I would change the font families and sizes to be uniform. It's distracting to have slightly different font-families and font sizes in a single diagram. SVG font size specifications are often absurd. I've seen too many files with specifications such as font-size="18.378612px". Maybe they convert to reasonable point sizes, but the precision not needed.

Glrx (talk) 16:41, 24 October 2017 (UTC)

@AKosiaris (WMF), Majavah, and Dzahn: Could you provide a list of Fallback-fonts? Perhelion (when he was admin) created File:SVG_Text_Font_Test.svg and it contains a fallback to Nimbus Sans L, however it is not in the current font-list. Do you know what's wrong?  — Johannes Kalliauer - Talk | Contributions 17:19, 22 April 2021 (UTC)

Anomalies with font attributes, especially font-style

with CSS

without CSS

Dear SVG experts!

I discovered that the converter handles font attributes defined via classes (the CSS syntax) differently than if they are specified via font-family="sans-serif" and font-style="italic" (SVG syntax). Note that it’s not me, but one Perhelion who crafted <text>s for the latter image, so I shouldn’t subscribe to correctness of the SVG code. Also there is now a posting on StackExchange about interpretation of font-family.

Somebody is certainly at fault, but who: rsvg developers, Wikimedia technicians, or an unreliable SVG code happened? Opinions? Incnis Mrsi (talk) 18:38, 27 December 2017 (UTC)

Update: It turned out that the current converter doesn’t reproduce the bug imaged with font-style="italic"_in_rsvg_at_Wikimedia.png mined from the MediaWiki cache, which was produced somewhere between April 9, 2014 and today. This likely isn’t a CSS–SVG difference of the converter, but its transient malfunction at an unknown date in the last four years. Incnis Mrsi (talk) 19:44, 27 December 2017 (UTC) specifically, on 2014-04-09 14:34 UTC according to the «Date:» header. Incnis Mrsi (talk) 12:46, 28 December 2017 (UTC)

@Incnis Mrsi: I think the rendering-problem is CSS-independet.  — Johannes Kalliauer - Talk | Contributions 22:35, 27 December 2017 (UTC)

Re SVG:

Don't use random fonts without a generic fallback.

Generic fonts: font-family: serif and font-family: sans-serif are sensible, but font-family: sans is not.

Keep the code clean: use elements should link to elements in the defs section rather than deep clone elements that are also rendered in the body.

Do alignments right: text-anchor="end" is your friend.

Glrx (talk) 22:48, 27 December 2017 (UTC)

---

Thanks for your activity, people. Happy New Year! Incnis Mrsi (talk) 12:46, 28 December 2017 (UTC)

link to specific language version

中文（繁體）

I would like to link to https://commons.wikimedia.org/wiki/File:History_of_the_Universe_lang.svg?lang=zh but I don't know how. I tried:

[[:File:History of the Universe lang.svg?lang=zh|lang=zh]], [[:File:History of the Universe lang.svg|lang=zh]]

lang=zh, lang=zh

{{F|1=History of the Universe lang.svg?lang=zh|lang=zh}}, {{F|1=History of the Universe lang.svg|lang=zh}}

History of the Universe lang.svg?lang=zh, History of the Universe lang.svg

{{technically replaced|1=History of the Universe lang.svg?lang=zh|lang=zh}}

Sorry, this SVG file is solely a source for re-utilization, editing or printing purposes. Please do not use this graphic within Wikipedia articles! MediaWiki isn't able to render this image correctly. Some details may be missing or look wrong. When you include the image in a Wikipedia or any other Wikimedia project site's page, you may want to use the other file, until the support increases. Help talk:SVG File:SVG.png

 

{{vva|1=History of the Universe lang.svg?lang=zh|lang=zh}}

File:History of the Universe lang.svg?lang=zh.svg is a vector version of this file. File:SVG → File:History of the Universe lang.svg?lang=zh.svg | lang=zh  For more information, see Help:SVG. In other languages

lang=zh

 

 — Johannes Kalliauer - Talk | Contributions 22:51, 27 December 2017 (UTC)

The file has multiple languages, but there is only one file and therefore only one wiki markup link:

• File:History of the Universe lang.svg

Such a link goes to the File: page; it is not a link to the SVG file itself. Just ask the reader to follow the link and then select the appropriate language from the dropdown box when he gets there.

If you try to include a URL parameter to specify the language, then the wiki markup will URLEncode the "?" to "%3F" because it believes the "?" is part of the filename:

• History of the Universe lang.svg?uselang=zh-hant

Switch-translated files were an addition to MW, so the markup wasn't made to handle links with URL params.

For a link with URL parameters, just use single brackets and a raw URL:

• File:History of the Universe.lang?lang=zh-hant

If the reader can read Chinese, then

• zh:File:History of the Universe lang.svg

works, but does not keep the reader on his wiki or transport him to Commons...

For the templates, just use the file name without the language argument. A Chinese reader will get to the correct file, and the documentation should describe how to add the lang argument. To make it clearer, the templates need modification to take lang params.

On another front, zh is an IETF macrolanguage rather than a language. SVG files should use langtags such as zh-Hans (simplified Chinese) or zh-Hant (traditional Chinese). It turns out that librsvg is broken and will will display the first zh-* it finds, but the browsers will do it a little better. BTW, only use one langtag per systemLanguage attribute because Chrome and Edge don't do it right. (Chrome will work if you put spaces around the commas: systemLanguage="de , fr , it", but Chrome will think there are two "," langtags.) It's one of those rare places that librsvg does a better job than Chrome.

Glrx (talk) 23:52, 27 December 2017 (UTC)

@Glrx: Thanks for the answer. I tried zh:File:History of the Universe lang.svg, but on my computer it renders the english version (also if I'm not logged in).

@Glrx: Maybe you know how to "repair" File:Structure_of_the_magnetosphere_LanguageSwitch.svg it uses systemLanguage="ru-1" for File:Structure_of_the_magnetosphere-ru-1.svg and systemLanguage="ru-2" for File:Structure_of_the_magnetosphere-ru-2.svg. Due to a renderbug I created one workaround version (based on the solution proposed by Perhelion) and I added all different language-versions with a language-switch. There were two Russian versions. Is it possible to have one file with a languageswitch with two Russian versions?

 — Johannes Kalliauer - Talk | Contributions 17:17, 28 December 2017 (UTC)

(Oops; wrong referent about zh:.) Yes, it displays English. IIRC, MW design decision is to default images to lang=en. If it defaulted to the WP's language, then MW would be generating language-specific versions even when that language is not available in the SVG file.

You are opening a old wound with langtag handling because File:Structure of the magnetosphere LanguageSwitch.svg won't show either "ru-1" or "ru-2" in the language select dropdown, langtag sorting is gone, and WMF developers are monumentally confused about SVG langtags.

You cannot display the "ru-1' image with the dropdown control, but you can use "lang=ru-1" in the URL to do the display:

• https://commons.wikimedia.org/w/index.php?lang=ru-1&title=File%3AStructure_of_the_magnetosphere_LanguageSwitch.svg
• https://commons.wikimedia.org/w/index.php?lang=ru-2&title=File%3AStructure_of_the_magnetosphere_LanguageSwitch.svg

The magnetosphere SVG uses the langtags "ru-1", "ru-2", and "numbered"; those langtags should not be used because they do not conform to the BCP47 specification. A singleton such as "-1" should be followed by another subtag; "numbered" is not in the registry. Multiple versions of the same language are allowed in an SVG file. For example, SVG can be written to distinguish American (en-US such as "color") and British (en-GB such as "colour") spellings. Conforming langtags could be "ru-x-1", "ru-x-2", and "qqz-x-numbered" (or "qqn"), but those langtags are poor. For the Russian langtags, there's probably a regional difference in the phrases that should be distinguished with existing region subtags such as "ru-RU" (Russian as used in Russia) and "ru-UA" (Russian as used in the Ukraine). (Those region subtags are only an example; I don't know the regions involved; I'd have to ask a Russian speaker why different phrases are used.) (More problems: hyphenated langtags don't work correctly in librsvg, so it does not distinguish "ru-RU" from "ru-UA".)

On another issue, the switch-translated magnetosphere SVG file has grouped all phrases in one language together (all the "de" text elements are selected with one switch). I call that approach a planar translation. It is better to use more switch elements and group the phrases with the same meaning together. That is, one switch element for every phrase that needs to be translated. That's how switch elements are used in File:First Ionization Energy.svg. Keeping similar phrases together makes it clearer what needs to be translated. I like that you kept multiline translations within one text element.

Glrx (talk) 21:20, 28 December 2017 (UTC)

Help with Bold Font

Tracked in Phabricator
Task T25643
DECLINED

Hello, I am somewhat of a new SVG editor, although I find it very enjoyable (especailly converting old .png into .svg). I'm coming across a strange issue I was hoping to resolve. I've been working on making "election apportionment" diagrams, diagrams used to show how many members of a certain congressional body belong to a specific party. A file called 114thHouse.svg is an example of what I mean. However, I'm coming across some strange issues. Whenever I upload my .svg to wikicommons, I lose my bolded font. For example, look at US_House_193-239_(3V).svg (notice the 435 is bolded) and compare that to 114thHouse.svg. Why is this happening? In Adobe Illustrator, I can see there is bold font.— Preceding unsigned comment added by PeterMGrund (talk • contribs) 03:01, 13 January 2018 (UTC)

Hello Peter, this is task phab:T25643. Adobe used his own (proprietary) font-name systematic, which is also for me not understandable. I fixed one of your files for example.  -- User: Perhelion 03:36, 13 January 2018 (UTC)

Why one should expect «.st0{font-family:'Helvetica-Bold';}» to be understandable by anything but Adobe Inc. house products? This is a non-standard CSS inciting vendor lock-in. On Commons, such things must be fixed on sight, thanks user:Perhelion. @PeterMGrund: use links File:US_House_193-239_(3V).svg and File:114thHouse.svg (with colon after opening square brackets in the wiki code). Incnis Mrsi (talk) 08:19, 13 January 2018 (UTC)

All characters piled-up

Hello

I created the following file with a text editor: File:Carte hexagonale 8mm numerote 35hex.svg

Everything seems perfect when I display it with Firefox or Chrome or when I import it into Inkscape. However, the SVG-to-PNG does not work well. I guess it is related to text-anchor="middle" but the problem does not seem to be listed here (or maybe I just didn't see it or understand it).

Of course I can import it into Inkscape then save it (it seem to automatically set the text anchor to left while keeping the correct position) but I find this solution a bit unsatisfying.

Any hint?

Regards

Cdang (talk) 13:20, 19 February 2018 (UTC)

Explicit definition of letter-spacing was decisive, although I have no idea why was it that wrong by default. It is better to post such stuff to Commons:Graphics village pump next time, anyway. Incnis Mrsi (talk) 14:21, 19 February 2018 (UTC)

Thanks a lot Incnis Mrsi. Regards

Cdang (talk) 16:05, 19 February 2018 (UTC)

My guess is that the poor spacing is another incarnation of using small font sizes. The picture had font sizes of 0.4. One should not need to add letter-spacing. Glrx (talk) 18:38, 20 May 2018 (UTC)

"Most major bugs which have been reported to GNOME for years are going to remain as is"

The text says "Most major bugs which have been reported to GNOME for years are going to remain as is". This appears to be inaccurate, as, for example, the mask bug Phab:T55899 is corrected in the last version https://gitlab.gnome.org/GNOME/librsvg/issues/105#note_83452 : "This is fixed in 2.42.3; possibly as low as 2.42.2". In this case, it's Wikimedia's fault to use a old version (seven versions between librsvg 2.40.16 and librsvg 2.42.3) of librsvg (which, btw, seems to be in an active state). Thomas Linard (talk) 14:37, 2 June 2018 (UTC)

I don't see the contradiction here. First, the statement is a direct quotation, so it is true. Is there another maintainer claiming that the source is out of deep freeze and major bugs are being fixed? There is a substantial effort translating C++ code to Rust, but that effort has translated buggy code without fixing it. Second, the claim is about "Most major bugs". Fixing a single major bug would not negate the "most" claim. Third, Phab:T55899 is apparently a four-line fix, so it does not seem to be a major bug but rather a minor bug. See User:Bawolff Sep 9 2013, 10:35 PM comment (almost 5 years ago). Fourth, there are simple bugs that should have similar short fixes. For example, problem with style not defaulting to type="text/css", problems with small font sizes, problems with vertical text escapement, and confusion about text-anchor with right-to-left text. A major issue (not necessarily a bug) is support for textPath and for font baseline support. Glrx (talk) 03:25, 4 June 2018 (UTC)

Cleanup image with white space

See File:Digital-elevation-map-so california.png.svg.

I made this by cropping a file in the Commons. I did not notice that the map image after the crop has a lot of whitespace around it making the image too small. Do I start over, delete the file, edit in AI and upload again? How? Or can I clean up inside WM Commons? How? — Preceding unsigned comment added by BrucePL (talk • contribs) 19:36, 6 June 2018 (UTC)

Apparently resolved. Glrx (talk) 01:02, 7 June 2018 (UTC)

Internet Explorer 11 and up: toggles on click interactivity in pure SVG?

Is it possible, when working with pure SVG (no Javascript et cetera), to have a user, on Internet Explorer 11 and up (without any further browser plug-ins) click on one part of an SVG, and to thus toggle the visibility of another part of the SVG? If so, could you please create a MWE that demonstrate the possibility? Please also answer at https://stackoverflow.com/questions/51199162/internet-explorer-11-and-up-toggles-on-click-interactivity-in-pure-svg Vincent Mia Edie Verheyen (talk) 05:08, 6 July 2018 (UTC)Vincent Mia Edie Verheyen (talk) 05:07, 6 July 2018 (UTC)

Font issue

I recently made a plan for a stadium File:Northumnerland Development Project.svg to illustrate articles like Tottenham Hotspur Stadium. However I notice that lettering does not come out right in the thumbnail image in the article. I have no idea what the issue is, and as this is the first time I have ever made a svg file with Inkscape, and not a very good attempt at the job, I must have made some mistakes somewhere. Can anyone help? Hzh (talk) 08:59, 14 July 2018 (UTC)

@Hzh: → Commons:Graphics village pump. Incnis Mrsi (talk) 11:57, 14 July 2018 (UTC)

Thanks. I'll move the discussion there. Hzh (talk) 12:01, 14 July 2018 (UTC)

Blank SVG image after upload

I have created a few SVG maps using Inkscape. These images are rendered correctly in browser, but after uploading to Commons the files look empty ((File:Assam district locator map Baksa.svg and others Category:Locator maps of districts of Assam) where the original file remains OK (here). Does anyone know what might be going wrong here? --SlowPhoton (talk) 09:09, 28 December 2018 (UTC)

@SlowPhoton: the thing “wrong” is almost certainly the software which generated these SVGs. Ask on Commons:Graphics village pump, and specify how namely did you modify original images (and which exactly). Incnis Mrsi (talk) 10:04, 28 December 2018 (UTC)

Please use Commons:Commons SVG Checker, and you will know the problem:

• WARNING in <mask> with id=mask2921: Mask element found with maskUnits set. It will not be rendered properly by Wikimedia's SVG renderer. See https://phabricator.wikimedia.org/T55899 for details.

see Commons:Graphics_village_pump#Blank_SVG_image_after_upload for details  — Johannes Kalliauer - Talk | Contributions 13:17, 28 December 2018 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 13:19, 28 December 2018 (UTC)

New server fonts?

Tracked in Phabricator
Task T221453

I personally find the Liberation family out of date for svg drawings, they remind me of old Linux distributions. Would it be possible/appropriate to add some fonts to the server? I think that the Source Sans/Serif/Code Pro from Adobe would be a welcome addition – and since they're OFL licenced, there should be no problem with using them. --Nefronus (talk) 19:30, 13 July 2019 (UTC)

@Nefronus: It was already suggested by @OSeveno: in April, and I created phab:T221453. Liberation family is used for substituting Times und Arial, both are still widely used. Times might be the most used font in scientific journals, therfore I personally find the Liberation family as still a valid font. If you don't like Liberation familiy you can use different fonts, see meta:SVG_fonts for all available fonts.  — Johannes Kalliauer - Talk | Contributions 07:47, 14 July 2019 (UTC)

@JoKalliauer: It appears that on the field of fonts we are surrounded by conservative old men at Phabricator. Proposing new fonts either gets ignored or criticized and deemed unnecessary. Even you let yourself be pushed into accepting just a minor expansion of missing branches of existing fonts. And Nimbus would not add anything significantly different or newer than the existing. Adding the last missing branches of DejaVu is only finishing a job half-done and why even consider Century Schoolbook L? My proposal for Fira Sans Font Family is based on it's excellent characteristics for usage on the Internet and the fact is has a really big character set including text figures and small caps. It's about usability. On Wikipedia we have limited space on the screen for images. So when I create a new map for example, I like to use a font with very good readability on a thumb image, while not looking like a font from the '80s. Sometimes it appears that Commons/Wikimedia/Phabricator is completely dominated by old-school Linux supporters. (btw I also use Linux next to Windows) --oSeveno (User talk) 10:39, 14 July 2019 (UTC)

It seems that user-extensions get developed very extensible, but there are view Tech-Support-People by the foundation to implement anything, therefore they seem to use out-of-date but stable software. (In security-issues they are up-to-date.) We updated in April 2019 to librsvg 2.40.20, which was published in 2017. Everything what the Foundation has to mantain seems to be backward. Ps Glrx, the only person who answered on phab and I would not call him "conservative old men". I do not know anywone on Wikimedia who knows the SVG2.0-draft better than him. And I assume that SVG 2.0 will be the future of SVG-Rendering. phab: seems to me to be a graveyard for bugs, where they exists "forever", without any progess, that's not (only) related to fonts.  — Johannes Kalliauer - Talk | Contributions 13:57, 14 July 2019 (UTC)

I'm not sure what to say here. There are several considerations.

Many of the SVG files on Commons are problematic. The text is poorly typeset. Some text is not anchored correctly; it is text-anchor: start and positioned to end in the right place; different fonts have different metrics, so the ending position may move; the text should have been text-anchor: end Some times text has separately painted subscripts and superscripts instead of tspan elements. Many files use uncommon fonts without specifying fallbacks. It may be that few SVG files on Commons specify fallbacks. And some designers get so frustrated at trying to make the fonts come out a particular way on Commons that they convert the text to curves. There are many problems with SVG files. It is, perhaps, a more important issue than adding fonts.

Many efforts focus on getting librsvg to produce acceptable images, but that can miss the point that Commons is a source of images for not just WMF Wikis but also for everybody. We should want the display to work well in all SVG agents. Arial is a font that is recognized by many SVG agents. Using font-family: Arial will produce reasonable results on many SVG agents. That is one of the reasons I dislike changing "Arial" to "Liberation Sans": it will confuse many of those agents. There is an advantage to sticking with common font families.

Sticking with common fonts does not always work. Graphics illustration programs do not seem to help compatibility, and they bring their own host of problems. Adobe Illustrator spits out font descriptions for Arial that other SVG agents do not understand. Inkscape emits reasonable font descriptions, but it outputs bloated SVG unless a user is sophisticated enough to limit that output.

It has been hard to get information from WMF staff. I do not know if the font list used by the Commons SVG Checker is accurate. I do not know how many bytes WMF is willing to serve (i.e., how small would an SVG file have to be for WMF to consider directly serving SVG rather than converted PNGs). WMF probably also needs good reasons for undertaking significant changes to its image handling. If it is not broken, then do not fix it. WMF also confronts problems of scale. Yesterday, a friend told me his company has 18,000 servers. I do not understand operations at that scale. Small mistakes may have dire consequences, so they can understandably be conservative.

I could say a lot about Phab, but I do not think the effort is worthwhile. The simple view is some volunteer needs to do the work or it will not get done. With respect to bug residence time, many bug lists (not just phab) move at glacial paces. It is a matter of priorities and resources. There are ancient bugs on the librsvg buglist. I've done parallel browser bug reports on Chrome, Edge, and Firefox with very mixed results. For one parallel bug, Edge has not fixed it, Firefox jumped on it, and Chrome ignored it until they found a volunteer to work on it. I've done bug reports that include which lines of code need to be changed with even stranger results. Sometimes the change is promptly done, and sometimes the change is not done at all.

The tone of the initial request is off the mark. "I personally find the Liberation family out of date for svg drawings" sounds more like a statement of personal preference for some fonts over other fonts rather than a request that has significant engineering merit. A subsequent comment raises usability but is critical elsewhere.

I'm not against adding improved fonts. I do not know about Adobe's en:Source Sans Pro and variants. en:Fira Sans says many good things about the font. One of the features of Arial is it has a condensed version (Arial Narrow) and a Heavy version (Arial Black). It sounds like Fira Sans may be even better in that respect. It may be a good default sans-serif font. Adding a font should be a simple matter of copying it into the relevant master distribution directory. Making it the default sans-serif font would be more involved and probably require discussion and consensus.

That said, I'm not sure I want to see uploaded SVG files using font-family: Fira Sans. Even if it works on an improved Commons, it will display as Times New Roman on my laptop unless I download the font family. Although it may be the typeface of the Mozilla brand, the font does not exist on my laptop even though I have installed Firefox. Is the font a standard install on any operating system? I do not want to be fielding questions about librsvg output looking great but opening the SVG in a browser looking both different and horrible. We already get a lot of questions going the other way.

Maybe the font installation problem can be solved with CSS @font-face {font-family: …; src: …;}, but I doubt WMF would want automatic downloading triggered by SVG files. WMF currently disallows SVG external symbol libraries. There are too many opportunities for mischief.

Glrx (talk) 23:49, 14 July 2019 (UTC)

Can .jpg image be converted into .svg image?

How can I convert a .jpg image into a .svg image, for uploading to Wikimedia Commons?Davidbena (talk) 22:01, 14 July 2019 (UTC)

The simple answer is no. JPEG images are bitmaps, but SVG is a vector format. A proper conversion needs to recognize the objects in the bitmap and turn them into vector shapes. Letters should also be recognized and turned into text. There are programs that do bitmap to vector conversion, but they usually need subsequent editing. You might inquire at Commons:Graphic Lab/Illustration workshop. Glrx (talk) 23:55, 14 July 2019 (UTC)

Davidbena -- a random typical JPEG (photograph of a real-world scene, etc.) can't be usefully converted to SVG, but there are special cases. See File:Williamsburg_restroom_sign_cropped.svg for an SVG converted from a JPEG... AnonMoos (talk) 09:02, 15 July 2019 (UTC)

Imperfectly, but sometimes that's better than nothing. See https://en.wikipedia.org/wiki/Wikipedia:Graphics_Lab/Resources/PDF_conversion_to_SVG. SilverbackNet^talk 03:31, 17 October 2019 (UTC)

Accurate/non distorted export of SVGs from Illustrator

Took me a while to find out why this upload of the Wikimedia Space Sticker looks so horrible. You can see the "o"s and the "g"s and the "s"s look very distorted. I finally found the explanation and solution for a perfect result:

This is a common error in .SVG file .. that's because hard curves (curves made with only two anchors and long handles) this cant not be rendered good by the browser.

The best thing to do is to divide your path into smaller segments, specially around the anchor that have the problem.

Just go to Object > Path > Add Anchor Points

— Source: https://graphicdesign.stackexchange.com/a/54171

Leaving it here for anyone who is more familiar with this article to find the right place for this information. --HDothiduc (WMF) (talk) 18:52, 10 September 2019 (UTC)

Seal

Seal Jessie123123 (talk) 00:12, 9 November 2019 (UTC)

Tidying up section links to a user page

Under the Tidying Up section there is currently a link to User:JoKalliauer/Optimization#When_is_optimizing/validating_files_undesired?. I think this should be more formally documented somewhere and discoverable on this help page (I knew I had seen some guidelines on when optimisation is not desired and just spent longer than needed trying to track down where that was on this page). --SilentSpike (talk) 12:02, 28 April 2020 (UTC)

@SilentSpike: I see optimization as to controversal, and it is a trade-of between validating and keeping helpful editor-data for further editing, that everyone has to decide on their own. I think that is a reason why it is difficult to put all aspects to consider in a formally document.

However three points are imho clear:

1. If a file is broken, wrong rendered or problems occour --> validate/otimizate the file (with e.g. https://tools.wmflabs.org/svgworkaroundbot/ )
2. No svg-source-code-edits without visual changes (on foreign files), see User:JoKalliauer/Optimization#svg-scource-code-edits_without_visual_change
3. keep the structure of the existing svgs, see Commons:Overwriting_existing_files (If there are editor-data: keep them, if it is written by texeditor, don't edit in an editor)

If you check the images at User_talk:Thomas_Linard/Archives#removing_rasterdata/optimizing you can see Thomas Linard reduced the file size often dramstically, however they removed hardly visible rasterdata, where you have to know where to look precisely. (Oxygen-icons are made for high-resolution with intentional many high-resulution-details, not for file-size-optimization.)

Bulk-edits such as https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20190405190642&user=Thomas+Linard&ilshowall=1 should imho not be allowed, but fixing files should be enforced.

 — Johannes Kalliauer - Talk | Contributions 05:12, 27 June 2020 (UTC)

Issue when uploading

I made a 1200x800 svg image in Adobe Illustrator but when i upload it, it uploads in 512x341, i tried open it in a browser and it displays at full resolution but when i try upload it does in lower resolution, im am not expert so maybe is a dumb issue but i need help.--Athosmera (talk) 09:34, 19 May 2020 (UTC)

@Athosmera: An SVG does not have a fixed size (technically you can add width and height attributes into the svg tag, but this is not advised) due to the nature of the format (vector graphics which can be arbitrarily scaled). The viewbox of your SVG is presumably 1200x800 and commons is just presenting it as rendered at scale 512x341. This is perfectly fine, you just need to specify the desired dimensions when using the file. --SilentSpike (talk) 15:02, 20 May 2020 (UTC)

Your upload is fine. The file has viewBox="0 0 1200 800", which says it is a 1200×800 virtual image. Commons then scales that image to fit into 512×512 box. That is the "size" that commons reports: 512 × 341; 341 = 512 * 800/1200. Glrx (talk) 22:57, 26 May 2020 (UTC)

Is it possible to reduce size of image after uploading here

Is there any shortcuts to reduce size of wiki uploaded image by means of converting it into SVG or something. A Beginner doubt. Rahulsoman (talk) 21:50, 20 August 2020 (UTC)

@Rahulsoman: If it is PNG/JPEG, generally to convert it to svg; it has to be recreated.

If it is an uploaded SVG, it could be reduced, but that does not make sense, see User:JoKalliauer/Optimization#Optimizing_SVGs_that_have_already_been_uploaded.

If it is not uploaded SVG, you could use e.g. https://svgworkaroundbot.toolforge.org/ , for more options read: User:JoKalliauer/Optimization#How_to_optimize

 — Johannes Kalliauer - Talk | Contributions 20:51, 20 April 2021 (UTC)

Hi Johannes Kalliauer thanks for info. Rahulsoman (talk) 13:38, 24 June 2021 (UTC)

Title of the "Editor" section

The title of this section seems like not contained into a translation tag so I couldn't translate it. I didn't edit it by myself as I have some problems with the numbering. Request to fix it, thanks a lot. -- Vikarna 14:11, 26 January 2021 (UTC)

PNG rendering varies

Main schisms from the Russian Orthodox Church (2021) On that file and others there is a strange thing that I don't understand. It's a svg and the automatic rendering in different sizes treats bold/normal and placing left/right different.

• Click on the image and all is correct
• Click on 1,860 × 1,039 pixels link and one text in left bottom is shifted to the rigth. In svg file it's set to be right centered (begin from right)
• Click on 1,280 × 715 pixels link and the text left bottom is shifted to the left and there is no bold text at all
• I can't understand this as all png rendering should (to my believe) use the same library. Can anyone explain this, thanks. --Goran tek-en (talk) 17:11, 17 April 2021 (UTC)

@Goran tek-en: Thank you very much for your post on my talkpage

Your old image has misplaced text, see e.g. Sept 2006 in the legend or Georgian Orthodox Church (bottom left) in w=1281px which is most likely related to phab:T36947, since you used font-size:3.8806px, see line 249 in [view-source:https://upload.wikimedia.org/wikipedia/commons/archive/4/41/20210420215451%21Main_schisms_from_the_Russian_Orthodox_Church_%282021%29.svg]. However Wikipedia:Wikipedia:SVG_help#bad_letter-alignment_on_small_font-size recommend to use font-sizes above 20px, that's >5 times larger.

If you check [view-source:https://upload.wikimedia.org/wikipedia/commons/4/41/Main_schisms_from_the_Russian_Orthodox_Church_%282021%29.svg] you will see that I use font-size="38.806", which is 10 times larger than the font you used.

And in the result you see that the current file does not have those reported issues, see w=1281px. (Don't forget to purge your cache, to see the current picture.)

If you click on the image, you see the SVG rendered by your lokal browser, not by librsvg, so that's pretty simple to explain. If you choose a specific PNG-size it is rendered by librsvg. librsvg is known to have many bugs. phab:T36947 is one of the most famous ones, which is better explained at Wikipedia:Wikipedia:SVG_help#bad_letter-alignment_on_small_font-size. Normally phab:T36947 is about imprecise letter-distances, however in your example it seems that it has imprecise text-positioning, anyhow for librsvg 2.40 (used by wikimedia) font-size:3.8806px is way too small.

So small-font sizes lead to imprecise rendering, which has different numerical issues depending on the render-size, leading to different unpredictable results.

librsvg >2.50 has many improvements, also relating to this bug (improved but not fully solved), however updating librsvg seems to be complicated, see phab:T193352, another approach would be to change the render phab:T40010, which needs a reevaluation, see User:JoKalliauer/SVG_test_suites for details.

 — Johannes Kalliauer - Talk | Contributions 15:52, 21 April 2021 (UTC)

JoKalliauer Thanks for this explanation but there are some things I don't understand.

• When I check the text "Sept. 2006" in Inkscape it's 14.6666832 px not 3.8806 px as it is in a text editor. Your file say 14.66839027 px in Inkscape and 38.806 px in text editor. I can't understand how it can be different in Inkscape and in text editor (code)?
• Do you change the font-size in text editor and why is it not bigger in Inkscape? There must be some kind of scaling I have no knowledge about.
• We still have the differences between the rendered png's. 1,280 × 715 pixels gives no bold texts. 1,860 × 1,039 pixels gives bold and normal texts. --Goran tek-en (talk) 17:32, 21 April 2021 (UTC)

@Goran tek-en:

I think it is a font-issue, I tried to change it to font-family="DejaVu Sans", which is better distinguishable between bold and normal/regular. (Don't forget to purge your cache, to see the current picture.)

DejaVu Sans needs more space, leading to other issues, I tried to rearrange the text a bit. If it does not appeal you revert it.

Also I sometimes use Inkscape, you somehow explained me, why Inkscape-font-sizes are different to texteditor (I already knew it but I did not know why), so that I can explain you what you explained me. ;-)

You used width="1860.1" height="1038.8" viewBox="0 0 492.15 274.84", however I used width="1860.1" height="1038.8" viewBox="0 0 4921.5 2748.4".

So your svg-file has dimensions 492.15x274.84, and mine has 4921.5x2748.4, so mine is 10 times larger (so in the texteditor I need 10 times your size). However to have a reasonable default preview-size we both used width="1860.1" height="1038.8" which scales it to a reasonable size. Because in the end-result our both images are scaled to the same size we need the same font-size in Inkscape. To have an identical size in inkscape and texteditor you have to set width/height equal to the numbers in viewBox e.g. width="492.15" height="274.84" viewBox="0 0 492.15 274.84" or width="4921.5" height="2748.4" viewBox="0 0 4921.5 2748.4", or just completely remove width="..." height="..." .

 — Johannes Kalliauer - Talk | Contributions 17:59, 21 April 2021 (UTC)

JoKalliauer Thanks for that, I will do some studies on it. I'm a graphic worker and I rely much to what I see in Inkscape. I do some minor things in the code but not much, but I will definitely use this with view-box and what I can see I can do that in document properties. --Goran tek-en (talk) 10:56, 22 April 2021 (UTC)

Problems with left-to-right?

In section "librsvg" it says that "librsvg has problems with left-to-right and top-to-bottom text strings". I am sure it's the other way round and librsvg has no problems with left-to-right scripts like Latin, Cyrillic, or Greek, but with right-to-left scripts like Arabic and Hebrew. user:Glrx mentioned that "confusion about text-anchor with right-to-left text" in discussion "Most major bugs which have been reported to GNOME for years are going to remain as is" above. Love —LiliCharlie (talk) 17:20, 25 June 2021 (UTC)

@LiliCharlie: Good catch, thanks. Glrx (talk) 15:52, 26 June 2021 (UTC)

A new section (3.10.10)?

Lately I use {{Image generation}} which does W3C validation. When I checked some files of "mine" or derived from my work I found when using the Markup Validation Service an unusual error, which I expose and believe deserves a section, as I explain below:

===Error "Text run is not in Unicode Normalization Form C" with W3C validation===

In some old Inkscape SVG files and when validating with https://validator.w3.org/check, the quoted message (of the prior title) may appear.

We explain below through an example (with draw.svg) how it can be solved in Windows.

Assuming Markup Validation Service returns:

  Line 503, Column 39: Text run is not in Unicode Normalization Form C.

  sodipodi:role="line"> القزحيَّ ة </tspan></text>

  [In this case the red character is not allowed. Obviously, other messages may appear]

====Steps====

1. With PSPad:

  Optionally, you can see that line 503 contains:

    sodipodi:role="line">القزحيَّة</tspan></text>

  With file codification: ANSI Western European (1252). But it should have been: Unicode UTF-8 no BOM (65001). To do this, the next step is required:

2. With Windows Notepad:

2.1. Open draw.svg.

2.2. Go to File | Save As..., then in the bottom bar and at the side of "Encoding:", choose "UTF-8 with BOM", then press "Save" button and overwrite draw.svg.

3. With PSPad:

3.1. Reopen draw.svg. Then the line 503 displays

  sodipodi:role="line">القزحيَّة</tspan></text>

3.2. Use the command Encoding | Unicode Normalization | Canonical composition to change characters not allowed.

3.3 Save draw.svg.

Jmarchn (talk) 21:05, 27 June 2021 (UTC)

New section request: Fixing text issue

Hi all

I'd like to add some guidance on fixing a common issue I've experienced with uploading SVG files which include text. However I can't understand how to add text on the page with all the translation tags etc, please could someone add this in for me. This is also possible to do in Inkscape, but I don't know how.

Thanks

== Common text issue with unsupported fonts ==

Wikimedia Commons only supports a limited number of fonts, unsupported fonts are converted and can cause issues especially for graphs and often make the graph look broken with letters in the wrong place and overlapping. To fix this we can convert the font to one supported by Commons or converting the text to paths using a program, e.g Inkscape or Adobe Illustrator

=== Illustrator ===

For individual files

1. Open file
2. Select all
3. Select object > all text objects
4. Type > create outlines
5. Save

=== For multiple files ===

==== Organise files ====

Put all the files you want to do this to in a folder, put no other kinds of files in the folder, otherwise Illustrator will get confused.

==== Record action ====

Click Window > Actions, then create new a action (the plus symbol), then record these steps

1. Select all
2. Select object > all text objects
3. Type > create outlines
4. Click Stop recording action (the stop button

==== Run action ====

Now we have recorded our action we need to run it on the set of files

1. In the Action menu: Click the lines and select ‘Batch’
2. Source, Folder (and chose folder), Destination: Save and close

John Cummings (talk) 13:41, 9 July 2021 (UTC)

This proposed advice is inappropriate.

Diagrams should use well-known (e.g., Arial or Helvetica) and/or CSS generic fonts (e.g., sans-serif). Choosing an uncommon font (e.g., Ubuntu) means that the SVG file may display poorly on any system that does not have that font. Choosing fonts available on Commons does not fix the problem because those SVG files may not display well on Windows or Android systems.

A good practice is to use font fallbacks. For example, font-family="Ubuntu, Arial, sans-serif" or style="font-family:Ubuntu, Arial, sans-serif;". Also leave some extra space for changing font metrics due to scaling or font availablility. If one tightly fits text into a small space, then that text may display poorly even if the exact font is available.

Converting fonts to curves bloats the file size and makes editing and translation more difficult. SVG Translate cannot be used when the text has been converted to curves. It also makes using SVG files more difficult. If I display an SVG file in my browser, I can copy paste text from the SVG file; I cannot copy paste text that was converted to curves.

Commons should not encourage contributors to converts text to curves. SVG files with converted-to-curves text often deserve the {{Path text SVG}} template. Text should be in text elements unless there is an important reason to render exactly the font. For example, Alberta road signs in Category:Alberta Highway shields have a stylized font.

Glrx (talk) 21:37, 9 July 2021 (UTC)

Glrx wrote: "Also leave some extra space for changing font metrics due to scaling or font availablility."

Having seen lots of translated SVGs, I believe the following is also good advice:

Leave as much extra space as possible because translations may be considerably longer than the original texts or labels. Love —LiliCharlie (talk) 22:17, 9 July 2021 (UTC)

Of course one should leave as much space as possible for texts but in practice it's mostly very hard. You want to make the version you are working on as legible as possible and then it's hard to take in consideration a maybe translation. To my experience it's almost impossible to make a translation just by changing texts in a text editor, you as god as always have to view it and make manual edits to the texts for it to work well. --always ping me-- Goran tek-en (talk) 11:34, 10 July 2021 (UTC)

SVG won't load as png

Hello! I uploaded an SVG map today and initially, it did work. I then replaced the image with a higher default resolution, but it had changed the default view for some reason, so I reverted it. Now, the image won't load. Thanks in advance! --DrOwl19 (talk) 18:18, 13 October 2021 (UTC)

The SVG in question

@DrOwl19: you'll probably want to ask this question at Commons:Graphics village pump, as I don't know how many people are watching this page for technical questions like this. For my part, I have no idea why it's not rendering. Commons:Commons SVG Checker doesn't show any problems, but then again, it doesn't check for every bug that exists in the SVG renderer. clpo13_(talk) 18:42, 13 October 2021 (UTC)

@Clpo13: It seems to be rendering now, so I don't know what was happening. Thanks anyway! --DrOwl19 (talk) 18:45, 13 October 2021 (UTC)

@DrOwl19:

The second version that you uploaded confuses MediaWiki with an invalid height attribute:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="1832px" height="px" viewBox="0 0 1832 1416" version="1.1">

For most images, the viewBox attribute should be set and the width and height attributes should be absent (or set to the default of 100%).

Images on Commons are cached, so it may take some time for a recent change to take effect.

Glrx (talk) 23:05, 13 October 2021 (UTC)

Vote for better SVG-Rendering

1. meta:Community_Wishlist_Survey_2022/Multimedia_and_Commons/Improve_SVG_rendering till February,11th
2. w:de:Wikipedia:Umfragen/Technische_Wünsche_2022_Themenschwerpunkte, till February, 6th (German)

 — Johannes Kalliauer - Talk | Contributions 17:44, 31 January 2022 (UTC)

Can't load my svg file

Hi all! I have been making the map for 4 months, and now I have completed it and started uploading it here. I waited 5 minutes, and then Dikwarehouse writes that "This file did not pass the verification procedure." At the beginning of the download, he gave me that this file was already downloading. Tried again - same result. Resaved my file as "plain SVG", tried again - same result. What to do? Tell me please.

P.S.: I want to upload this file in svg format in any case, so that everything is beautiful. The file weight is 239 MB, if that matters.

P.P.S.:I exported this SVG file to a PNG file via Inkscape. I got a PNG file weighing 343 MB. I started uploading this file to Wikimedia Commons. And I managed to download it! Further buttons open in the Download Wizard. So it's not about the file size! And in what? I don't know...Пётр Тарасьев (talk) 16:00, 22 August 2022 (UTC)

@Пётр Тарасьев:

A file that is 239 MB is big. If you were to succeed in uploading it, the renderer may timeout when MediaWiki tries to display it. Only interested users would download such a large file.

SVG file uploads are rejected for a variety of reasons beyond ordinary files. Some possibilities are

• The file contains JavaScript. The presence of a script tag or on attributes such as onload.
• The file has elements in a non-whitelisted namespace.
• The file references a nonstandard DTD.
• The file has a DTD subset.
• The file has external references to images, fonts, or symbols.

See Commons:Commons SVG Checker. Running the file through the checker might be futile due to its size.

Make sure your SVG file is valid.

Glrx (talk) 15:15, 23 August 2022 (UTC)

@Glrx, Thank you very much! I checked my file and there are a lot of errors! I'll post it in PNG format.Пётр Тарасьев (talk) 15:32, 23 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. – Ilovemydoodle (talk) 18:40, 23 August 2022 (UTC)

SVG diff tool

Does anyone know of a tool or userscript out there to show a mediawiki style diff between upload versions of SVG files? VanIsaac (en.wiki) 21:38, 28 January 2023 (UTC)

@Vanisaac: diff of the source-code or of the image

for source-code you might use the commandline-tool colordiff

colordiff <(curl https://upload.wikimedia.org/wikipedia/commons/archive/0/0b/20230108211732%21Jeep_problem_graphs.svg) <(curl https://upload.wikimedia.org/wikipedia/commons/archive/0/0b/20230109090730%21Jeep_problem_graphs.svg)

-- Johannes Kalliauer - Talk | Contributions 19:01, 11 February 2023 (UTC)

Vanisaac -- If an SVG file is edited in a different application than the one in which it was originally made (Inkscape to Adobe Illustrator or vice versa, etc), then ordinary text diffing may not do much good... AnonMoos (talk) 19:01, 14 February 2023 (UTC)

@Vanisaac: . SVG is XML, so an XML diff tool could work. I have never used one. A tool that displays XML (without doing a diff) may be useful. I hand edit SVG files using Visual Studio. It allows me to collapse subtrees. Glrx (talk) 22:13, 14 February 2023 (UTC)

429 error in W3C validator

I can't check svg files in W3C validator anymore – it shows error „429 Too Many Requests”. Does anyone know how to solve this problem? --Obivan Kenobi (talk) 09:38, 13 March 2023 (UTC)

Details? Problems should not require detective work to discover how you triggered the problem.

For File:Exmouth Gulf, LT.svg

I tried https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FExmouth_Gulf%2C_LT.svg&doctype=Inline&ss=1

• The DOCTYPE could not be automatically detected by W3C.
• Error External Checker not available

Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.

The error encountered was: 429 Too Many Requests

I selected DOCTYPE SVG 1.1, and the validator ran.

The XML prolog says standalone="no".

The SVG has the namespace xmlns:osb="http://www.openswatchbook.org/uri/2009/osb". How did you upload the file without triggering the WMF whitelisted namespace check?

Glrx (talk) 17:01, 13 March 2023 (UTC)

Strange that all my previous svg uploads that had a valid code at the time when uploading and later until now, suddenly became invalid even though I haven't touched them. I draw just a simple straight line in a blank Inkscape document and saved it. And when I tried to check it for errors, it cannot be checked as well. So I don’t understand where the problem is: should I upgrade Inscape to a newer version, should I buy a new PC, or should I stop creating svg files because it is not possible without having a programming skills? --Obivan Kenobi (talk) 19:03, 13 March 2023 (UTC)

Apparently, the W3C checker now requires a DOCTYPE processing instruction. See https://www.w3.org/wiki/Validating_your_HTML?TB_iframe=true

In the past, the W3C checker would use the Nu validator when there was no DOCTYPE.

It looks like we now must use the Nu validator explicitly in the templates or files without a DOCTYPE will not validate:

• https://validator.nu/?doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F0a%2FExmouth_Gulf%252C_LT.svg
• https://validator.nu/?doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F1%2F1d%2FFirst_Ionization_Energy.svg
• https://validator.nu/?doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F1%2F11%2FConic_Sections.svg

That requires updating some templates.

Glrx (talk) 19:24, 13 March 2023 (UTC)

{{Valid SVG}} and {{Invalid SVG}}. Editing requires rights I do not have.

|validateurl=//validator.w3.org/check<!--
-->{{#ifexist:File:{{PAGENAME}}|?uri=<!--
-->{{#if:{{{url|}}}|{{{url|}}}|{{urlencode:{{canonicalurl:Special:Filepath/{{PAGENAME}}}}}}}}&doctype=Inline{{#ifeq:{{{opt}}}|>||{{{opt|&ss=1}}}}}}}

Glrx (talk) 19:47, 13 March 2023 (UTC)

In the past, people were basically discouraged from including DOCTYPE declarations in SVG files uploaded to Wikimedia Commons, while including an xmlns="http://www.w3.org/2000/svg" declaration in the opening part of the enclosing <svg element was increasingly insisted upon. Declaring SVG files without "DOCTYPE" to be invalid would affect many tens of thousands of files, and would be a major change... AnonMoos (talk) 16:02, 20 March 2023 (UTC)

Font problem

I translated this map into this one. Then I changed the fonts to "Nazli" which is installed on Wikimedia. The problem is when you open the page, you can't see "Nazli" but when you click on the picture and open to see it in full, the font works. Can anyone help? Yoosef (talk) 08:42, 21 March 2023 (UTC)

Greek characters

Hello, I want to create a map that includes common greek characters α, γ, δ. I want to keep the font editable and don't want to convert it to paths. Is this possible? When I tried to do this the characters are correctly displayed in the final image but not in the preview. Thanks --Furfur ^{⁂ Diskussion} 11:43, 23 March 2023 (UTC)

@Furfur:

Yes, but do not use Adobe fonts such as Symbol. Adobe fonts are not Unicode but rather Adobe-Standard-Encoding or Adobe-Symbol-Encoding. The Greek characters are not at Unicode codepoints, so Unicode fonts will not display the Greek characters. XML files want a single character encoding <XML version="1.0" encoding="UTF-8"?>; they do not expect the character encoding to change for different fonts or different portions of the file. Use the Unicode character encodings.

Glrx (talk) 17:19, 23 March 2023 (UTC)

@Glrx: Thank you for your answer. I reuploaded the file using Unicode font encoding (I did not use Adobe fonts before), but I have the impression that this doesn't help ... --Furfur ^{⁂ Diskussion} 22:17, 23 March 2023 (UTC)

@Furfur:

Your original upload is

• https://upload.wikimedia.org/wikipedia/commons/archive/5/52/20230323004343%21Pure_iron_phase_diagram_%28DE%29.svg

It uses the Adobe Symbol font. Here's why.

It has CSS that says class st13 uses the Adobe Symbol font (font-family:'Symbol'):

	.st9{font-size:18px;}
	.st10{font-size:9px;}
	.st11{font-size:15px;}
	.st12{enable-background:new;}
	.st13{font-family:'Symbol';}

The relevant SVG is

<g id="g2907" transform="translate(-36,0)">
	<text transform="matrix(1 0 0 1 342.7422 495.2297)" class="st12"><tspan x="0" y="0" class="st13 st9">a</tspan><tspan x="11.355" y="0" class="st8 st9">-Eisen (BCC)</tspan></text>
</g>
<g id="g2913" transform="translate(-44,0)">
	<text transform="matrix(1 0 0 1 388.2188 419.4777)" class="st12"><tspan x="0" y="0" class="st13 st9">g</tspan><tspan x="7.4" y="0" class="st8 st9">-Eisen (FCC)</tspan></text>
</g>
<g id="g2919" transform="translate(4,0)">
	<text transform="matrix(1 0 0 1 362.0117 377.4055)" class="st12"><tspan x="0" y="0" class="st13 st9">d</tspan><tspan x="8.895" y="0" class="st8 st9">-Eisen (BCC)</tspan></text>
</g>

Notice that the class="st13 st9" tspan elements use a, g, and d for alpha, gamma, and delta. That's not Unicode.

If your computer has the Symbol font, then it will display as expected, but if your computer does not have a Symbol font, then the characters will probably display as a, g, and d.

You may have also run into some cache issues. Changing a file may not show an immediate change.

Glrx (talk) 23:25, 23 March 2023 (UTC)

All the Adobe fonts have been removed but the preview is still not correct.

The syntax is

.st7{font-family:Liberation Sans,Arial,sans-serif;}
.st8{font-size:18px;}

and

<g id="g2907" transform="translate(-36,0)">
	<text transform="matrix(1 0 0 1 354.0972 495.2297)" class="st7 st8">δ-Eisen (BCC)</text>
</g>
<g id="g2913" transform="translate(-44,0)">
	<text transform="matrix(1 0 0 1 395.6188 419.4777)" class="st7 st8">γ-Eisen (FCC)</text>
</g>
<g id="g2919" transform="translate(4,0)">
	<text transform="matrix(1 0 0 1 370.9067 377.4055)" class="st7 st8">α-Eisen (BCC)</text>
</g>

I don't think that it is a cache issue because the preview is the same in different browsers. --Furfur ^{⁂ Diskussion} 22:09, 30 March 2023 (UTC)

@Furfur:

It looks fine to me; the Greek shows on Commons (which is actually a PNG) and in my browser:

Try going to the File: page and click on a different preview size (such as 1152 × 1024).

• Size of this PNG preview of this SVG file: 675 × 600 pixels. Other resolutions: 270 × 240 pixels | 540 × 480 pixels | 864 × 768 pixels | 1,152 × 1,024 pixels | 2,304 × 2,048 pixels.

Glrx (talk) 02:47, 31 March 2023 (UTC)

@Glrx

Thank you. This file looks fine for me too, but when I move to this page: https://commons.wikimedia.org/wiki/File:Pure_iron_phase_diagram_(DE).svg, I do not see the Greek characters. The PNG previews are all ok. --Furfur ^{⁂ Diskussion} 19:23, 31 March 2023 (UTC)

@Furfur:

File:Pure_iron_phase_diagram_(DE).svg show Greek characters for me. That the other PNG previews work for you suggests that you continue to access an old cached copy of the 675px-wide PNG

• https://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Pure_iron_phase_diagram_%28DE%29.svg/675px-Pure_iron_phase_diagram_%28DE%29.svg.png

HTTP response

Request URL: https://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Pure_iron_phase_diagram_%28DE%29.svg/675px-Pure_iron_phase_diagram_%28DE%29.svg.png
Request Method: GET
Status Code: 304 
Remote Address: (snip)
Referrer Policy: origin-when-cross-origin
access-control-allow-origin: *
access-control-expose-headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
age: 36
content-disposition: inline;filename*=UTF-8''Pure_iron_phase_diagram_%28DE%29.svg.png
content-type: image/png
date: Fri, 31 Mar 2023 21:20:22 GMT
etag: 2a1047d5652b9cee54fc936a6668e5d6
last-modified: Thu, 23 Mar 2023 13:15:40 GMT
nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
server: ATS/9.1.4
server-timing: cache;desc="hit-front", host;desc="cp1090"
strict-transport-security: max-age=106384710; includeSubDomains; preload
timing-allow-origin: *
x-cache: cp1080 miss, cp1090 hit/1
x-cache-status: hit-front
x-client-ip: (snip)
x-content-type-options: nosniff

Glrx (talk) 21:36, 31 March 2023 (UTC)

@Glrx,

ok but how can I delete the cached copy in the Commons? I repeatedly deleted the browser cache and tried different browsers with the same result. Furfur ^{⁂ Diskussion} 15:46, 1 April 2023 (UTC)

SVG is not converted correctly to PNG

File:2-Ethylbut-1-ene.svg looks good on its page in Chrome, but not in Firefox: the lines are too thin. Purge-ing doesn't help, clearing the browser cache and reloading the page doesn't help either. But: when added to a page on a different size than 512px (original) the line-width is correct.

Width: 512 px; lines are too thin

Width: 511 px; line-width is correct (3px)

- Erik Baas (talk) 17:39, 2 April 2023 (UTC)

And... the problem is gone! Don't know how or why... :-) - Erik Baas (talk) 18:22, 3 April 2023 (UTC)

How to access my translated svg image?

Discussion moved here from COM:Help desk#How to access my translated svg image?.

Hello. I've translated the labels on the French image File:Marché noir - importance.svg to English using the svg translate tool, and I know it's saved, because I see it in the history, and also if I set the "render" drop down to English (en), even though the image remains in French, if I click it, it goes here which has the English labels I added. But how do I access that version of it at Wikipedia? I would like en:Black market in wartime France#Proportion of production to show the English version of the chart, not the French one. Background for this is this request. (Previous commons discussion suggested I try here.) Thanks, Mathglot (talk) 08:11, 10 September 2023 (UTC)

Tracked in Phabricator
Task T335361

Tracked in Phabricator
Task T337139

Tracked in Phabricator
Task T337199

Image should display "en" rather than "other".

@Mathglot:

By (parochial) design, WMF wants all images without an explicit language match to default to English.

Although the default clause on this SVG is French, WMF wants to display the English labels.

Since the file has an English clause but no explicit French clause, WMF wants to display English even when French is requested. That can be "fixed" by using SVG Translate to translate the default language to French (identity translation). SVG Translate is buggy here: it should have asked what the default language is and made an explicit entry. I recommend that you do the default to French translation using SVG Translate.

Around April 2023, WMF upgraded Thumbor (the PNG thumbnailer). The upgrade introduced some SVG regression errors — including problems with multilingual files. IIRC, it breaks many non-English default SVG files. Some multilingual SVG files will display no text.

What MediaWiki displays for non-English default SVG

Image	MediaWiki should display	current MediaWiki actually displays
Default PNG URL	English (SVG has explicit English)	French (default)
Forced Klingon PNG URL	English (SVG does not have explicit Klingon)	French (default)
Forced French PNG URL	English (SVG does not have explicit French)	French (default)
Forced English PNG URL	MediaWiki cannot generate this URL	MediaWiki cannot generate this URL

Glrx (talk) 12:27, 10 September 2023 (UTC)

Thank you for this detailed response. I got the gist of it (although not the gory details) and I believe you were suggesting at one point a workaround that might work for me, here:

That can be "fixed" by using SVG Translate to translate the default language to French (identity translation).

What I understood by this, was you suggesting I run svg translate again, "translating" the French labels into French, i.e., by just copying the labels over from the French-named label field on the left into the input field on the right), so that is was I did. I ran svg translate on the image to "translate" it to a new French version, and it seemed happy with that and it uploaded successfully (here). However, everything seems to [mal-]function as before, so either I misunderstood, or there's a missing piece. Thanks for the phab tix links (and update); I'm following T337199 now.

I'll wait while that ticket plays out, but there's still one thing I don't get: namely, the contrasting behavior between this fr⟶en image, and that of another fr⟶en image (File:Judiciary of France.svg, originally: File:Organisation juridictionnelle nationale fr.svg) which I requested help with in February (here), and which TilmannR helped with and successfully found a way to access the English version of the image with my translated labels. To the extent that I understand what happened there, I believe TilmannR created a new image, and we based the label translations on that; so I'm guessing that that was a different type of workaround. Is that something that would be advisable here, or should I just wait for the fix to TT337199? The file is in use at en:Black market in wartime France#Metrics. Thanks, Mathglot (talk) 19:09, 10 September 2023 (UTC)

@Mathglot:

You did fix a problem, but that problem is currently masked by other problems. The problem you fixed will appear on the French wiki when the larger issue is fixed. Before your fix, the SVG file did not have an explicit systemLanguage="fr" (French) translation.

Consider using the file on the French wiki. MediaWiki would believe the SVG file did not have a French translation. MediaWiki has no way of knowing what the SVG default language is. MW does not see any systemLanguage="fr" attributes in the SVG, so it believes there is no French in the SVG. Consequently, MediaWiki would generate a URL for the "default" (aka English) translation:

• https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/March%C3%A9_noir_-_importance.svg/640px-March%C3%A9_noir_-_importance.svg.png

If Thumbor were working correctly, it would run the SVG-to-PNG converter (librsvg) with the (parochial) preferred language of en. The SVG file has English translations (systemLanguage="en"), so the URL would produce the English version of the image. Not what we want for the French wiki.

But Thumbor is not working correctly, so it produces the default French translation, so it looks like it is working on the French wiki when it is not.

With your fix, the French wiki will notice there is a French translation, so MediaWiki will generate the URL for the French version:

• https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/March%C3%A9_noir_-_importance.svg/langfr-640px-March%C3%A9_noir_-_importance.svg.png

With your fix Thumbor will continue to display the French version on the French wiki when Thumbor is fixed.

Right now, Thumbor is broken in such a way that the English translation is never produced from the default URL. IIRC, Thumbor does not set the SVG-to-PNG converter's language preference for a default URL to en, so the language preference ends up being something random that does not match systemLanguage="en". Consequently, the converter always selects the default clause (which is French) and produces French.

A workaround is to change the default clauses to English, but that is not the right thing for a French-named file.

Why does File:Judiciary of France.svg work? Uh, that file does not work either. It has the same problem as the file above. Follow this freshly generated link, and you will see French rather than English translations:

• https://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Judiciary_of_France.svg/2120px-Judiciary_of_France.svg.png

What happened is the last changes to the SVG file were made in March 2023, which is before Thumbor changed. The image is popular enough that many of the PNG files are coming out of the MW cache rather than being run through the (broken) version of Thumbor. The PNG images were rendered before Thumbor changed and have stuck around.

For example, this URL is currently in English:

• https://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Judiciary_of_France.svg/640px-Judiciary_of_France.svg.png

Looking at the HTTP response headers shows a cache hit

Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
Age: 58200
Content-Disposition: inline;filename*=UTF-8''Judiciary_of_France.svg.png
Content-Type: image/png
Date: Sun, 10 Sep 2023 04:02:26 GMT
Etag: 0649d61f0030b08dfd16304509347b03
Last-Modified: Mon, 20 Mar 2023 07:26:18 GMT
Server: ATS/9.1.4
Server-Timing: cache;desc="hit-front", host;desc="cp1078"
Strict-Transport-Security: max-age=106384710; includeSubDomains; preload
Timing-Allow-Origin: *
X-Cache: cp1084 hit, cp1078 hit/1
X-Cache-Status: hit-front

If someone were to purge the cache for the file, then all the English diagrams would be replaced with French versions.

Judiciary of France also does not have an explicit French translation, so French will disappear from the French wiki when Thumbor is fixed.

The problem is bigger than it seems.

Glrx (talk) 20:24, 10 September 2023 (UTC)

Glrx, very illuminating; thanks again. If I understand correctly, we (en-wiki viewers) are more or less at the mercy of events beyond our control, as far as being able to continue viewing the diagram in English at the en-wiki articles which include it, namely, it could spontaneously flip into French at those articles if the cache is purged. This could be very perplexing for editors of those articles, so I've added this brief explanation to the TP of "Jurisdictional dualism" (and linked it from the others) to prevent wasted investigation on the part of other editors. Would you mind quickly reviewing it (link), to make sure I didn't get anything horribly wrong? Thanks for the detailed explanation above; much appreciated. Mathglot (talk) 23:05, 12 September 2023 (UTC)

Your summary is fine. Glrx (talk) 23:49, 12 September 2023 (UTC)

Thanks. Mathglot (talk) 01:27, 13 September 2023 (UTC)