Talk:SVG/Archive 2

'IE users have to download and install a browser plugin' in lead

There seems to be a concerted attempt going on to insert a puff for VML into this sentence in the lead. The issue is well covered later in the article - "Web sites that serve SVG images, for example Wikipedia, typically also provide the images in a raster format, either automatically by HTTP content negotiation or allowing the user to directly choose the file." Web sites can convert to any format that IE understands - PNG, GIF, JPEG, VML, even <canvas> and therefore not serve SVG at all to this user - or the user can install a plugin. The lead provides a summary of the article: If you want more detail, let's put it in the article, not the lead. But let's make it true - the *user* cannot convert the file without a plugin, and it is not true that "the SVG must first be converted to VML" - it can be converted to any format that IE understands. --Nigelj (talk) 22:03, 11 April 2009 (UTC)

Firstly, I am not the person who inserted this line, nor do I have any POV that supports the use of VML in any unbalanced way, in fact normally quite the opposite. So if there is a "concerted attempt" at anything, I am not a part of it. I did revert your two deletions as I believe the line is (a) informative and therefore of benefit to the article and (b) does no harm. As for your last point about converting to PNG, GIF, JPEG or VML only one of those is a vector format like SVG is, so all conversions would result in (probably significant) loss of functionality and quality (as Wikipedia's use of rsvg does). Neither would facilitate DOM access either, a significant feature the use of vector formats in web markup.

Either way, I'll leave it as it is, as you seem to feel a lot more strongly about the issue than I do. If any other editors agree with me please feel free to revert Nigel's deletions. _ɹəəpıɔnı 23:15, 11 April 2009 (UTC)

"All currently supported graphical browsers"

"All currently supported graphical browsers on Linux systems and the Macintosh have implemented some level of SVG support."

I can't see that this can possibly be verified. There's no way anyone can be sure of finding all "currently supported graphical browsers" in order to check. "Currently supported" will necessarily include any browsers, however obscure, that are still in their early stages of development and therefore don't yet support SVG.

How can we best rewrite this statement into that is verifiable, find a suitable source, and provide an "as of" date rather than just the meaningless "currently"? -- Smjg (talk) 18:49, 10 May 2009 (UTC)

"All currently supported major graphical browsers"/"All currently supported popular graphical browsers"

Just out of curiosity, what graphical browsers are you aware of that don't support it? I can't think of any grasphical browsers that don't run on the "big three" rendering engines other than Konqueror and even that is apparently switching to WebKit in future. Are there other graphical HTML rendering engines? _ɹəəpıɔnı 18:59, 10 May 2009 (UTC)

To your first question: Internet Explorer for a start. Other than that I don't know, but I'm sure there are a number out there. To your second question: Yes. Presto, for example. No doubt others, especially given the number of browsers out there. But "All currently supported major graphical browsers" would probably deal with this sub-issue, given a reasonable objective definition of "major". (I've up to this point ignored mobile devices and the like, which are bound to give more answers though probably not in relation to Mac, Linux or Windows.) -- Smjg (talk) 20:17, 10 May 2009 (UTC)

In my first question, I didn't say, but I took it for granted we were restricting the conversation to Mac and Linux browsers seeing as they are the systems referred to in the quote you find dubious. So IE doesn't really apply.

In my second question, Presto is one of the "big three" in my mind. I was again excluding IE. I have since looked at Wikipedia's own List of layout engines and examined the others. AOL's Boxely UI toolkit isn't a browser (and doesn't support HTML or CSS - perhaps Wikipedia should have a separate List of HTML layout engines), GtkHTML is no longer developed (switching to WebKit), HTMLayout is Windows only and is not a browser (for application development), Mariner is no longer developed, Tasman (IE5 Mac) is no longer developed, tkhtml is a widget engine, and Prince does support SVG. So I'd say the statement as it was is relatively safe. _ɹəəpıɔnı 22:34, 10 May 2009 (UTC)

Also, on your other edit to the page, "As of now" is not really ambiguous - it is used on many wiki pages to simply mean "at time of writing". Pages on topics such as web technologies are accepted as being quite transient in nature (as is Wikipedia in general) so "as of now" is something very commonly applicable.

Article improvement - more specific information

Given that a small comment has been added on discussions regarding future diffusion curves support in SVG (thanks Nigel), a helpful and useful addition to the article, but a very specific, technical one, I've looked though the article and have some thoughts on additions.

• The functionality section is split into emboldened parts, the more significant of which have accompanying explanations. Less significant parts don't but could - would such info be over-technical in scope?
• Native browser support is mentioned and vaguely described. Would some kind of detailed table of support - i.e. a small visual summary of the content of Comparison_of_layout_engines_(SVG), with the addition of some (non-browser) renderers, be overly technical?

Just trying to keep WP:MTAA in mind. _ɹəəpıɔnı 19:10, 25 May 2009 (UTC)

Also as an aside, the comment "More recently, with the developments of HTML5, the SVG format may now have to contend with the <canvas> element, which is already gaining momentum." seems fairly extraneous and IMO not correct. <canvas> is not a vector technology, it's not an image format, and it can be used in conjunction with SVG (so they don't compete). The three "references" are non-notable bloggers. I'm going to remove it.

