Template talk:Convert to SVG/Archive 1

Topics from 2006

Policy proposal:No deletion of improved versions of images

Hi folks. Anyone reading this may be interested in Commons:Village pump/Policy proposal:No deletion of improved versions of images. pfctdayelise (translate?) 00:51, 21 February 2006 (UTC)

See also Category talk:Images that should use vector graphics / Fred Chess 10:31, 21 February 2006 (UTC)

I think text of template should be updated to remove deletion request text. --EugeneZelenko 16:19, 23 February 2006 (UTC)

Optional image type parameter

Since Category:Images that should use vector graphics has grown really huge, I have added an optional parameter to the template to subcategorize images by type. For example, {{Convert to SVG|flag}} will place an image in Category:Flag images that should use vector graphics. Other subcategories may be added as needed. --Ilmari Karonen 18:28, 21 February 2006 (UTC)

I've also written a user script for semiautomatically sorting images into the subcategories: en:User:Ilmari_Karonen/fixconverttosvg.js. —Ilmari Karonen 21:18, 21 February 2006 (UTC)

Image in the box

The following tag could be added before "This ..."

Image:Converted_to_SVG.svg|80px|left

(in brackets of course)

—the preceding unsigned comment is by Teebeutel (talk • contribs)

• Done – thanks for the suggestion!  David Kernow 02:16, 28 June 2006 (UTC)

May this template be translated?

Like {{PD-self}}

I, the copyright holder of this work, release this work into the public domain. This applies worldwide. In some countries this may not be legally possible; if so: I grant anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law.

A list of languages it shown at the end of the template. I can write here the translation to Spanish:

Esta imagen (o todas las imágenes en este artículo o categoría) deberían volverse a crear como imágenes vectoriales SVG. Esto proporciona muchas ventajas, véase Commons:Images for cleanup para más información. Si ya hay una versión SVG de esta imagen disponible, por favor súbala a Commons. Tras subirla, reemplace esta plantilla con la plantilla {{SupersededSVG|nuevo nombre de imagen.svg}} en esta imagen.

---

---

Todas las imágenes con esta plantilla se añaden automáticamente a Category:Images that should use vector graphics, una subcategoría de Category:Images for cleanup. El tipo de imagen (en inglés, tal como "flag") se puede dar como parámetro a la plantilla y se fijará al nombre de la categoría. Category:Image cleanup templates en:Template:Convert to SVG

{| {{PD-Layout}}
| [[Image:Converted to SVG.svg|64px]]
|
| Esta imagen (o todas las imágenes en este artículo o categoría) deberían volverse a crear
'''como imágenes vectoriales [[:es:Scalable Vector Graphics|SVG]]'''. Esto proporciona muchas ventajas (véase [[Commons:Images for cleanup]] para más información). Si ya hay una versión
SVG de esta imagen disponible, por favor súbala a Commons. Tras subirla, reemplace esta plantilla
con la plantilla {{tlp|SupersededSVG|''nuevo nombre de imagen''.svg}} en esta imagen.
|}<includeonly>[[Category:{{{1|}}} images that should use vector
graphics|{{PAGENAME}}]]</includeonly><noinclude>
<br><br>
----
----
Todas las imágenes con esta plantilla se añaden automáticamente a [[:Category:Images that
should use vector graphics]], una subcategoría de [[:Category:Images for cleanup]]. El tipo
de imagen (en inglés, tal como "flag") se puede dar como parámetro a la plantilla y se fijará
al nombre de la categoría.
[[:Category:Image cleanup templates]]
[[en:Template:Convert to SVG]]
</noinclude>

and Gallician:

Esta imaxe (ou todas as imaxes neste artículo ou categoría) deberían recrearse como imaxes vectoriais SVG. Isto proporciona moitas vantaxes (véxase Commons:Images for cleanup para máis información. Se xa hai unha versión SVG desta imaxe disponible, por favor súbaa a Commons. Tras subi-la, reemplace esta plantilla coa plantilla {{SupersededSVG|novo nome de imaxe.svg}} nesta imaxe.

---

---

Todas as imaxes con esta plantilla engádense automáticamente a Category:Images that should use vector graphics, unha subcategoría de Category:Images for cleanup. O tipo de imaxe (en inglés, tal como "flag") pódese dar como parámetro á plantilla e fixarase ó nome da categoría. Category:Image cleanup templates en:Template:Convert to SVG

{| {{PD-Layout}}
| [[Image:Converted to SVG.svg|64px]]
|
| Esta imaxe (ou todas as imaxes neste artículo ou categoría) deberían recrearse '''como imaxes vectoriais [[:gl:Scalable Vector Graphics|SVG]]'''. Isto proporciona moitas vantaxes (véxase [[Commons:Images for cleanup]] para máis información. Se xa hai unha versión SVG desta imaxe disponible, por favor súbaa a Commons. Tras subi-la, reemplace esta plantilla coa plantilla {{tlp|SupersededSVG|''novo nome de imaxe''.svg}} nesta imaxe.
|}<includeonly>[[Category:{{{1|}}} images that should use vector graphics|{{PAGENAME}}]]</includeonly><noinclude>
<br><br>
----
----
Todas as imaxes con esta plantilla engádense automáticamente a [[:Category:Images that should use vector graphics]], unha subcategoría de [[:Category:Images for cleanup]]. O tipo de imaxe (en inglés, tal como "flag") pódese dar como parámetro á plantilla e fixarase ó nome da categoría.
[[:Category:Image cleanup templates]]
[[en:Template:Convert to SVG]]
</noinclude>

but as parameter is in English, I can't insert it on the content of the template. I hope this is useful anyways. --Nethac DIU 19:28, 12 July 2006 (UTC)

world maps

Stop adding this template to world maps. Coastlines cannot be shown properly as vectors - you cant come up with an equation to describe them, they are more like a photograph in that respect, and you wouldnt convert photos to svg!. because of this svg is inaccurate at every scale, while png is accurate to the scale it depicts. svg world maps are also ten times larger, and harder to view --Astrokey44 08:34, 15 December 2006 (UTC)

Topics from 2007

Rude, petty waste of time

11-May-2007: The effort to force images into SVG format has unfortunately produced a rather vicious, rude impact on works-in-progress by original authors not using SVG format. Even GIF files that are a mere 1766 bytes are being hounded for such petty, senseless conversion, regardless of the plans of the original authors for those images, and a result, the rude and petty reformatting of images has produced many hours of frustration and extreme agravation (gee, image that, huh?). Let this be a first, and formal, notification that the whole concept of rampant reformatting of images, even those of trivial and petty sizes, is completely unacceptable and will not be tolerated much longer. N.B.: I am hereby giving due warning to cease and desist the rude and petty waste of time involved in the reformatting and deletion of images. -Wikid77 11:35, 11 May 2007 (UTC)

It's not about the size, it's about the quality. If I wanted to quickly grab a small portion of the image and zoom in on it to provide greater clairity, I would be faced with the limitation of raster format. For example, see [4 bit counter] diagram. Is there a good reason why this image should be in raster format, other than to save you time? I say that if someone wants to make a vector version of the image, let it be.

The advantages of SVG conversion are numerous and include better scalability, editability, and reusability. Of course it's reasonable to coordinate with the original authors if it's a work-in-progress - no sense in working at cross-purposes. Dcoetzee 21:26, 12 June 2007 (UTC)

Requested edit

{{editprotected}} Can the image be changed to ? 71.233.232.243 19:45, 26 May 2007 (UTC)

 Not done I don't think that's a good idea. The image that is used is more descriptive. MECU≈talk 21:13, 12 June 2007 (UTC)

SVG does not work in Microsoft Internet Explorer browser

Please see: http://wiki.svg.org/Internet_Explorer

Most people use MS Internet Explorer (MSIE) browser. SVG does not work in Microsoft Internet Explorer browser, not even in MSIE v7.

I use both Firefox and MSIE browsers. Firefox browser can view svg images.

If one goes to this page

• http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

in both Firefox and MSIE one sees png images substituted for the svg images. I believe wikimedia/wikipedia does that for all svg images.

And what are the kilobyte sizes of the png images versus the svg images? I thought png images required skill to create them in lower kilobyte sizes. I thought that it was not possible to do that automatically by a server program.

There is more discussion here: Commons talk:Deletion requests/Superseded. --Timeshifter 15:26, 24 June 2007 (UTC)

IE 9 will have SVG support, basic at least (i.e. no filters). In any case, for web display it's probably correct to use PNG images instead of SVG directly for many many images. Take for example some SVG maps which easily can be several MiB in size whereas a PNG thumbnail has reasonable sizes. Of course, many simple flags are tiny in SVG (unless created in Inkscape) and could be served without a problem. But changing the infrastructure so that *some* SVG images are embedded as SVG in the page and some are not and all according to user preference is probably much effort for very little gain. —Johannes Rössel (talk) 11:13, 26 February 2011 (UTC)

GIF images make more sense for maps, charts, tables, and most graphics.

Maps, charts, tables, and other graphics usually use few colors. GIF images scale fine, and look great. It is a lossless format, but does not have a wide color palette. So for such graphics it is great. And gif image code and creation is no longer under any kind of patent protection.

It seems ridiculous to me to be converting low-kilobyte, lossless, scalable gif graphics to png images.

GIF images scale much better than png images at the server level. Servers can create and cache low-kilobyte gif images almost instantly at any size. And the images look fine at all sizes since it is a scalable, lossless format. Also, the average person can find and edit many public-domain gif graphics, and upload them to wikipedia. Even with simple-to-use, popular freeware image editors such as IrfanView.

PNG images use many more kilobytes when scaled and cached automatically by the wikimedia/wikipedia servers.

PNG images are only necessary for scalable, lossless, high-color and true-color images. Since png is a lossless format.

PNG images can't be quickly scaled at the server level, if one wants low kilobytes comparable to jpg images.

I see jpg images being substituted for png images in some cases on wikipedia. I see png images being stored at the commons, but jpg images being substituted for actual use, expecially if the image is shown at a larger size on the particular wikipedia page.

Please see:

• http://commons.wikimedia.org/wiki/Commons:Images_for_cleanup#PNG_photos_that_require_a_JPEG_version

So lossless, true-color, PNG image perfection is desirable for storage, but it is not practical for actually showing those large photos on the web at this stage of image technology for the web. At least for dialup users of the web.--Timeshifter 15:32, 24 June 2007 (UTC)

I think you are incorrect and misunderstand the technical details of the .png format. A PNG format image does not have to be 24-bit colour. It can have an 8-bit palette exactly like a Compuserve GIF image. With identical 8-bit (256 colour) images, the PNG version will definitely be smaller than its GIF counterpart, because the Huffman compression in the PNG file is superior to the Lempel-Ziv-Welch compression in the Compuserve GIF file. Easyplex 03:09, 15 August 2007 (UTC)

I understand that png images can have an 8-bit palette. But gif images are easier to use for most people for charts, etc.. Even the simplest image editors can usually handle gif images. So I think that Wikipedia should actually encourage gif use for charts and 8-bit palette graphics in general. Because it is almost impossible not to get a comparatively low-kilobyte, lossless image when using the gif format.

GIF images are not good for high-color images, and most people learn quickly not to try. So people use gif images for charts and graphics. People can't easily screw up charts and low-color graphics with gif editing. But they can end up with high-kilobyte images of varying quality if they try to create jpg and png versions of the same charts and graphics.

See this gif image: . I created it a year ago from a federal government PDF file, and put the chart in this wikipedia article: w:Incarceration. But I haven't bothered with creating more gif images for wikipedia because of this elitist snobbery about only wanting png images. Well, I don't have the time or interest to learn how to edit png images. I have tried, and find it to be a complete pain. --Timeshifter 06:24, 15 August 2007 (UTC)

OK. I am calm. :) I found out why PNG images are not scaling well on wikipedia. Please see Commons talk:Deletion requests/Superseded#Further considerations and (future) suggestions. ColdShine says that "MediaWiki renders all SVGs and scaled PNGs as truecolor PNGs, even when the source images are 8-bit."

See also the section titled "Scaled GIF images use much fewer kilobytes than scaled SVG/PNG images".

PNG and SVG may be better than GIF in some ways. I don't know the technical reasons, nor do I see any appreciable differences for 8-bit images. But gif images are a lot easier to edit for most people, and now that we know that MediaWiki can't scale 8-bit PNG images correctly, then we need to encourage, not discourage, gif use for 8-bit graphics. Scaled gif images in wikipedia articles use much fewer kilobytes in many cases.

Many people create and upload 32-bit PNG graphics to wikipedia/wikimedia when they should be creating and uploading 8-bit GIF graphics. The 32-bit PNG graphics can use many more kilobytes, whether they are scaled, or whether they are at full size. This is a burden to both broadband and dialup users. --Timeshifter 23:28, 21 August 2007 (UTC)

Romanian translation

An admin please add the Romanian translation to the template - Template:Convert to SVG/ro. --Roamata 10:27, 2 September 2007 (UTC)

Another vanity-tag

11-Oct-2007: This SVG template tag has become quite the pompous vanity-tag, in 24 languages. It appears at the top of many articles, grandstanding, "Look at ME! I'm the SVG rant, more important than all articles combined!" I've even seen the SVG tag absurdly placed in articles with JPEG photo images, ranting to convert ALL images to SVG format, regardless of need. However, don't blame anyone in particular for vanity tags: such ridiculous vanity-tag usage is just another predictable facet of the age-old problem of "form over substance": in any aging bureaucracy, expect rampant memos about the need to adhere to standard formats and proper form. Always beware that "administrivia" will try to grandstand to take "center stage" and aggrandize its own self-importance. Take steps to curb the spread of vanity-tags:

• Limit each tag to about 3 lines of text, or 10% of in-your-face display.
• Always try to lower the tag after the intro text of an article; don't let the vanity-tag take "top billing" like the self-proclaimed star of the show.
• Reduce the ranting words such as "all images" and be less POV-biased by using phrases such as "might" or "most images" not ALL.
• Apologize for grandstanding: "(Remove this tag if unneeded)".
• Split into 10 various tags: rather than shine a vanity spotlight on just one prima-donna tag, create 10 minor, lesser variations, where each of the ten (or so) variations would apply only in a more limited scope, thereby limiting the pompous tendency to force the original, broader vanity-tag which applies everywhere.

Those are just a few techniques to limit the pompous spread of the grandstanding vanity-tags that make Wikimedia Commons seem like such an absurd project, with petty, ranting memos. Remember any aging bureaucracy must be managed to avoid "form over substance". -Wikid77 10:31, 11 October 2007 (UTC)

Topics from 2008

Link fix

Can some admin please change the link Commons:Images for cleanup to Commons:Media for cleanup? --jed 07:51, 5 January 2008 (UTC)

Category when omitting optional file format/type flag parameter

It appears that when the optional file format/type flag parameter is omitted, that the template might not be adding to an "Images that should use vector graphics" category?

I tried it without the optional parameter, and it did not seem to add the Canalvc.png file to a category. I tried it with a parameter of PNG, and it seemed to work appropriately. LeheckaG (talk) 20:43, 20 June 2008 (UTC)

template update

{{editprotected}} I've just updated the code at en:w:Template:ShouldBeSVG to address problems stated here. basically I rewrote it as a switch function, so that user errors with parameters can be caught and handled more easily. I've implemented it there, and it seems to work (though there's always the possibility that it might need some tweaking...). could someone edit it here as well? all that needs to be replaced in the contents of the 'includeonly' block, where the category is transcluded.

<includeonly>{{{category|[[Category:{{#switch:{{lc:{{{1|}}}}}
|alphabet|chemical|circuit|coat of arms|diagram|emblem|fairuse|flag
|graph|map|music|physical|symbol={{lc:{{{1|}}}}}
|icon=symbol
|{{#if:{{{1|}}}|other}}}} images that should be in SVG format|{{PAGENAME}}]]}}}</includeonly>

--Ludwigs2 (talk) 22:25, 12 August 2008 (UTC)

Take a look at Category:Images that should use vector graphics. Commons has different categories. Rocket000(talk) 22:41, 12 August 2008 (UTC)

ah, sorry - that would be easy to fix, except it doesn't seem to be documented anywhere. let me see if I can ferret it out and make the change. --Ludwigs2 (talk) 23:34, 12 August 2008 (UTC)

revised version, using the commons categories (god bless regexp)  :-)

<includeonly>{{{category|[[Category:{{#switch:{{lc:{{{1|}}}}}
|flag|logo|map|symbol|coat of arms|chemical|circuit|math|alphabet|physical|music
|graph|military insignia|art={{lc:{{{1|}}}}}
|icon=symbol
|{{#if:{{{1|}}}|other}}}} images that should be in SVG format|{{PAGENAME}}]]}}}</includeonly>

There's a lot more than that. See Special:CategoryTree/Images that should use vector graphics (including all the subcategories like in Map images that should use vector graphics). Keep in mind, we on Commons have way more more images to deal with. Rocket000(talk) 00:13, 13 August 2008 (UTC)

I understand that you have a lot more images to deal with, but the nature of a category system is that things should be... err... categorized. it seems like a lot of these images are simply uncategorized by the people attaching the SVG tag, and some of them are categorized randomly, but still, there should be some kind of hierarchy and structure here, otherwise it's just a bloody mess. part of this has to do, of course, with the fact that the {{SVG}} template is undocumented on Commons, and so people either put nothing in for the parameter, or use parameters they pick up somewhere else. I'm happy to write the documentation as well, if you think that would help, but I'd still need some idea of what the basic categories we're dealing with are.

I can see for commons purposes that the SVG template might need to be revised to use category trees more effectively. I'll give that some thought. but if you and I can work out what kind of structure these pages should have, I'm sure we can make this a much more effective system. --Ludwigs2 (talk) 00:44, 13 August 2008 (UTC)

OK, I'm about to sign off for now, but I'll have a look at what we need and don't need. I see there's a lot of over-categorization. I'll get back to you tomorrow. Rocket000(talk) 03:06, 13 August 2008 (UTC)

I'm filtering out the categories that were added in full by the template.. this takes a bit to update, but it will make making the list easier. Rocket000(talk) 20:12, 14 August 2008 (UTC)

How's that? I went with all the categories with at least 10 images. Not as many now (but icon was left in). Rocket000(talk) 20:45, 14 August 2008 (UTC)

that looks good to me. would you like me to beef up the docs? I'd copy over and edit the one from english wikipedia, which is pretty well written...

a couple of other questions while we're at it. on the version of this template on english wikipedia, I made the following two changes:

1. uncategorized items all go to the other images... category page, mostly to prevent the main category page from having a mess of images on it
2. categories are listed using the default sort order, rather than the all-up-front alphabetical sort order that gets used here. I'm not sure which is preferable, but I think it should be consistent across projects. take a look and tell me which way you think it should go.

--Ludwigs2 (talk) 01:23, 15 August 2008 (UTC)

First things first, I moved the documentation to Template:Convert to SVG/doc, where you're absolutely welcome to give it better documentation. Next, it doesn't matter to me where the rest of the images go, but I think maybe knowing which ones have a non-standard name verses having no parameter at all would be useful to know. As for #2, I think we should keep the subcategories all in front because there are other categories that are added in full, like Category:Dinosauria size comparisons (personally, I don't think it should be done this way, but it is). Rocket000(talk) 23:02, 15 August 2008 (UTC)

ok. I think I might go through and rationalize the category tree some (just because it looks like a mess). it's funny, the original purpose of these edits was to map 'icon' to the 'symbol' category, because an editor on wikipedia was using the wrong name, and now icon and symbol are two separate cats. I still think that's a good idea (symbols and icons are pretty much interchangeable terms...). ah, well, let's see what happens... --Ludwigs2 (talk) 01:14, 16 August 2008 (UTC)

Retrofit topic-year headers

20-Aug-2008: I have grouped older topics above using headers "Topics from 2006" (etc.) to emphasize age of topics. Older topics might still apply, but using the tactic of yearly headers to note the age helps avoid rehashing old news, without archiving any ongoing issues. Also, new topics are more likely to be added to the bottom, not top. -Wikid77 (talk) 17:07, 20 August 2008 (UTC)

image categories

I redid the docs, and it seems to me that some of the categories here are redundant or unnecessary. for instance:

• 'fairuse' and 'png' are completely unused (I had to make the appropriate pages for them myself) and should probably be deleted entirely.
• 'music' and 'musical notation' are redundant. and the latter should probably be merged into the former.
• 'icon' and 'symbol' seem redundant, and should probably be merged
• 'logo' and 'emblem' also seem redundant, and should probably be merged
• a few common misnamings that end up in 'other', usually plurals, that should be accounted for.

if all of the above were done, the new code would look like this:

<includeonly>{{{category|[[Category:{{#if:{{{1|}}}|{{#switch:{{lc:{{{1}}}}}
|alphabet|art|chart|chemical|circuit|coat of arms|diagram|flag|graph|logo|map|math|military insignia|music|physical|symbol={{{1}}}
|musical notation=music
|emblem=logo
|icon=symbol
|chem|chemical structure|chemistry=chemical
|flags=flag
|other}}}} images that should use vector graphics|{{PAGENAME}}]]}}}</includeonly>

sorry, that previous revision request was from me. --Ludwigs2 (talk) 01:49, 26 August 2008 (UTC)

Topics from 2009

Multiple categories

Does this template currently take multiple parameters? If not, could this template be adjusted to do so? For example to display: This biology/diagram image should be... on this image with only one template. It could theoretically still put the image in both hidden(?) categories as well.--Rockfang (talk) 22:04, 6 May 2009 (UTC)

diagram should only be used for diagrams that don't fit in the other categories. Almost everything in the biology category is a diagram. Maybe this should be renamed? Rocket000 (talk) 00:33, 1 September 2009 (UTC)

Its seems not working. Example File:Russisk-befolkning.jpeg --Perhelion (talk) 18:47, 11 May 2010 (UTC)

I mean for example the category graph (which are linked in the template) didn't exists. --Perhelion (talk) 16:38, 12 May 2010 (UTC)

Extra link

This template should have another link leading to "SVG" (here in commons, where aditional information is present). - ☩Damërung ☩. -- 01:38, 30 September 2009 (UTC)

Suggestion for new parameter value: Signatures

{{Editprotected}} I would like to hereby request that a new parameter value for signatures be added to this template.--Blargh29 (talk) 01:58, 18 December 2009 (UTC)

 Done. --The Evil IP address (talk) 13:56, 21 December 2009 (UTC)

Topics from 2010

Suggestion for new parameters value: Sport and Technology

{{editprotected}}

I would like to hereby request that new parameters value to be added to this template. Ps: in relation to Category_talk:Images_that_should_use_vector_graphics#Suggestion_for_new_Categories --Perhelion (talk) 19:41, 24 October 2010 (UTC)

 Done They will categorize into Category:Sport images that should use vector graphics and Category:Technology images that should use vector graphics. Rocket000 (talk) 21:33, 28 October 2010 (UTC)

Thank you :) --Perhelion (talk) 17:26, 30 October 2010 (UTC)

new parameter

I would like to introduce a new parameter in the template for unused images. They would get something like "priority=low" and would be categorized into a separate category to relieved. Cheers --Cwbm (commons) (talk) 07:42, 17 November 2010 (UTC)

We have the problem that some categories are very full. Unused or other low priority images that are tagged clog the categories and prevent higher priority images from being converted to SVG. Hence, the Category:Graph images that should use vector graphics could get a subcategory named Category:Graph images that should use vector graphics/low priority or similar. --Leyo 08:52, 17 November 2010 (UTC)

It would probably be better to do it the other way around, i.e. to tag high prio images. It could be done using a parameter like |prio=high. // Liftarn (talk)

We could also use something like Top 200 symbol images that should use vector graphics as a guide. // Liftarn (talk)

High priority would be redundant to the list. And if you take more images the categories get too big. --Cwbm (commons) (talk) 15:45, 18 November 2010 (UTC)