Wikipedia talk:SVG help

How can black boxes have color FFFFFF?

At Wikipedia:SVG Help#Rendering files,

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)

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

SVG Validity

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)

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)

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)

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)

Font issues understated

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)

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)

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)

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)

SVG Logos

Can fair-use logos on Wikipedia be in SVG? Thanks. Leujohn ^(talk) 12:45, 10 February 2009 (UTC)

This has been the subject of some debate in wikipedia, with no clear consensus either way, but the general feel is no there shouldn't be fair use SVGs. This is due to the fact that SVG provides infinite scalability, and thus is not fair-use worthy.

As a contrived example, if it were allowed, one could use autotracing of any non-free logo at a large scale (to minimise algorithmic errors), then shrink down the default SVG presentation to small scale -- which would effectively allow arbitrary sizing of these logos, at a rate as fast as you can chuck the non-free logos into your tracing program.

For the record, I am in favour the removal/replacement of non-free SVGs. However if you wan't to remove existing fair use SVGs, you may have to engage in some lengthy debates.

Some various bits of reading:

• Mailing list User:Zzyzx11 on fair use images
• Wikipedia_talk:Non-free_content/Archive_18#Conversion_to_SVG_and_fair_use

User A1 (talk) 13:43, 10 February 2009 (UTC)

The first link above is particularly interesting: User:Zzyzx11 states that he has been "quietly making some unilateral additions to WP:IUP and WP:FUC" to deprecate fair-use SVG logos. But none of the changes have stuck. That strongly suggests there was not consensus that they were required.

Some further, more recent discussions on this issue (as somebody says in one of them the topic comes up about once a year) can be found eg here (WT:IUP, July 2009), here (WT:NFC, December 2007),here (WT:NFC, January 2009) or here (WT:NFC, June 2009)

The current (longstanding) position seems to be that there is no consensus to remove non-free SVG logos (and some argue strongly that there are reasons to prefer them).

On the other hand, there is consensus to deprecate bad image conversions to SVG. (See eg this discussion, WT:NFC, February 2010). Jheald (talk) 17:13, 14 March 2010 (UTC)

Note that if files were previously released in vector format (prior to the existence of the SVG format), then I see no reason why they should not be converted to SVG. For example, such files may have been created with software listed at List of vector graphics editors. --trevj (talk) 11:13, 11 March 2011 (UTC)

Some thumbnails are garbled

Present Librsvg version (as of 2010-02-16) renders some Wikipedian thumbnails erroneously:

If I had to guess, I would say that there is an integer conversion happening when the glyph size is being computed, resulting in the text being far too large. Did you want me to play with the SVG to see if there is something I can do? Or are you happy just to leave it on this talk page ? User A1 (talk) 12:04, 16 February 2010 (UTC)

I didn't understand your question for 100%, but you are free to play with separate copy of this SVG. Please do not change the version which appears in the article: I'm pretty sure that the problem in graphic engine must be fixed, not the picture itself. By the way, Opera refuses to display this SVG image correctly: it renders something ca. 5 minutes taking 99% of CPU time, then displays boxes without labels.

The SVG image's thumbnail

BPK (talk) 21:35, 16 February 2010 (UTC)

Arial

Given that we have Helvetica available in the SVG fonts lists, why then are we using Random Sans to substitute for Arial in SVGs originated on OpenOffice, rather than Helvetica, which Arial was purposely created to be drop-in interchangeable with? This seems to completely break up detailed formatting (eg in diagrams), in a way that is completely unnecessary.

Come to think of it, why is the formatting being broken up just so badly? I could understand a certain amount of mis-kerning as a result of the metrics not quite matching, or a bit of overflow, but instead given an unknown font, our SVG interpreter seems to just dump the text at the left margin.

This seems a completely unnecessary fail by the SVG interpreting software. Can it not be configured to fall through a bit more gracefully? Jheald (talk) 16:53, 14 March 2010 (UTC)

The odd thing is, having fixed the broken images, by replacing the characters with paths,

• File:Fold bifurcation.svg
• File:Cusp catastrophe.svg
• File:Cusp shape.svg
• File:Pitchfork_bifurcation_left.svg

having done all that, I now find that, if I look at the old versions of the images, OpenOffice had actually provided encapsulated information for each of the characters used -- i.e. it had actually given full path information for each character in the file.

So whether on "free software" grounds the wiki software actually had the full fonts or not is completely irrelevant: the information it needed was actually given (as the copyright on these fonts allows) in the file all the time.