The Functionality section is incomplete. I see no reason why clear and accessible expositions should not be possible, but I don't have time atm. Globbet (talk) 15:31, 26 May 2009 (UTC)

I've just added the last five summaries to the Functionality section (Interactivity, Scripting, Animation, Fonts and Metadata). Please feel free to simplify or otherwise improve on my first drafts. I tidied up some stuff about browser support too, while I was in there. --Nigelj (talk) 19:55, 27 May 2009 (UTC)

Not a Forum

Wikipedia is not a forum. I have deleted, not archived, much discussion that is completely irrelevant to the improvement of this article. Discussion and questions about SVG are better dealt with at Wikipedia_talk:GL, WP:Village pump (technical), WP:WikiProject SVG, WP:SVG_Help, or Commons:Graphics_village_pump or see other pointers at WP:SVG image support. Globbet (talk) 17:03, 26 May 2009 (UTC)

Part of the content you deleted was my raising of the VERY IMPORTANT issue of lack of native support for Vector Feathering in the SVG spec...

- This is not not a forum, no...

- But why would you say silencing this issue is in any way beneficial to this article or the SVG spec generally?

- I tried to explain why this was so important...

- Decent Feather support is not a curiosity its core. —Preceding unsigned comment added by 58.165.95.165 (talk) 16:20, 29 May 2009 (UTC)

First, please remember to sign and date your contributions to talk pages by using ~~~~. Secondly, I do not wish to silence anyone, but I would like you to try to understand that this is not the right place to discuss your thoughts or mine as to how SVG should work. This talk page is intended for discussion of how to improve the Wikipedia article on SVG, not how to improve SVG. Do you not see the difference? Wikipedia has no influence over the SVG specification, and no interest in your proposals unless they are recorded elsewhere and are generally regarded as sufficiently important. Please do some reading including WP:NOTFORUM before you put all the removed discussion back. A good place to discuss your ideas might be [1]. Please go to my talk page if you must argue the point. Globbet (talk) 22:44, 29 May 2009 (UTC)

Dear 58.165.95.165, you are not being silenced, you are merely been directed to discuss in a discussion forum (which Wikipedia is not a discussion forum). Wikipedia is not affiliated with the W3C, the Wikimedia Foundation have no influence in nor do they constribute to the creation and evolution of the W3C's SVG specifications. Wikipedia is an independent encylopedia that documents what IS, not discussed what might/could/should be. _ɹəəpıɔnı 08:00, 30 May 2009 (UTC)

Sir 58.165.95.165! If you wish to access the discussions that have been removed from the talk page, you may consult the history of the talk page. Very little is really deleted from Wikipedia, but still: the talk page is a discussion about the contents of the article, not a forum. Most of us are dry boring editors of an encyclopedia, with editorial ambitions, rather than affiniados of this-or-that program/OS/encoding, and forum-kind discussions are obstacles for the editorial process. Rursus dixit. (^mbork³!) 16:01, 18 January 2010 (UTC)

Limitations

22:10, 25 October 2009 Globbet (talk | contribs) (39,625 bytes) (Last two edits appear to be a misunderstanding) (undo)

Explain please. Who is misunderstanding and what. BPK (talk)

