Template talk:Vector version available

Linking to commons images

This template does not work when linking to images on Commons directly as the Image: prefix is already set. Please change this so that vector versions on Commons can be linked correctly (e.g., :Commons:Image:Vector image.svg). (Forgot to sign --Geopgeop 07:04, 1 July 2006 (UTC))

Proposed merge

I'm not opposed to merging the two templates, but I'd like to use the {{SVGNowAvailable}} design because it looks better. El T 15:25, 25 August 2006 (UTC)

Thumbnail problems

The display of a thumbnail of the replacement image does not seem to be working. AnonMoos 21:55, 20 October 2006 (UTC)

I don't think it was my edit, I just removed the merge tag. But this is an odd problem, it appears inconsistent. For example, while Image:Hyperbola one over x.jpg doesn't render the new image, Image:HSV RGB Comparison.png does. Ideas? --ChrisRuvolo (t) 00:18, 21 October 2006 (UTC)

Problem fixed. Peter O. (Talk) 01:56, 21 October 2006 (UTC)

Looks good, thanks. --ChrisRuvolo (t) 03:47, 21 October 2006 (UTC)

Proposed merge

I suggest merging Template:SupersededSVG into this template.

Template:SupersededSVG seems to be a parallel to commons:Template:SupersededSVG (ironically, there is a similar conflict between it and commons:Template:Vector version available), but I see no reason to use both. Unless I am mistaken, they perform the same function: notifying visitors to an image's description page that an SVG version of that image is both available and preferable. I understand that the Superseded template might be used to indicate a stronger conviction that the SVG is superior, but I believe the phrasing of Vector Version Available (i.e. "should be used in place of this raster image whenever possible") fulfills this purpose as well. Furthermore, Template:SupersededSVG is not as widely used and does not add tagged pages into the appropriate category, as this template does.

On the other hand, I prefer the look of Template:SupersededSVG, and I believe the insertion of "Note: this file will not be deleted, unless it is explicitly nominated for deletion" is a wise choice. If possible, I believe those aspects of Template:SupersededSVG should be included in this template. MithrandirMage 16:46, 19 March 2007 (UTC)

• Agree. The merge seems just logical. — Isilanes 19:37, 10 May 2007 (UTC)
• Agree --Froztbyte 15:50, 20 October 2007 (UTC)
• Agree per rational. +mt 20:05, 29 October 2007 (UTC)

Move?

Should this template be moved to "Template:SVG version available"? I think "SVG" version available sounds better than "Vector" version available. --98E 22:31, 24 April 2007 (UTC)

Category renaming

The related Category:Images made obsolete by an SVG version has been nominated for deletion, merging, or renaming. You are encouraged to join the discussion on the Categories for Discussion page.

This template currently automaticly populates the category Category:Images made obsolete by an SVG version. The new suggested name for this category is Category:Wikipedia images available as SVG. See discussion links in the box above. --David Göthberg (talk) 07:20, 1 April 2008 (UTC)

The renaming has been done.

--David Göthberg (talk) 13:56, 7 April 2008 (UTC)

Image

This template should not include the image of the picture, as it is sometimes used on non-free content, such as Image:Projectrunwayaustralialogo.JPG, and thus in breach of WP:NFCC Fasach Nua (talk) 12:55, 11 September 2008 (UTC)

Let's see: So you say it is a problem that we show the same image a second time on the image page is a problem when it is a fair use image? (Well, in another format, but the same design.) Well, then isn't it already a problem that we show the image the first time on the image page?

Of course, if it indeed is allowed to show the image the first time but not the second time, then we can add an option that tells the template to not show the image. (We still need to feed the image name since we need to link to the new image.) Perhaps something like this:

{{vector version available|New image.svg|image=off}}

But then again, we should not make SVG images of fair-use logos and similar, since then they can be scaled up to any size and that breaks the fair-use rules. So really, we should instead delete Image:Project-runway-australia-brand.svg and keep the Image:Projectrunwayaustralialogo.JPG. (Well, make a smaller, better and transparent png would probably be better.)

So in fact, this template should never have to be used on fair use images, since fair use images should not be made into SVGs.

--David Göthberg (talk) 13:59, 11 September 2008 (UTC)

Is there anyway for the template to "know" if it is on a page in a category that contains the text "non-free" ? Fasach Nua (talk) 14:48, 11 September 2008 (UTC)

No, there is no way for the template to figure out if it is on the same page as a "non-free rationale" tag. Well, there are some really nasty CSS hacks we could use to make it or the "non-free rationale" tag show differently (different colour or even a warning message) if they are placed on the same page. (The one that is below the other can change appearance with those tricks.) But no way we can make them for instance report the problem by adding the page to some category.

Also, there is currently no way a template can check what file ending a page has. That is if a non-free license tag is placed on a page ending with ".svg" we can not detect that either.

What we can do is to have some bot watch if pages turn up both in Category:All non-free media and Category:Wikipedia images available as SVG at the same time. And check the names of pages in Category:All non-free media and report if any of them end in ".svg".