All this blather about copyright fonts is just so much hot air: what we really have here is a bug in the rendering software, plain and simple. Jheald (talk) 18:48, 14 March 2010 (UTC)

There are two problems here (1) should wiki allow embedded fonts? Probably (2) Is it technically supported, maybe not. Pragmatically, just use something like DejaVu sans, and you will not have any problems. No embedding required as the target machine has the font. Neater SVGs for all. I have not studied the Arial or helvetica licences (though I ran a quick search, but turned up nothing) to see whether font embedding is allowed, and how redistribution is to be done, nor am I in charge of any wiki servers :). Feel free to raise this somewhere more likely to get a response, such as the librsvg bug page. User A1 (talk) 22:23, 14 March 2010 (UTC)

The URW version of Helvetica supplied with Ghostscript, that WP has on the server, is as far as I am aware completely free software -- re-usable in any way anyone likes.

As for Arial, according to Microsoft the legal embedding rights can be found expressed in the embeddability bits in the font file. ([1] "Can I embed Microsoft fonts in my documents?"). For Arial, the permissions indicate "editable" -- the second highest level of permission -- meaning that the font can be embedded within content that can be edited by the user. Therefore yes, such use does seem to be entirely licensed and legal.

(In earlier days, these bits weren't always set accurately, so much software - including some versions of Adobe Distiller - simply ignored them. Agfa Monotype brought a famous case against Adobe, claiming that ignoring the bits breached the DMCA. But the courts held that the bits were just flags, and did not "effectively control access". [2] It seems also that Agfa could not assert that the software fell foul of "contributory infringement", since it had significant bona-fide applications. Nevertheless, none of that gives a user the right to embed a font that hasn't been licensed to be embeddable. However, at least according to its own font file, Arial has been licensed (from Monotype by Microsoft) to be embeddable. Which was our concern here).

On the technical side, we can conclude there currently seem to be (at least) two bugs:

(1) where fonts have been embedded, the libsvg software is not picking up the paths that are explicitly included in the file for glyphs from the embedded font -- or at least, it is not able to pick them up in the format that OpenOffice (as of 2005) saved them.

(2) even when the font name is identified as Arial, the software is not falling through to substitute for it with Helvetica (a much nearer match than DejaVu sans).

(3) whatever font it is that it is defaulting to, the software seems to be losing all the positioning information.

(librsvg bug 525023 ? See also others listed at Proposal:Librsvg_development_funding) Jheald (talk) 10:19, 15 March 2010 (UTC)

But you're right, there are more productive places to raise this -- indeed I think it may even be one of the longer standing wished-for fixes on the MediaWiki open issues board. Jheald (talk) 00:49, 15 March 2010 (UTC)

These problems would go away if we used Inkscape for our rendering, rather than the (essentially moribund) libsvg. Jheald (talk) 10:38, 15 March 2010 (UTC)

I like the inkscape renderer solution, but it depends on who is writing the wiki-scripts. It isn't me :) User A1 (talk) 21:04, 1 June 2010 (UTC)

Previewing

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)

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)

How to test SVG locally?

How to test SVG locally with the same SVG vector to raster engine as in Wikipedia before uploading it to Commons. I uploaded SVG which has no problems with Opera 11, IE 9 and FireFox 3.6.9. Wikipedia's rasterization software renders this image with some unwanted objects. I need to determine whether it is an SVG file bug or engine bug.BPK (talk) 00:30, 8 June 2011 (UTC)

Although not exactly "local", the SVG Check tool should solve your problem. Alternatively, you could try installing and running rsvg, which is the renderer used by MediaWiki. —Quibik (talk) 09:47, 8 June 2011 (UTC)

