Wikipedia talk:SVG help

How can black boxes have color FFFFFF?[edit]

If black boxes still appear after converting all objects appropriately, it may be necessary to hand-edit the XML to remove any rectangles with color FFFFFF (black), this can be easily done using the search tool of a text editor to locate rectangles or black objects.

In an RGB color model, wouldn't FFFFFF be white, rather than black? So should one look for rectangles with color 000000 instead? 85.23.33.52 (talk) 10:37, 10 August 2008 (UTC)[reply]

Indeed, this is true. Still it's what you do! User A1 (talk) 11:44, 10 August 2008 (UTC)[reply]

SVG Validity[edit]

Commons has two (new?) templates: commons:Template:ValidSVG and commons:Template:InvalidSVG. I just opposed an FPC because of invalid SVG... mostly due to sodipodi / inkspace additions... but, can anyone discuss the importance of validity? Are there certain invalid features which should be accepted? If there are acceptable invalid features then how should those templates be used and are they misleading? (Although Image:Sodipodi-logo squirrel.svg was created with sodipodi and doesn't contain the errors of Image:Caucasus-ethnic en.svg) Thanks --gren グレン 05:29, 29 August 2008 (UTC)[reply]

Hello, here is my two cents:

I am unconvinced of the usefulness of this. I would hesitate to make any decisions purely on the basis of this tag -- what it represents is a very complex analysis of the document, and invalid code should not be considered to be a problem provided it renders as a PNG on wikipedia i.e. through RSVG.

Whilst it is a good fight to ensure interoperability by standards compliance, unless one has the expertise required to fully understand the issues involved, then you should not use this information in decision making. This is probably something that you want to take up with the inkscape developers, if you are of a technical bent. Otherwise marking this up is simply hyping something that people don't understand and compressing it down into a "yes" "no" result, which loses all the context of the arguments. I for one would oppose the use of this tag.

Any appropriate understanding of this "invalid" document would come from an understanding of the SVG specification, as well as how it allows for extensions to the base SVG structure. I am in no position to comment on this.

From a practical perspective, you can probably make these "errors" go away by saving inkscape files as "plain SVG". User A1 (talk) 07:32, 29 August 2008 (UTC)[reply]

From the commons SVG page SVG#Tagging_SVGs: "Unfortunately this validator cannot handle RDF or other metadata, should you wish to include it, but it can still find errors in your SVG. It also wants a Doctype declaration, which is not a requirement in SVG and may actually cause problems." If this is true, then the validator may not be perfect either ^_^ so again, my opinion -- don't use this as a decision making tool. User A1 (talk) 07:38, 29 August 2008 (UTC)[reply]

Thanks. When I originally posted my no at FPC I had only seen 51 errors and not gone through them. When I took a glance most of them seemed to be sodipodi / inkscape elements. My worry about this started when I would see the Media Wiki plugin render PNGs differently than Firefox's SVG support. Some of the cases turned out to be that Firefox had now properly implemented support for some things. Still, it is a general worry of mine that data can be distorted depending on which SVG component is used. I think we do need to come up with better standards for what is 'Wikipedia Valid' but the fact that an SVG made with inkspace/sodipodi gets 50+ errors just from that will make it more difficult track down real issues of SVG compliance. I generally agree with your idea... I have far less of a grasp on SVG validity than I do on HTML validity issues. Thanks for your input. :) gren グレン 08:19, 29 August 2008 (UTC)[reply]

Font issues understated[edit]

The Font issues section addresses the availability of fonts at Mediawiki. It speaks to what is only a symptom of a larger issue. The section says nothing about the need for a referenced font file to exist on a visitor's machine. The presence of a font file at Mediawiki does not guarantee that the file will exist on every visitor's machine. A visitor may be clueless as to why the appearance of text on their screen looks nothing like the preview PNG displayed by Mediawiki. "Substituting the font with an available font" is a Wiki-centric solution. The font may be available at Mediawiki, but it may not be "available" on every visitor's machine.

The list in the Available Fonts page says nothing about how likely a visitor is to have that font installed on their machine. One might gain a false sense of security when picking a font from that list, expecting every visitor to see the font as intended. If it shows up as expected in Mediawiki's PNG preview, the creator of the SVG image may have no reason to suspect that their image will appear as anything other than what their machine and Mediawiki's preview PNG have shown them.

In images where the appearance or placement of text is important, there may be significant portability issues if one chooses to use an SVG image instead of a raster image. -Ac44ck (talk) 19:33, 15 January 2009 (UTC)[reply]

Whilst this is indeed true, I would expect that fewer people actually look at the SVGs, and instead probably only look at the pre-rastered images. User A1 (talk) 00:49, 16 January 2009 (UTC)[reply]

Perhaps so. Then wholesale conversion of images from PNG to SVG for those exceptional cases would seem to be largely wasted effort. And server space would seem to be wasted by the only-used-once files being stored along with the multiple rasterized previews made therefrom.

I tweaked the text in the article again to mention the possibility that it isn't a concern in some cases, but remains a PITA in others. My first attempt to upload an SVG image to Wikipedia got me PO'd. That the vectors scale so well is seductive. Finding that the text handling can be unpredictable was an unwelcome surprise. If someone finds this page (which I didn't know existed) before they try making an SVG image — and they find this caveat in the sea of other text here — then they might be forewarned. - Ac44ck (talk) 01:46, 16 January 2009 (UTC)[reply]

I understand and appreciate the situation, I think the current wording that you have inserted is quite good and explains the situation clearly. As an aside to other users who may not be familiar with our discussion -- all Mediawiki fonts are freely available, and can be downloaded. (I don't say where from :) ) 'nix users probably have them all by default. User A1 (talk) 03:24, 16 January 2009 (UTC)[reply]

Previewing[edit]

IIRC the uploader doesn't include a preview. Although unlikely, the situation could arise where an editor has access to an SVG file, but no means to preview it before uploading, e.g. an outdated browser. Therefore, is it worth including a link to this online SVG to PNG image conversion utility? --trevj (talk) 12:44, 11 March 2011 (UTC)[reply]

That would only really be useful if they were running the same software setup that we are. The Commons solution is commons:Commons:SVG Check... AnonMoos (talk) 19:47, 11 March 2011 (UTC)[reply]

Template talk:Should be SVG#Vector data[edit]

I would like to make you aware of my proposal. --Leyo 09:37, 18 June 2011 (UTC)[reply]

Confusing: "font-family="Liberation Sans,Arial,Helvetica,sans-serif"[edit]

In the font family issues subsection, mention of font-family="Liberation Sans,Arial,Helvetica,sans-serif" is confusing in context, as it contains Arial and Helvetica which are not part of acceptable SVG fonts. Is this recitation a mistake, or does it require more explanation? —RCraig09 (talk) 19:11, 3 March 2020 (UTC)[reply]

@RCraig09: There is no font family issues subsection, either here or at Wikipedia:SVG help. --Redrose64 🌹 (talk) 23:29, 3 March 2020 (UTC)[reply]

Sure there is, at Wikipedia:SVG_help#font-family_issues, in the second bullet point. --{{u|Mark viking}} {Talk} 23:39, 3 March 2020 (UTC)[reply]

So the subsection isn't font family issues at all, but font-family issues. Punctuation is critical. --Redrose64 🌹 (talk) 08:07, 4 March 2020 (UTC)[reply]

The text concerned was added by JoKalliauer (talk · contribs) in this edit. --Redrose64 🌹 (talk) 08:14, 4 March 2020 (UTC)[reply]

@RCraig09 and Redrose64:

On Wikimedia Arial and Liberation Sans is rendered identical (With Liberation Sans), see File:SVG_Text_Font_Test.svg, therefore they are kinda "synonyms".

It is better to specify a font available on Wikipedia (such as Liberation Sans) with fallback fonts such as: font-family="Liberation Sans,Arial,Helvetica,sans-serif", in which you define similar fonts that are available on Wikimedia, Windows, Linux, or Mac.
— Wikipedia:SVG_help#font-family_issues

Liberation Sans is for Wikimedia&Linux
Arial is for Windowsusers (in most cases they do not have Liberation Sans)
Helvetica is for Mac-Users (I think they neither have Arial (copyright-protected) nor liberation Sans))
sans-serif is used if you do neither have "Liberation Sans" nor "Arial" nor "Helvetica"

fallback-fonts are important otherwise it will look in your local Browser-rendering completly different, and they do not affect Wikimedia-rendering.

On c:Help:SVG#fallback you find a more detailed explantation. (with the recommendation to replace Arial with font-family="Liberation Sans,Arial,Nimbus Sans L,Helvetica,sans-serif"

— Johannes Kalliauer - contrib. 09:10, 7 March 2020 (UTC)[reply]

Vielen Dank! Es ist jetzt deutlicher. Henceforth, I plan to use font-family="Liberation Sans,Arial,Helvetica,sans-serif" instead of font-family="Liberation Sans,sans-serif". —RCraig09 (talk) 15:28, 7 March 2020 (UTC)[reply]

Bad rendering of Liberation Serif[edit]

An oddity I have just found: I used Liberation Serif for a text on one SVG file, and while it appears perfectly rendered in Commons, on en:Wikipedia the text shoots off the image. Others I did in the same way seem all right. The image is File:Battle of Lake Trasimene, 217 BC.svg, appearing here. The same is apparent with File:Battle_cannae_destruction.svg appearing here: perfect rendering when you look at the image on its own, but one line shooting off the end when embedded in the article.Hogweard (talk) 08:35, 2 September 2020 (UTC)[reply]

@Hogweard: This is the Talk page for SVG help: you need to move your question to the actual page to get help. I can't see any problem with your file in the article. Try clearing the cache in your browser, as I had this sort of issue from my browser refusing to update previous cached versions. Michael D. Turnbull (talk) 14:59, 7 October 2020 (UTC)[reply]

@Hogweard: Font renderings in SVG files are an ongoing problem (example). See https://en.wikipedia.org/wiki/Wikipedia:SVG_help#font-family_issues for an overview. In my case, at least, clearing the cache does not work in many instances. Items to consider are the font size in the original SVG file (bigger is better), and the value of upright=_._ in Wikipedia articles. —RCraig09 (talk) 17:01, 7 October 2020 (UTC)[reply]

Vote for better SVG-Rendering[edit]

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

— Johannes Kalliauer - Talk | Contributions 17:39, 31 January 2022 (UTC)[reply]