They were your edits, I think, so your misunderstanding. Contrary to what you said, SVG does support multiple switchable languages. That is one of its potential advantages for use in Wikimedia. However the librsvg software that is currently used in Wikimedia to convert SVG files to .png for display is not able to handle that feature of SVG. You are right that, at present, to show labels in a different language in Wikimedia you need to create a new file, but the problem is not with SVG. Globbet (talk) 18:47, 29 October 2009 (UTC)

Could you explain me how to use multilanguage SVG feature (how the strings should be declared, which software can show me that feature working, what I need to do to switch languages)? Best of all you explain this not only to me, but update the article in correct way. BPK (talk) 19:12, 30 October 2009 (UTC)

No, I don't think it would be appropriate to put that in the article because Wikipedia is not a manual. I will put something at your talk page, however. Globbet (talk) 22:32, 30 October 2009 (UTC)

Thank you very much. You are right - Wikipedia it is not a manual, but this feature is at least worth mentioning. BPK (talk) 16:46, 31 October 2009 (UTC)

No compatibility for IE?

How can I see the pictures in Wikipedia then? Are they rendered to PNG, and that's what I'm seeing? Flash man999 (talk) 04:07, 12 March 2010 (UTC)

Perhaps Wikipedia:Graphic Lab/Resources/SVG may be of some assistance. Hyacinth (talk) 07:30, 12 March 2010 (UTC)

Indeed it was. "MediaWiki converts the SVG image to a PNG image." Hyacinth (talk) 07:33, 12 March 2010 (UTC)

Click on the picture and then again so that you only see the picture! thats the only way to get the original svg. mabdul 11:57, 12 March 2010 (UTC)

Raster graphics in SVG

I would like to highlight the fact that any conforming SVG engine supports PNG and JPEG images. (See section 5.7 of the spec. Note that a PNG or JPEG image counts as a Graphics Element.)

I think this is significant. AFAICT, the W3C and the browser developers are now saying that The Right Way for websites to do animated raster images is (or will be) SVG in conjunction with SMIL (or, less preferably, Javascript), as opposed to animated GIFs or APNG. (Yes, using a vector graphics format to animate raster images is kinda odd at first sight. But it turns out to be technically better and politically easier than mandating APNG or MNG support.)

There's a very nice demo of manipulation of raster images via SVG here.

I've made two attempts to mention this in the article, neither completely satisfactory. Can anyone suggest a better way to mention this? Does anyone say we shouldn't mention this? Should we also mention that a SVG image can use embedded SVG images just like PNGs and JPEGs? Cheers, CWC 13:08, 15 August 2010 (UTC)

sry for the late answer: couldn't you wrote a separate paragraph about the topic that the W3C is definitive for svg against apng/mng/gif? we need reliable sources, but I think that I could find them / ask for a statement by the W3C. mabdul

I don't have a reliable source for SVG being the preferred way to do animation, that's just my personal judgment. (I only mentioned it here because it influences my thinking about what we should cover in the article.) Mabdul, it would be great if you could find or get something from the W3C. Please give it a try!

While I'm here, let me note that the animation features of SVG come from SMIL, but I don't see SMIL itself becoming very popular (except maybe its Timed Text profile). Cheers, CWC 12:29, 13 September 2010 (UTC)

W3C's SVG working group activity is publicly accessible. I have followed it for some time and am not aware of discussion about using SVG to animate raster images. Actually, I don't think I quite understand what you mean, anyway. In your example demo it does not seem to me that the bitmaps are animated. Globbet (talk) 23:00, 13 September 2010 (UTC)

I've added a brief mention of templating and use of PNG/JPEG/SVG images to the end of the "Functionality" section.

The only reason I've discussed animation of raster images here is that I think the arrival of IE9 and Firefox 4 will lead to websites moving away from flash and towards SVG for animation, and that many of these SVG animations will use raster images. Hence I think it important that the article mention that SVG images, animated or not, can include PNG and JPEG images.

Some asides: One reason I expect more SVG animations to appear is that flash-blockers won't affect SVG-based advertisements. (I created some simple SVG animations yesterday; it turns out to be really easy to make annoyingly attention-grabbing animations with SVG ...) SVG can do sequences of images like APNG does (by animating the xlink:href attributes of images), but will run on a lot more browsers than APNG. If only a smallish part of the image changes, SVG plus multiple PNGs may take less bandwidth than APNG. In fact, SVG is even more powerful than the formidable MNG, but is easier to create content with.