But it seems you asked this in the first place because of that someone made an SVG version of Image:Projectrunwayaustralialogo.JPG and then put {{vector version available}} on the JPG and then marked the JPG for deletion. And in cases like this the admins who are asked to do the deletions are supposed to know enough that they know to instead delete the SVG image. I have left a comment about that at the JPGs entry on the Images and media for deletion page.

So really, all this is not a problem. It is just that user who made the SVG who didn't know how it works with fair-use images, and that user will now learn how it works.

--David Göthberg (talk) 16:22, 11 September 2008 (UTC)

That is not correct, fair use SVG images are allowed. See {{SVG-Logo}} and Category:Vector images of trademarks. This has been hashed out in many discussions already. --ChrisRuvolo (t) 16:17, 12 September 2008 (UTC)

ChrisRuvolo: Have you read what {{SVG-Logo}} says? It says: "Due to the difficulty of creating an SVG logo that meets Wikipedia's non-free content criteria it is generally not advisable to create original vector versions of logos."

And that template links to Wikipedia:Non-free content#Policy 2 which is a guideline and at point 3 b states: "Minimal extent of use. ... Low- rather than high-resolution/fidelity/bit rate is used (especially where the original could be used for deliberate copyright infringement). This rule also applies to the copy in the Image: namespace."

The problem with SVG images is that they can be scaled up to any size, and thus misused. That is, fair-use should not use too high resolution images, and SVG images have infinitely high resolution. That is, the "difficulty" we have with making SVGs that fulfil our non-free criteria is that there is no way to lock an SVG to only show in some maximum resolution.

The case that Fasach Nua brings up above is that someone remade a logo that was in JPG format to be in SVG format. Which as {{SVG-Logo}} states is "generally not advisable". And we already had the JPG so we really didn't need the SVG. Although the SVG did look better. So I used the SVG to make a good but reasonably sized PNG instead: Image:Project runway australia logo.png. As I explained above it is very questionable to use SVGs for non free images, especially since we so easily can take the SVG and make a PNG of it, thus locking the maximum resolution of the image. (And since the PNG was better than the JPG I changed the article to use the PNG, and then I had to delete the JPG and SVG since we may only keep a non free image if it is used in an article.)

--David Göthberg (talk) 01:23, 13 September 2008 (UTC)

Ah, so the contention is "making" the logo, not uploading existing EPS logos as SVG. Sorry if I misinterpreted. BTW, the resolution issue is not something that is enshrined in copyright law, but was rather a way to have Wikipedia use only the "minimal portions" of a copyrighted logo for identification under fair use doctrine. That doesn't apply to SVG. Although SVGs can have infinite resolution, they can't always have infinite detail, which would be an analogous way to deal with the issue. Cheers. --ChrisRuvolo (t) 21:05, 15 September 2008 (UTC)

ChrisRuvolo: I am not sure what you mean. I certainly would not take the Encapsulated PostScript (EPS) original of a logo from a company, convert it to a SVG, and then upload it to Wikipedia. I am pretty sure that would not count as fair use since that would retain almost 100% of the detail from the original. But I would consider using the EPS original to create a reasonable resolution PNG image, and then upload that PNG image instead. And right, a SVG with sufficiently little detail is probably legal to use as fair use. But with SVG it is very hard to tell what is sufficiently little detail. With a PNG it is much easier. So I don't see why we should not convert any "fair use SVG" to PNG, instead of the other way around.

--David Göthberg (talk) 22:28, 15 September 2008 (UTC)

I disagree, An officially sourced EPS is the official logo, and true to trademark law, we must provide an accurate representation. The conflict here is between the desire to use the "minimal portion" of a work and to have an accurate trademark representation. There is no clear delineation point as to what qualifies as a "minimal portion", so we have to fall back on trademark use and thus the most accurate rendering (the full-detail SVG). Also, why would the company provide the EPS for use unless it was for proper brand identification? It could be argued SVGs are more valid than a PNG for trademark use, since they are the most accurate representation. As such, there is no need to covert properly sourced fair use SVGs to PNG. --ChrisRuvolo (t) 20:30, 19 September 2008 (UTC)

Added reasoning

I changed the text of the template so that it now reads:

A [[:Image:{{{1}}}|vector version of this image]] is also available, and should be used in place of this raster image where the raster image contains information that could be stored more efficiently and/or accurately in the SVG format, as a vector graphic. (new text in italic)

I used the approved language at Template:ShouldBeSVG. In any event, this template needs to carry with it some reasoning behind the replacement suggestion. Please do not delete the reasoning I posted but feel free to replace it with any more correct reasoning. Thanks. -- Suntag (talk) 15:31, 11 September 2008 (UTC)

Okay, I guess it is time for me to ramble a little:

1: About the attribution path: I wrote that. Right, when an image is based on another image here you can not just delete the old image. But all you have to do is to first copy the attribution information from the old image to the new image, then you can delete the old image. But people tend to be sloppy with that. And that is why I added the warning about the attribution path. Really, we should always add all the names of all the involved authors for an image already from starters, and not trust the attribution path. See for instance how we wrote the full attribution in the description of Image:Gnome globe current event.svg. That means that image is not depending on any other image for its attributions, and the other other images can be deleted if we feel we don't need them anymore.