This looks strange: when I upload my SVG to online SVG check tool, everything looks fine. It goes close to testing the picture with librsvg. Assume that I managed to build the library. How to make practical use of it? (I'm running Windows). By the way, I'm talking about this image BPK (talk) 18:14, 10 June 2011 (UTC)

I did not find rsvg directly in my Ubuntu system. It turned out to be within apt-get install librsvg2-bin. But I had found the librsvg2-2 library it uses and listed its reverse dependencies. If you use a program in it, it uses the same code to render an SVG, and, for example, libreoffice is equivalent to rsvg.

$ apt-cache rdepends librsvg2-2 | sort | uniq librsvg2-2 Reverse Depends: aisleriot aterm aterm-ml cairo-clock cairo-dock-core cairo-dock-plug-ins compiz-plugins darktable denemo emacs23 emacs23-lucid eog fvwm gambas2-gb-gtk-svg gbrainy gcompris gdesklets gimp gir1.2-rsvg-2.0 glchess glines gnobots2 gnome-panel gnome-system-monitor gnomine gnotski gstreamer0.10-plugins-bad gweled gwibber iagno libabiword-2.9 libafterimage0 libccss-1-5 libevas1 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-0:i386 libgegl-0.0-0 libgldi3 libhippocanvas-1-0 libimage-librsvg-perl libjava-gnome-jni liblablgtk2-gnome-ocaml libmagickcore4-extra libmono-system-windows-forms4.0-cil libmono-winforms2.0-cil libopenscenegraph80 libreoffice-core librsvg2-2.18-cil librsvg2-2:i386 librsvg2-bin librsvg2-common librsvg2-dbg librsvg2-dev libswami0 logjam mahjongg mate-control-center mate-panel mate-system-monitor mdm mistelix mldonkey-gui moblin-icon-theme monkey-bubble netsurf-gtk performous pike7.8-svg python-libavg python-rsvg quarry ruby-rsvg2 tryton-client tuxmath tuxpaint tuxtype vlc-plugin-svg xfce4-xkb-plugin --A Pirard (talk) 20:13, 15 October 2013 (UTC)

Template talk:Should be SVG#Vector data

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

Help deleting preliminary uploads

I am using Adobe Illustrator 10 which does not display SVG images the same as when uploaded to Wikipedia. I made a number of changes to File:MaxwellEqArea.svg on the commons, uploading each change which looked good in Illustrator, but not on Wikipedia. I finally got it right, but I think the intermediate files should be deleted, and I do not know how to do that. PAR (talk) 23:19, 11 January 2012 (UTC)

You can post your request to commons:Commons:Administrators'_noticeboard and a Commons admin will delete them for you. By the way, if you need a place for testing for future uploads, File:Test.svg is a file on Commons set aside for testing purposes. Cheers! -- Orionist ★ talk 00:23, 12 January 2012 (UTC)

You can also use the commons:Commons:SVG Check tool. I was having the same problem as you, and found that tool to be a lifesaver. Antony–22 (^talk⁄_contribs) 07:31, 12 January 2012 (UTC)

Thumbnail render blurry

Median personal income for the population age 25 or older.

I have been working on recreating some old graphs as SVG charts (using matplotlib). This is working great, except the thumbnail images of the graphs are very blurry, especially the fonts. If I render a png at the same resolution using matplotlib or Inkscape, I get a very clear image. Is there any way to fix this? It looks so bad I'm tempted to just upload my 300px thumbnail and link it in the article instead :(

See the thumbnail on the right. For comparison, here is the version I rendered at 350px. Quasar (talk) 15:12, 9 May 2012 (UTC)

Why did you convert the text into paths? --Leyo 21:32, 9 May 2012 (UTC)

Ahh, that may be the main issue. This is the direct svg output from matplotlib (a plotting/graphing library for python), I will see if there is a way to get it not to do that. Quasar (talk) 01:45, 10 May 2012 (UTC)

Why haven't thumbnails been updated?

I've just created a prettier version of the image on the left but for some reason some thumbnails/PNG versions haven't been updated. I'm guessing this is something that should happen automatically as I've not managed to find much about it. Any comments/hints appreciated! Thanks, Smason79 (talk) 11:49, 29 June 2012 (UTC)

This is a caching problem, which can occur anywhere from the Wikimedia server to your own local hard drive. You can try "purging" the server image and reloading in your browser... AnonMoos (talk) 20:33, 29 June 2012 (UTC)

I should have noted that I'd tried clearing the cache in my browser and reloading. Thanks for the pointer to purge, but I'm not sure what should be purged? I tried the image page and one of the thumbnails, but neither appeared to have any effect (the purge action disappeared from the URL, so I doubt it's me mistyping and should have been recognised by the server). Smason79 (talk) 10:45, 30 June 2012 (UTC)

Just checked again and the images seem to have corrected themselves. Still unsure whether next time I should be patient or if it's a manually triggered event. Smason79 (talk) 15:31, 1 July 2012 (UTC)

To AnonMoos – From the client side, how do you signal the Wikimedia server or any other servers along the way to "purge" their images? I've sometimes waited for over a week for "the" cache to clear. All I know for sure is that it's not my client-side. Stigmatella aurantiaca (talk) 07:26, 26 July 2012 (UTC)

If you go to directly to the Wikimedia Commons image description page, on most skins there should be a "purge" link or tab, or you can add "&action=purge" / "?action=purge" (depending on context) to the URL... AnonMoos (talk) 16:58, 26 July 2012 (UTC)

Undesirable tinted backgrounds

SVG images in some display templates have undesirable tinted backgrounds. For example Template:Multiple images. On the German Wikipedia, standard thumbnails have this same rendering flaw. A friend of mine uploaded modified versions of two of my images to de:Kennedy-Thorndike-Experiment and I was upset at the rendering, so I set about to do a kludge, which I first tested out on Template:Multiple images.

For each image I added a new layer below the main layer and locked the main layer to prevent accidents. Switching to the lower layer, I added a borderless rectangle and sized it to exactly match the width and height of the image, then changed its fill color to white.

If you analyze the versions of my images on de:Kennedy-Thorndike-Experiment, you'll see this kludge applied. I'm sure there must be an easier alternative than an SVG expert could point out to me, but meanwhile, this kludge worked. So my question is, is there a simpler alternative to this kludge?

Thanks, Stigmatella aurantiaca (talk) 07:15, 26 July 2012 (UTC)

It would be more convenient if you could directly link to examples of images which you consider good and bad... AnonMoos (talk) 17:00, 26 July 2012 (UTC)

Kludged SVG image with extra white layer

SVG image without the kludge

Also compare Figure 2. A depiction of the concept of the "aether wind" in en:Michelson–Morley experiment versus the German-language version in de:Michelson-Morley-Experiment. Stigmatella aurantiaca (talk) 01:10, 27 July 2012 (UTC)

One thing that could make things simpler is if I am allowed to make the white rectangle any size I want, rather than trying to be exact about not spilling over the borders of the image. Am I allowed to do that? Stigmatella aurantiaca (talk) 07:10, 27 July 2012 (UTC)

I'm afraid this is more a matter of principle here (that could be easily resolved technically though):

• First of all, what you are doing Stigmatella aurantiaca, is removing transparency from those SVGs. This is very bad in my opinion. A good SVG is designed that it works on all sort of backgrounds – the transparency can be wisely chosen to improve the SVGs visual appearance. This should not be done if not totally necessary.
• The downside: if the SVGs author did non consider tinted (as you are complaining) or other colored backgrounds this can lead to the appearance being not optimal (e.g. the tinted background shining through at places where it might seem inappropriate.

Now there are two possibilities:

1. Improve the SVG (which should be done wisely and not only by removing transparency completely for the reasons lain out above).
2. Resolve the issue technically here on Wikipedia by changing the templates you mentioned to show a white background by default. E.g. on English Wikipedia in article space images are given a white background by default (it's done by a simple entry in common.css if I remember correctly). The template you used above could be adjustet appropriately. On German Wikipedia the default tinted background is used though (but could be changed by CSS, too, so if you want this to be changed you'd have to tdo a request there).

--Patrick87 (talk) 14:34, 3 October 2013 (UTC)

I created a request to change Common.css to fix the lacking styling of the template you mentioned here. --Patrick87 (talk) 15:35, 3 October 2013 (UTC)

Thanks! Stigmatella aurantiaca (talk) 19:19, 3 October 2013 (UTC)

Uploading SVG images from IP editors

I am preparing an article to reach the FA-class. I have created a flowchart to replace an outdated one. The outdated flowchart is the last one in SVG format. I would like to keep one SVG diagram at least, but I am unable to upload the new file. I have checked the file with the SVG Check tool, so further updates are not expected. Is there any chance that such an image from an IP editor could be uploaded? 84.127.80.114 (talk) 19:22, 23 July 2014 (UTC)

Sorry for belated reply. I suppose you could e-mail the SVG file to somebody who would upload it, but it would probably be easier for everyone all around if you just signed up for a Wikipedia and/or Wikimedia Commons account... AnonMoos (talk) 16:42, 13 August 2014 (UTC)

The IP provided the source in its diff. Alternatively, source is at Talk:Debian#Development flowchart. I think it would be better to obtain a Commons account (one account name can cover all projects) and learn how to upload the image. That way, if you wanted to modify it later, then you could do that, too. Glrx (talk) 17:19, 13 August 2014 (UTC)