@Globbet: No, those bitmaps are not animated, but SVG can animate the clipping, zooming, scaling and even filtering of bitmaps. The SVG animation stuff works the same way on any graphic object, whether a stroked path or a raster (that's one of many nice things about SVG), so I wouldn't expect there to be much discussion of animating rasters.

Now I'm going to add an animated Gaussian blur to a little animation I created yesterday. Cheers, CWC 15:08, 20 September 2010 (UTC)

Limited support under Android 1.9 / 2.2 native browser(s)?

I'm seeing some limitations in what SVG content will render properly under the default browser (or alternative browsers) running on Android 1.9. I believe this is also true for Android 2.2. The SVG wikipedia page doesn't provide any insight regarding Android support for SVG.

Can anyone confirm what support there is for SVG under the Android browser(s), and update the Wikipedia content accordingly?

Thanks, Paul. 60.241.203.71 (PaulSzym) 14:08, 1 January 2011 (UTC)

Apparently, no [2]. I updated this in the mobile paragraph. Hervegirod (talk) 14:31, 1 January 2011 (UTC)

Wrong about Wikipedia and SVG

Section Support for SVG in web browsers claims:

Many web sites that serve SVG images, such as Wikipedia, also provide the images in a raster format, either automatically by HTTP content negotiation or by allowing the user directly to choose the file.

But it doesn't serve SVG images! It auto-converts them to .png whether I wish or not, and serves PNG to the browser, never SVG. It supports SVG:s but never serves them. Therefore the statement is inaccurate and the fact that it supports SVG is irrelevant in this context. I've tried to find a way to let WP serve SVG instead of autoconvert them, but I've found none so far. Rursus dixit. (^mbork³!) 09:05, 6 February 2011 (UTC)

I think Wikipedia falls into the second category. If you go to File:SVG-logo.svg and click on the link SVG-logo.svg below the image, it will have allowed you "directly to choose the file". 'View source' to verify that. --Nigelj (talk) 09:41, 6 February 2011 (UTC)

Internet Explorer 9

Quickly changed the lead to reflect the release of IE9. I also plan to add an out of date tag to encourage factual review in light of this new development. Xenni (talk) 02:02, 23 March 2011 (UTC)

Internet Explorer

The last sentence of the introduction needs to be removed (concerning IE). IE 9 supports SVG. There is no reason to note that older version of one browser or another do not support SVG.

• Mostly disagree since IE9 does not run Windows XP (which is still the most used version of Windows). But I can fix up the sentence. -- KelleyCook (talk) 19:28, 9 June 2011 (UTC)

• It is quite important to note that all versions before IE 9 do not support SVG because many people still use these older versions — Preceding unsigned comment added by 207.204.230.151 (talk) 00:13, 3 December 2011 (UTC)

Section 508 compliance

Are SVGs able to support alternative text for people with disabilities? I know that CGMs do not support alternative text and I was just wondering about SVGs. Thank you. — Preceding unsigned comment added by 152.121.17.253 (talk) 11:46, 29 June 2011 (UTC)

Since SVG is based on XML, every good application is able to read the actual text of the SVG and thus able to present it to disabled persons. mabdul 03:00, 3 December 2011 (UTC)

Usage share

There is ABSOLUTELY NO WAY that IE has more usage then Chrome. Just impossible. Same goes with IE and Firefox. 86.150.108.189 (talk) 16:18, 11 December 2011 (UTC)

SVG Print is obsolete

The overview notes that the SVG Print subset is currently a working draft. According to http://www.w3.org/TR/ the SVG Print subset has been retired. I couldn't find anything on the w3.org site explaining why it has been retired. Presumably there must be a record of the decision somewhere. The only information I've come across is this talk by Chris Lilley http://www.youtube.com/watch?v=e2J3k_S1eb0 where in response to an inaudible question at 18:05 he says at one time there was a thought that SVG should be an alternative to PDF but that is no longer the case. — Preceding unsigned comment added by 1.124.170.144 (talk) 03:55, 1 July 2012 (UTC)

How?

How are the vector images on Wikipedia made? 76.120.17.197 (talk) 22:00, 6 August 2012 (UTC)

Removed image

File:Difference between SVG and other file types.svg

Difference between SVG and other file types

Aguzer (talk · contribs) added this image to the page in this edit. I removed it, saying, "Reverted good faith edits by Aguzer (talk): Rv baffling image. Please explain on Talk page what aspect of SVG this is meant to illustrate, as that is not clear." Aguzer has responded on my personal talk page saying

Original:" SVG dosyalarının içeriği taşınabilir dir. Yani katman halinde. Diğer dosya türlerinde ise öyle bir şey yok. O resim bunu anlatıyordu. " Google Translate: " SVG files are portable content. So if the layer. Other types of file is no such thing. That picture tells it. "Aguzer (talk) 21:04, 12 November 2012 (UTC)

What do other editors think? I don't think that the concept of layers is specific to SVG; I don't think that the image particularly illustrates the benefits and possibilities offered by layers; I think it is just as likely that a reader will see the image and think it means that coloured objects do not register correctly with their neighbours after an SVG file is saved and re-loaded. --Nigelj (talk) 21:39, 12 November 2012 (UTC)

Original:" SVG dosyaları kayıt edildikten sonra yeniden düzenlenebilmektedir. Ancak diğer dosya türleri özel programlarla sadece açıkken katmanlar halinde yapılabilir. Onlar kayıt edildikten sonra artık düz bir yüzey gibi olurlar. "

Google Translate:" SVG files can be rearranged after being registered. However, only when other types of files with special programs can be done in layers. After the fan as they are no longer a flat surface. "Aguzer (talk) —Preceding undated comment added 10:36, 13 November 2012 (UTC)

Original:"Diğer dosya tipleri saklandıktan sonra artık düz bir yüzeydir."

Google Translate:"After being stored in the other file types is no longer a flat surface."Aguzer (talk) —Preceding undated comment added 10:40, 13 November 2012 (UTC)

• Oppose including image. Yes, SVG file contain objects that can be edited. Not sure that should be emphasized because many SVG images will be generated from a source with more information. The SVG files I've looked at have a lot of noise in them. The given file suggests 3D data exists, but that is not the case. It does not illustrate the desired concept. Glrx (talk) 18:16, 16 November 2012 (UTC)

New links

This edit reintroduced a previously deleted SVG converter link and added two other links. One new link is an SVG converter, and a second is an SVG editor. The links are:

• SVG-edit – Online graphics editor (free program running inside of the web broeser, based on SVG-DOM and JavaScript)
• SVGConv - The online SVG converter - Online converter that converts SVG to JPEG, PNG, GIF, BMP, PDF, PS and other formats; processes multiple SVG files in multiple output formats in one step
• Go2convert – Online converter, which - among many other format conversion tasks - can export SVG to various raster image formats (JPEG, GIF, TGA, BMP etc.)

These links are SVG tools and do not contain content about SVG. There are many tools for editing SVG, and the previous section (Scalable Vector Graphics#Software and support in applications describes some. WP need not advertise an online tool (that has little documentation). Converters are of limited utility to general readers given that current web browsers can render SVG. The Go2Convert.com is not an "online" tool; it requires a download. Furthermore, the added section is more akin to an External links section. The links sound in advertising.

I would revert the edit, but I've already done that once. Glrx (talk) 18:54, 26 November 2012 (UTC)

Links removed today stated based on original research

• VectorMagic Precision Bitmap To Vector Conversion Online - Converts JPEG,GIF, PNG to vector formats like SVG, EPS, PS, PDF. No batch processing.
• Go2convert - Free Online File Conversion - Converts to/from over 100 major image formats including BMP, EPS, GIF, JPEG, IMG, PDF, PNG, PSD, SVG, and TIFF. The output image is hosted on the site for 2 days; size and quality are customizable. Batch processing with separate desktop app. Upload Limit: 10MB.

This one appeared dead/unresponsive:

• OnlineImageConverting - Online image converter - Converts to/from BMP, DDS, EPS, EXR/HDR, GIF, ICO, JPG, MNG, PCX, PNG, PSD, SVG, TGA, TIFF. No batch processing. Color depth, size, quality are customizable.

The above sites were removed from the article today by an IP user who made a large number of edits. The stated reason for removal of these links was explicitly WP:OR. From the edit summaries, I am assuming that the editor attempted to convert some unknown file using each of these services. Given that we are listing some such services in the article, should these be put back in the article? What criteria are we using for including such a service in this article? —Makyen (talk) 04:14, 30 January 2014 (UTC)

@Makyen: is this list needed? Just wondering. George8211 // Give a trout a home! 12:15, 15 February 2014 (UTC)

@George8211: I'm not sure, which probably shows some personal bias. My issue with the edits was that they were paring down the list based on testing against some undefined file, with unknown criteria applied to the output. I would not have much of a problem with doing so if the file was a defined, standardized image and the criteria matched against the output was specified. When I first visited this article, quite some time ago, I found the list to be helpful. Makyen (talk) 02:59, 17 February 2014 (UTC)

I have mixed feelings. WP isn't supposed to be a directory, and lists of application software end up being spam magnets. On the other hand, a tool that converts a bitmap to SVG can be useful. I have several such tools that are not in the list; CorelDRAW did a supprisingly decent job a few months back. For the most part, converting raster to vector does not work well; the result must be edited with a vector graphics editor.

I don't think we should list SVG to bitmap converters given the browsers will now do that job. It's not that interesting.

Taking a broader view, the real issue is not bitmap to SVG but rather bitmap to some vector graphics format (many of the example tools list many graphics formats). So the simple way out is to mention that there are many tools that Vectorization (image tracing) / convert bitmaps to vector formats (such as SVG) and be done with it. Maybe point to Comparison of raster-to-vector conversion software. Glrx (talk) 22:58, 18 February 2014 (UTC)

Plug-in section removal?

Do we really need an entire section describing old plug-ins for a single version of an old browser? I don't seen any need to keep Plug-ins section around. --209.203.125.162 (talk) 02:10, 12 March 2014 (UTC)

I would say keep it mostly as is for now. While IE8, or earlier, is down to about 5% of the accesses to Wikipedia, IE8 still accounts for about 20% of all web traffic according to at least some firms.

After some significant additional time has passed, it would be appropriate to reduce, but not remove, the section. Wikipedia, in general, does keep historical information. At some point in the future, it could be reduced to something like:

"Internet Explorer, up to and including IE8, was the only major browser not to provide native SVG support. IE8 and older require a plug-in to render SVG content. Several different plugins were made including: Ample SDK, Batik, Google Chrome Frame, GPAC, Adobe SVG Viewer, Corel SVG Viewer, Raphaël, Renesis Player, and SVG Web. Microsoft joined the SVG Working Group prior to releasing initial SVG 1.1 support in Internet Explorer 9 beta."

— Makyen (talk) 06:30, 12 March 2014 (UTC)

Page coding issue ..

Check out the "green square with a black outline" example section (Scalable_Vector_Graphics#Example). Depending on the width of the open browser window, some of the XML code appears overlayed on the green square. Obviously this is a page coding issue that needs attention (ie, the code box is not wrapping properly). JimScott (talk) 14:03, 17 May 2014 (UTC)

I moved the image so now the code in the example shouldn't overlap the image. Some may prefer to have the square appear directly below the code, without any text flowing around it. If so, they can make the change. — Frεcklεfσσt | Talk 13:03, 19 May 2014 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

• SVG logo h.svg

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 06:52, 8 May 2020 (UTC)

Structured Vector Graphics?

I've used SVGs for years and I've always known that the "S" in the acronym stands for "scalable". However, today I saw for the first time that some of the graphviz.org documentation (e.g., http://www.graphviz.org/pdf/dot.1.pdf) explains the acronym to stand for "structured vector graphics". I couldn't believe it.

So I did a Google search for that phrase, with quotation marks to be sure it would should that exact phrase. The number of results was not completely insignificant (58,600 results, as opposed to 9,030,000 for "scalable). So, I wonder, is this a common misconception or did the "S" in SVG stand for "structured" at some point in the past? --Mr. Lance E Sloan (talk) 01:33, 7 October 2020 (UTC)

I think it’s just a mistake. Even the first public draft of the SVG specification (dated 11 February 1999) called it Scalable Vector Graphics. --Zundark (talk) 07:57, 7 October 2020 (UTC)