2: Storage size is pretty irrelevant since Wikipedia has no lack of storage space. Rather what costs money is bandwidth and that also costs load time for the users. But MediaWiki renders SVGs as PNGs before it sends the images to the web browsers, since most web browsers can not render SVG images. Thus SVGs and PNGs cost the same bandwidth and load time. And it doesn't help to optimise the PNGs before you upload them, since in most cases they are used at another size in the article and thus have to be re-rendered by MediaWiki. (Besides, SVGs are not always smaller than the PNGs.)

3: When scaling images down in size the PNG re-scaling function of MediaWiki now is so good that a downscaled PNG often looks somewhat better than a downscaled SVG. But in some cases the SVG looks better. That is, both scaling functions now are so good that it doesn't matter much. (Well, for some high-use icons we do take the time to do the comparison and choose the one that looks better.)

4: Both scaling functions take some server load to perform, but that doesn't really matter since that is only done once, the first time the images are used at some specific size, and then the scaled versions are cached in PNG format on the servers "forever".

5: Rather, one advantage with SVGs is that they can be scaled up a lot without loosing quality. But if you work with PNGs and upload a sufficiently large original (say 400 pixels wide or so) then the image will always only be scaled down and always look good. So then the looks are no problem either. But sure, since many editors tend to upload too small PNG originals then SVGs are slightly better, since then it doesn't matter in what "size" the user uploads them.

6: Also, some think that it is easier to edit an SVG later on, like changing text in the image to another language so it can be used on another language Wikipedia. Yes, that is somewhat true. But frankly, I say that just means they are pretty bad image editors if they can't change a simple text in a bitmapped image or resize or move a box in a bitmapped diagram.

7: As I see it, the one big advantage with SVGs is that we can cut out items from SVGs and easily reuse those items in other images. That is something that can't be done well with PNGs. See for instance Image:Gnome globe current event.svg, we built it by putting together parts from other images. That's when SVGs really shine.

So really, in some cases SVGs are better, and in some cases PNGs are better. We should not replace a good looking PNG with a less good looking SVG just "because". But when you make new diagrams then due to reason 7 above consider using SVG as the format of choice.

And all this also means that I think it is a waste of editor time to remake good PNGs to SVGs. Your time would be much better spent if you used the time to instead make brand new SVGs for images and diagrams that we currently do not have an image for.

Suntag: I have no idea how we should compress all this down to some short reason to put in the {{vector version available}} template...

--David Göthberg (talk) 18:16, 11 September 2008 (UTC)

Non-free images

Template:Non-free vector version available has been nominated for deletion. Anyone interested is invited to comment on the discussion at the template's entry on the Templates for discussion page. That template uses the "nonfree=yes" parameter of this template; if that template is deleted, then I believe the "nonfree" parameter of this template should be removed as well. All the best, – Quadell ^(talk) 22:03, 16 August 2011 (UTC)

Requesting changes

Where it says, "…in order to maintain this information.For more information…" it should be, "…in order to maintain this information. For more information…". There must be spacing between "information." and "For". JC · Xbox · Talk · Contributions 08:01, 23 March 2013 (UTC)

 Done —Bkell (talk) 08:31, 23 March 2013 (UTC)

mono-space font for nonfree=yes

 New: When using nonfree=yes, the middle part of this box is displayed in a mono-space font like this:

 For more information, see the documentation on MediaWiki's support of SVG images.

There's a space somewhere before this fragment, related to the use of nonfree=yes. +mt 03:03, 8 April 2015 (UTC)

Template-protected edit request on 27 December 2018

To remove obsolete HTML tag lint error, please change

<center>...</center>

to

<div style="text-align: center;">...</div>

Of course, everything before, in between, and after stays the same. — Anomalocaris (talk) 02:08, 27 December 2018 (UTC)

@Anomalocaris: why do you want to introduce a new block element here (as opposed to using span or otherwise stylizing the table that is wrapping this)? — xaosflux ^Talk 02:49, 27 December 2018 (UTC)

User:Xaosflux: I edited {{Vector version available/sandbox}} to be the version I requested in the first place. I tested it at User:Anomalocaris/sandbox/Lint Test and my sandbox version has no lint errors and seems to work without any issue. I do not understand your problem. Where in Wikipedia is this template used where an additional block element would be a problem? —Anomalocaris (talk) 06:41, 27 December 2018 (UTC)

@Anomalocaris: just semantically, checking why you want to create a new block element (div) when this line of text is already fully enclosed in a block element? — xaosflux ^Talk 16:23, 27 December 2018 (UTC)

 Done Span does not work and I can see no table for this. Also this group of elements does seem to be in it's own section (as indicated by the horizontal line), so as a div defines a section of a document, it seems a good fit. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:06, 27 December 2018 (UTC)