Jump to content

Talk:SVG/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

Requires info about how to translate an SVG to SVGT (Tiny)

There is currently little or no information on the web concerning how to take a SVG (or any other vector file) and create an SVGT. How are SVGT's created? Suggest someone with knowledge add a brief overview of this means of translation...would be mighty useful!

Example Code is not code of Example

http://upload.wikimedia.org/wikipedia/commons/f/f1/Diamond-caution.svg has horrible Inkscapy source, while the example code in our page is quite readable —Preceding unsigned comment added by 213.211.163.68 (talk • contribs) 17 January 2007.

I don't know what is Inkscapy, but I downloaded Diamon-caution.svg into my directory and opened it with vi, but it looks completely different from the source displayed in the article. I would appreciate if someone explained it to the people like me. 140.129.151.35 05:52, 9 May 2007 (UTC)

I've just looked at it, and it's the same as the source shown in the article, except for a few whitespace differences. Can you be more specific about the differences you are seeing? (By the way, "Inkscapy" presumably means "containing Inkscape-specific attributes". But that was fixed some weeks ago.) --Zundark 07:58, 9 May 2007 (UTC)

Add SVG Mobiles list?

See http://svg.org/special/svg_phones

—The preceding unsigned comment was added by 213.211.163.68 (talk) 03:38, 17 January 2007 (UTC).

Already in. overlooked?!

Add the SVG logo?

It's just new, but already used on sites like W3C, SVG Open and svg.startpagina.nl I think this page should have it too See http://www.svglogo.com/finalists.html

I added the SVG logo and it was removed by User:Indolences. I would like to know why. Do other people agree that the official SVG logo will be better on the SVG Infobox than a couple of circles? There are several versions of the logo to choose from at http://www.svglogo.com and http://www.root2art.co.uk/svg_logo_download. So, if people prefer another, they can replace it. --DoSiDo 15:29, 12 May 2007 (UTC)
The logo does not illustrate what SVG can do. Similar to the HTML page, I thought an example would be best. Sure the SVG logo may be SVG based as well, but I feel the circles and basketball are a better example. -Indolences 01:34, 15 May 2007 (UTC)
The circles and the basketball do not even begin to show 'what SVG can do' in terms of animations, interactivity, scripting, styling, mixed namespaces, audio synchronisation etc. I think the official logo is as good as anything for the headline image, then we need all kinds of examples that 'really' show what SVG can do. --Nigelj 21:54, 15 May 2007 (UTC)
I tend to agree with Indolences. The illustration is admittedly rather simple in terms of the full capabilities of SVG, but for the most part an introductory illustration such as the one depicted in this article meets the general requirements. It is the graphical equivalent of Lorem ipsum to give a general audience a basic concept without overwhelming them with glitzy, cutting-edge displays of wizardry or branding initiatives. That's not to say such content is inappropriate for the article, but the introductory image displays a useful mix of basic concepts without overdoing it. dr.ef.tymac 03:00, 16 May 2007 (UTC)
I completely disagree. The SVG logo doesn't appear anywhere in wiki.riteme.site. Surely the info box on the SVG page would be the best place for it? Or are you suggesting that this logo should never be used anywhere because it doesn't contain any animations, interactivity, scripting, styling, mixed namespaces or audio synchronisation? If so, why have you replaced it with another (frankly rather ugly) image that also contains none of these features? -- Sakurambo 桜ん坊 08:35, 27 July 2007 (UTC)
Incidentally, your preferred image (Svg.svg) doesn't even contain valid SVG markup. I'm going to put the official logo back again. Sorry. -- Sakurambo 桜ん坊 08:40, 27 July 2007 (UTC)
I agree with Sakurambo that it is better to have a valid SVG file and moreover a visually pleasing one to introduce this vector format. The SVG logo does express many of SVG's features; check out the rationale for its choice at http://www.svglogo.com. I think the selection team did a good job.

Relationship with Postscript

It seems to me that SVG owes a fair bit to Postscript in terms of concepts, yet the article does not discuss this. Perhaps a section on history or scalable graphics languages predating SVG could tie SVG in with the history of the wider subject. At present the article presents SVG from a technical viewpoint, but could leave the reader thinking that the concepts used in SVG were developed from scratch when in fact they existed during the 1980s. Sangwine 20:56, 17 September 2006 (UTC)

It's certainly true that most of the graphical components in SVG (cubic and quadratic beziers, grouping, affine transforms, separate fill and stroke, reusable symbols, markers) existed during the 1980s and 1970s. Indeed, one motivation for SVG was to add industry standard graphicalfacilities to the Web. Thereare thus facilitiesin common with PostScript, also in common with CGM, GKS, and so forth (to which PostScript is also indebted). Some features, such as resolution-independent raster filter effects, are novel to SVG. I agree that a discussion of SVG needs to link into the wider world of 2D vector graphics. --Nantonos 12:56, 27 October 2006 (UTC)

Dying?

The downside to open standards is that companies would rather have a monopoly on a closed standard. Now that Adobe owns Macromedia, makers of Flash, it seems that they are going to let SVG wither and die. Adobe's SVG viewer download page, http://www.adobe.com/svg/viewer/install/ , now says "Please note that Adobe has announced that it will discontinue support for Adobe SVG Viewer on January 1, 2007." It would be great if Adobe just rolled SVG support into the Flash plugin, which would have probably been very easy from a technical standpoint, but it looks like they're going the other way instead and will not support a "competitor."

The End-Of-Life has been postponed a year. The new Adobe Mars also mentions SVG, a range of Adobe products still supports it. So Adobe is indeed focusing on Flash, but not on killing SVG (within Adobe).

Windows MetaFile (WMF) Versus Scalable Vector Graphics (SVG)

How-about some writing a comparison between these two formats -- the new standard trying to become dominant for scalable, vector images on webpages, and the existing Microsoft standard for ClipArt pictures. Which is better, for example. Color differences. Compression differences.

Well, one advantage of SVG is it is text XML, which pretty much all web developers already have the tools to output (they do it all day using HTML/XHTML) and CSS. Relatively easy to generate from scripts using already familiar tools such as PHP.
For compression differences, it would be a good idea to compress the SVG using gzip, since any web content is deliverable that way if the Content-Encoding header is set. WikianJim 08:11, 6 September 2006 (UTC)

SVG?

I got here while looking for information on SVG images after finding that my browser (Fire Fox 1.0.7) will not open them. When I click on a thumbnail for a higher resolution SVG image I get an "Open this image with AcroRd32.exe" dialog which reappears every time I click OK. My point being should not Wikipeadia be accessible by everyone without having to download new plugins or fiddle with settings? In particular this should be true for fundamental things like images. Is it not premature to adopt a new image format until the vast majority of browsers can access it straight out of the box? I feel Wikipeadia should be what it is, an Encyclopaedia, not an experimental proving ground for new technology.

All images in Wikipedia are rendered to browsers as PNGs or JPEGs for this very reason, even if the source of that image is actually an SVG one. You should be able to right-click on any image you can SEE in your browser and save the image as PNG. On the other hand, if you want the scalable image (which has infinite resolution), the SVG link is provided. On another note, I suggest you upgrade to the most recent version of Firefox (Firefox 1.5, released Nov 2005) which does support SVG, as does Opera (Opera 9 since June 2005), Konqueror (with KSVG plugin) and an upcoming version of Safari will support it out of the box (nightly builds already do). The only major browser with no built-in SVG support will soon be Internet Explorer, but you can download the Adobe plugin as you've already discovered. Jeff schiller 11:12, 1 September 2006 (UTC)
I think you missed the point. It should not be necessary to upgrade the browser or save an image before being able to view it. As the original comment said things in Wikipeadia should work with the majority of browsers out of the box. Firefox 1.0.7 is hardly an uncommon browser even if it is not the very latest version. There must be many currently used browsers that do not handle SVG images yet, so the use of such images in Wikipeadia would appear to be somewhat premature. Surely accessibility is much more important than the latest fashion in image formats.
I think you have missed the point. Wikipedia provides raster images for viewing by default (meaning EVERYONE can see the images). Everyone can also download the raster images by right-clicking and choosing Save Image As. This means anybody can see and download these images by right-clicking on them and saving them. However, if you have an SVG-capable browser, you can also download the SVG files and get the infinite resolution image (which is a feature of the SVG image). So the best of both worlds - what more do you want? Jeff schiller 00:17, 2 September 2006 (UTC)
The point is you should not need an "SVG-capable browser" to be able to access all of Wikipedia's images. Low tech GIFs and low compression JPEGs are adequate for all practical purposes. "Infinite resolution" is not a requirement for conveying useful information. "EVERYONE" cannot "see the images". Download yourself a copy of Firfox 1.0.7, open Fielding (cricket) click on the image and attempt to view the high resolution version. You won't be able to. It is irrelevant that you might right-click it and save it to view in some other program. That is really messy. The point is it should all work seamlessly in almost any browser. One day most browsers might be "SVG-capable" but until then use GIF and JPEGs. Wikipeadia should not be a proving ground for new technology.
I did exactly what you said, I downloaded the 8-month old browser and went to the cricket page. The image was visible. I clicked on the image, the image page came up (again, I could SEE the image). I didn't see a link to any "high resolution version", but I could right-click on the image and choose "Save Image As" which produced a PNG image named "448px-Cricket_fielding_positions2.svg.png" (143 kb). So:
I don't get why you state that everyone cannot see the images, I could see the image on Firefox 1.0.7 both here and here
I don't get why you say that "low tech" GIFs and JPEGs are adequate for all practical purposes and that infinite resolution is not "useful" when you yourself are actually looking for a high-resolution image
I don't get why you say that right-clicking on an image is "messy" and left-clicking is not, it seems to me like it's one extra step.
If you're happy with standard resolution on image files, then stay where you are. If you're looking to get an image with a much higher resolution, it's time for you to upgrade your browser to either Opera 9 or Firefox 1.5 (or try out Firefox 2 Beta). The only other option is for Wikipedia to have to store much larger raster image files and that costs a truckload of money.
I'm not going to argue any more on this, you're free to bring this up with the Wikipedia policy makers, but I, for one, am quite happy using modern browsers that are free, available for multiple platforms and have SVG capabilities. Good luck. Jeff schiller 10:32, 5 September 2006 (UTC)

Linked SVG file is invalid

The linked SVG file is invalid. On lines 121 and 127 it has "stroke-dasharray:### ###;". The spec says ([1]) that dasharray is comma separated, not space separated. Firefox's native SVG rendering follows the spec and ignores the rule, so the lines appear non-dashed. Can someone fix this?

Fixed it. How did you manage to find that out? Very subtle. Qutezuce 06:04, 24 May 2006 (UTC)
He probably opened it in a viewer that doesn't ignore the rule and found that it didn't work ;) Dark Shikari talk/contribs 13:20, 3 August 2006 (UTC)

files on wikipedia.org claiming to be SVG that are actually not (not conforming to the specification, not valid by validators even) are not uncommon. These files should be fixed

openclipart.org has some activity on it. Maybe an idea to cooperate?

Can anyone display the SVG image in this article?

I'm currently using Firefox 1.5 RC2 and the image doesn't display unless I press it. Anyone else with this problem?

The problem seems to be that the PNG image is not valid... Jeff schiller 13:23, 14 November 2005 (UTC)
First of all, that's not good enough. Secon of all, it's not a PNG image, it's a SVG images. Third and last, when I try to open the thumbnailpicture upload.wikimedia.org(...)Scg.svg.png it links to a PNG image, and I can't belive that exists. And when I correct it manually, it gives me 404. So is this a MediaWiki bug?
Ok, here's my experience. In the following three browser configurations: 1) Internet Explorer 6 with Adobe SVG Viewer, 2) Firefox 1.5 RC3, and 3) Opera 9 TP1, I see the following HTML source:
<a href="/wiki/Image:Svg.svg" class="internal" title="SVG example">
    <img src="http://upload.wikimedia.org/wikipedia/en/thumb/1/15/Svg.svg/180px-Svg.svg.png" 
         alt="SVG example" width="180" height="92" longdesc="/wiki/Image:Svg.svg" />
</a>
If I try to navigate to the .png link, I get a 404. This seems to be why I don't see the image at all - the PNG is not valid. The actual link should be http://upload.wikimedia.org/wikipedia/en/thumb/1/15/Svg.svg/617px-Svg.svg.png. Note that the thumbnail is 617 pixels, not 180 pixels...I can't figure out how to correct the link as I'm not familiar with images in Wikipedia.
The second problem is that Wikipedia does not try to display the SVG instead of the PNG when the user agent can. This is usually done in HTML like this:
<a href="/wiki/Image:Svg.svg" class="internal" title="SVG example">
   <object width="180" height="92" type="image/svg+xml"
      data="http://upload.wikimedia.org/wikipedia/en/1/15/Svg.svg" >
      <img src="http://upload.wikimedia.org/wikipedia/en/thumb/1/15/Svg.svg/670px-Svg.svg.png" 
          alt="SVG example" width="180" height="92" longdesc="/wiki/Image:Svg.svg" />
   </object>
</a>
In other words, the browser will attempt to display the SVG first, if it can't handle it, it would fall back to the img tag and display the PNG. This is something that would have to be done at the Wikipedia source code level, and I don't know if that support is there. There are potential problems with this since SVG images can have scripts in them that could do other things...how do you control that in the wiki environment? Anyway, I'm really interested in learning the resolution of this. Jeff schiller 15:31, 23 November 2005 (UTC)

SVG Wiki

The SVG wiki seems to be closed and I keep having to clean spam off it. Should we suspend the external link until it has migrated? I cannot find any suggestion of when that might be. --BozMo|talk 11:58, 21 Sep 2004 (UTC)

The SVG wiki was taken down earlier this year due to spam-death. It's recently been reborn and I've added the temporary link. Requires an account to edit pages. Jeff schiller 04:15, 25 October 2005 (UTC)

SVG 1.2 Full - not yet truly released

The very first line of the abstract in the current SVG 1.2 Full spec states very clearly "This specification is a placeholder for an updated draft of the Scalable Vector Graphics (SVG) Full, Version 1.2 specification.". If you further take the time to READ this document you will discover it is an outline ONLY and not a draft document available for review. Jeff schiller 03:00, 13 July 2005 (UTC)

If you follow the link to the previous versions (and so forth) you will find that the SVG 1.2 Full language has, of course, been released for public review. That particular docuent merely apologises for not making an update to 1.2 to bring it into line with the refactoring introduced inSVG 1.2 Tiny. --Nantonos 18:20, 13 July 2005 (UTC)
NantonosAedui: I agree with your updates now. Jeff schiller 19:16, 13 July 2005 (UTC)
But drafts of SVG 1.2 Full have nonetheless been released in the form of supplements to the SVG 1.1 specification. Your edit is misleading, as it suggests that this is not the case. Probably what you meant is that a stand-alone draft (independent of SVG1.1) hasn't yet been released. --Zundark 07:20, 13 July 2005 (UTC)
Yep. Jeff schiller 19:21, 13 July 2005 (UTC)

Wikipedia support

Just a note that I've added info that Wikipedia currently support SVG. - Ta bu shi da yu 07:37, 11 October 2005 (UTC)

See commons:Category:SVG for examples of SVG that have been uploaded. LoopZilla 09:00, 11 October 2005 (UTC)
Is it accurate to say Wikipedia "supports" SVG? From what I've seen so far, it's not possible to edit the SVG and only PNGs are displayed to the actual user in an article. Can anyone point me to a resource that describes Wikipedia's present and plans to support SVG? Thanks. Jeff schiller 15:46, 23 November 2005 (UTC)
Also, I notice that at any SVG image page (like http://wiki.riteme.site/wiki/Image:Orc.svg) that the MIME type listed is "image/svg". This is not the proper MIME type for SVG, it is "image/svg+xml". Jeff schiller 15:50, 23 November 2005 (UTC)
But when you click on the .svg link, the SVG is sent with "image/svg+xml".

Resizable SVG?

All, when looking at SVG images, such as [2], the browser renders the SVG in a fixed size. I think this is because of the fixed size attributes in the <svg> tag: 

  width="493.28000pt"
  height="252.89000pt"

Compare this to [3] which will resize to fit in the browser window. I think this has something to do with the "viewbox" attribute, because setting a 100% width and height alone doesn't seem to do it. Is there a generic way to get the SVG items uploaded all resizeable? How? I'm not very experienced with SVG, so any advice would be helpful. Thanks. --ChrisRuvolo (t) 21:41, 7 December 2005 (UTC)

If your image has
width="400" height="300"
in the 'svg' tag, change it to
viewBox="0 0 400 300"
The viewer should then scale the image to fit the viewing area. (Note that the width and height you gave above are in points and would need to be converted to pixels first. Also note that it's a 'viewBox' attribute, not a 'viewbox' attribute.) You don't need to explicitly set width and height, since they default to "100%" anyway. --Zundark 09:41, 8 December 2005 (UTC)
I see. that seems to work pretty well, thanks. So, is this something that we want to do for all SVG images? Is there any disadvantage with this? Thanks. --ChrisRuvolo (t) 13:52, 8 December 2005 (UTC)
Unless there's a reason to specify a particular size for the image, then I don't see any disadvantage. Inkscape used to handle viewBox badly, but this is supposed to be better in version 0.43 (according to the release notes; I haven't tried it myself yet). --Zundark 14:20, 8 December 2005 (UTC)

Using a viewBox rather than a fixed width and height is what the SVG specification recommends. --Nantonos 18:43, 8 December 2005 (UTC)

The wikimedia SVG -> PNG renderer doesn't do the right thing in this case. See Image:Hudson County, NJ municipalities labeled.svg (expected results are Image:Hudson County, NJ municipalities labeled.png). It renders 256x256 despite the viewBox attribute. --ChrisRuvolo (t) 23:02, 9 December 2005 (UTC)


The GIMP

I am unable to export images as SVG in the latest build of the GIMP (2.2.10 on Windows). If this is indeed possible, please describe how to do so here. Thanks, Jeff schiller 14:15, 18 January 2006 (UTC)

  • The process is a wee bit not-well-explained if you're trying to Google for it. GIMP Documentation has it hidden in the places you don't look. After you draw paths (note: you CANNOT export your normal ol' raster pics to SVG in the GIMP), click the "Paths" tab, and merge the ones you want together. Then right-click that merged layer and select "Export Path..."; the rest should be obvious. ...think I'll edit the relevant section of the article now. 68.100.68.23 04:04, 26 January 2006 (UTC)

SVG help

Hello,

I'd be appreciate any help with the following please:

1) Creating an SVG pink/light blue yin and yang symbol. I've tried, but it doesn't scale correctly.

2) Locating a good copyright free SVG butterfly. This is the best one I have found, but I'm unsure as to whether or not I can use it in Wikipedia:

http://www.croczilla.com/svg/samples/butterfly/butterfly.svg

(Both the butterfly and yin-yang symbols are used by the transgender community).

Thanks !

Dlloyd 22:52, 25 January 2006 (UTC)

The Open Clip Art Library might be of help. heycam 01:13, 4 February 2006 (UTC)

Misc stuff

I want tell everyone that if you want an SVG image, you can get them at http://www.openclipart.org (public domain). Also, if you want paint SVG image, you can do so with Inkscape (free, open source) software. Also, I would request someone make an SVG image of Star of Life and preferably put it under public domain.

Native support

I think that the SVG#Native_support subsection could be expanded a bit to describe which browsers support which options for using SVG in webpages, as described in the SVG 1.1 Specification, Section 2.3. Unfortunately, the browser docs that I have perused do not make this terribly clear. Thoughts? Mpd 15:29, 24 February 2006 (UTC)

Please see Comparison of Layout Engines (Graphics) for a detailed description of what engines support which SVG features. I have now added a link to the Native Support article... Jeff schiller 16:00, 24 February 2006 (UTC)
Ah, just re-read your comment/question and checked the section in the spec. This is, indeed, an interesting bit of knowledge that people will want to know about. My own experimentations have shown that Firefox 1.5 and Opera 9 TP2 allow: Standalone, Embedding by reference (HTML:object only, no HTML:image), External link via HTML:a. CSS property from HTML are not currently supported unfortunately. Embedding inline (XHTML) is supported but I have not experimented with it. Jeff schiller 16:04, 24 February 2006 (UTC)


Commercial Products

I noticed an anonymous contributer from IP addresses 84.4.43.144 and 84.4.41.76 has been removing links to commercial products that support SVG. Is this against Wikipedia policy? I don't see the harm in having a list of popular commercial products that support SVG, but I have no problem with removing them as long as links to the proper Wikipedia policy item can be put in here. Thanks, Jeff schiller 13:18, 9 March 2006 (UTC)

Probably some copyleft or open source zealot. No reason to remove them. --ChrisRuvolo (t) 13:52, 9 March 2006 (UTC)
You are funny. Remember: Wikipedia IS open source! See reasons below. Look also at the guidelines Spankman

SVG Search Engine

Just wondering: is there a google-images-like search engine that allows you to search for SVG images only? This would be a major help as I am trying to replace all images tagged with {{BadJPEG}} with SVG (or PNG) equivalents. Thanks, -Reuvenk[T][C] 02:10, 27 March 2006 (UTC)

If you add "filetype:svg" to your google search the search will be limited to svg files. But this may not be of great help, I think it only matches words found in the file name or inside the svg file. Qutezuce 02:45, 27 March 2006 (UTC)

Problem displaying SVG image correctly in firefox 1.5

Hi, I just uploaded the new figure Image:Weighted_K4.svg to the Commons, created using xfig. But when displayed by the MediaWiki software using firefox 1.5, only the nodes, letters and numbers are shown, but not the straight lines. When I click on the image, I get a correct display. Is this a known problem? If so, is it specific to firefox or is it a general problem? What should I do in order to include the image in an article — use it as it is or upload a png-version and mark the svg image as redundant? Thanks in advance, -- Sebdo 18:42, 17 April 2006 (UTC)

When you click on the image Firefox is rendering the SVG, but before that you are seeing a PNG image that is generated on the wiki servers, I believe by ImageMagick, so this probably indicates a problem with ImageMagick's SVG rendering. Qutezuce 21:25, 17 April 2006 (UTC)
Ok, I will use PNG images then until the problem is fixed. -- Sebdo 19:16, 18 April 2006 (UTC)

User:Booles had made several edits to this page removing some external links that involved commercial products as well as websites surrounding SVG (including one or two dead links). I had reverted these changes based upon my understanding that, in a list of software that supports SVG, we should not be discriminating against commercial products. Today I received feedback from User:Spankman that I should not have reverted these edits, citing that Wikipedia guidelines state: "the list of external links must remain small, and links to commercial products must be avoided".

First, using "must" in a "guideline" seems rather odd. I went searching but I am no Wikipedia policy/guideline expert here. The best I could find was this which states that external links should normally be avoided to "Sites that primarily exist to sell products or services" and "Links that are added to promote a site". This seems to imply that links to sites that exist to give away free products (i.e. open source products) are ok, which seems discriminatory to me.

Anyway, I then looked at the article and I have to admit that the external links section has gotten rather large. Also, the Toolkits section contains a great deal of external links also. Presumably this growth in links is due to the overall up-take of SVG in the mobile and desktop web spaces, so it seems logical that this has happened. The question is how to trim down/clean up the article in a fair way? I think it is still incredibly useful to SVG newcomers if they learn which products support SVG and this should include commercial products. The lengthy list of links also serves to somewhat validate SVG as a technology, so I'm a little biased here. I'd appreciate any input. Jeff schiller 21:19, 3 May 2006 (UTC)

This is certainly useful to have a list of commercial products, but the point is that Wikipedia is not the place to do that. "Zealots" of open source are also zealots of wikipedia that is open source and that is not a directory of software. If really you want to know all the commercial products around, you have the usual link to Dmoz, that is permitted by the guidelines and that should list all products related to SVG in order. There is a good reason to restrict links to open source software: source is informative, give us some knowledge of the technology. Commercial product doesn't. The other excellent reason if that if we accept links to commercial product, the page will be invaded by lots a links and becomes a directory of software, not the goal of Wikipedia. There is absolutely no doubt about that, commercial links MUST be removed. Spankman
Then you'd better head over to Microsoft Windows and clean it of commercial links. It's so blatant that there is even one commercial link right there near the top of the article in the infobox. That article is riddled with them, it's disgusting. Qutezuce 07:27, 4 May 2006 (UTC)
Possible, but I can't maintain and purge the whole wiki. Spankman 17:15, 4 May 2006 (UTC)
Spankman, first, I agree that the list could be trimmed down and I'm looking for useful suggestions towards that effect here. Second, can you please provide a link to the wikipedia policy/guideline document that says commercial links must be removed? Thanks, Jeff schiller 13:02, 4 May 2006 (UTC)
First of all, look at Wikipedia:External_links#What_should_be_linked_to. Sites that delivers commercial products can't enter the list and even the second list... A product is not a content. Thus, if they don't enter these lists, they should not be linked. Secondly they fall into the category "sites that exist to sell a product or service" because they have nothing else to propose. And such sites must be avoided according to the instructions. More, "Sites with objectionable amounts of advertising": the whole site is an advertisement for a product. More, "Sites that require payment to view the relevant content": you need to pay to use (view) the product. Do you need for more reasons? Apparently you want to shrink the section of external links but without eliminating these links, do you want keeping only commercial products here? Spankman 17:26, 4 May 2006 (UTC)
Spankman, do not put words in my mouth. In my latest excerpt, I merely asked for Wikipedia policies of the "MUST NOT" variety. This is for my own education, not to prove anything to anybody. What you have offered (and what I have been able to find) were guidelines which, by their nature, should not to be blindly followed at all costs. There could be valid exceptions to guidelines.
My original statements on this issue reflect my feeling that providing a list of products (commercial and non-commercial) may be useful information for people wanting to learn about or consider development in SVG. You may be under the impression that I want to protect certain links that I have vested interest in. This is not the case. My only interest here is in the success of SVG as a technology, which I feel depends on adoption of viewers, tools, frameworks, and developer interest. I'm an open-source and "free software" fan too, but if the list of supporting products is shortened, it may appear that SVG is not as successful as it is, or that adoption in the marketplace is stalling. However, if there is a dmoz page already set up, then let's go with that and link to it here.
Finally, while I will agree that the primary purpose of a website for a commercial product is in advertising and selling that product, those websites also can and do often offer developer and user support forums and evaluation versions of the software. Maybe these can also be linked to in a dmoz-type page? Jeff schiller 19:29, 4 May 2006 (UTC)
You are wrong on each point. If a commercial website has a forum or any valuable content (for us), put a link on that, not on the description of the commercial product.
You have written: "it may appear that SVG is not as successful". This is really not our problem. The goal of the Wikipedia is to EXPOSE, not to CONVINCE. They may believe whatever they want providing we have delivered the right information.
Valid links must point out additional information to complete the article here. A commercial website has promotional content and not valid information.
Read the discussion in the Village.
Spankman 12:39, 5 May 2006 (UTC)

Hi Spankman, based on this

More, "Sites with objectionable amounts of advertising": the whole site is an advertisement for a product.

I have decided to remove all internal links from this article, as every one of them links to another Wikipedia page that is full of advertising for Wikipedia (the whole Wikipedia website only exists to be advertising for its own free encyclopedia). Qutezuce 19:44, 4 May 2006 (UTC)

Quite interesting. However Wikipedia provides information for free while these sites SELL products. Splang 07:34, 5 May 2006 (UTC)

Still an advertisement whether or not they sell anything. So if money changes hands, thats inherently evil, right? Qutezuce 08:03, 5 May 2006 (UTC)
There are guys here that are not able to see a difference between information and advertisement. So they read the Walmart catalog when they need for some info in the Encyclopedia Britannica. Spankman 12:31, 5 May 2006 (UTC)
Yeah, I was looking in the Walmart catalog the other day and it's biography of Benjamin Franklin was pathetic. I sent them a letter.
Apparantly you are on of those that can't tell the difference between information and advertisement. A website for a free software project is inherently advertisement, it's advertising the free software product. The creator of the project may even reap financial benefits from such, if they use that website to promote themselves when looking for a job.
If you are looking for information on what products are available for purchase, then the Walmart catalog is a very good resource for such a thing. In fact it would be pretty hard to find any resource giving such information that wasn't selling something. Qutezuce 20:23, 5 May 2006 (UTC)
There is a lot of open source software for SVG. A source code is a valuable content, so we can link to them. Walmart and such catalogs are good to purchase products, so, read them to obtain lists of available products. Here, this is an encyclopedia and not a catalog. Oh! You are using Firefox! Spankman 06:15, 6 May 2006 (UTC)
Probably less than 10% of people come to Wikipedia looking for source code. The other 90% are only interested in tools they can use for SVG, providing a list of useful tools (with or without source code) for SVG is valuable content to those 90%. Qutezuce 06:21, 6 May 2006 (UTC)
I agree that the majority of people is not interested in sources, but this is valuable content. If we have free, complete, good free products (usually open source) why to add links to commercial products? Once again, Wikipedia is not a directory, Dmoz is. Spankman 07:01, 6 May 2006 (UTC)
Since the companies making the commercial products have not gone bankrupt there are obviously users of their products who think that the commercial products serve their own needs better then the completely free alternatives. It's not our place to tell someone to use free or commercial software, they can make their own choice depending on their on needs and philosophies. Qutezuce 07:07, 6 May 2006 (UTC)
Not a place to choose software too. 84.6.38.64 09:46, 7 May 2006 (UTC)
So if source code is only useful to a tiny minority of people, then why should this page become a web directoy of SVG related source code? As you said before that is what dmoz.org is for. Qutezuce 20:17, 7 May 2006 (UTC)

Perhaps links should be included to the wikipedia pages concerning the relevant software. The fact that the de facto standard software (Adobe illustrator) in graphic design supports SVG is important information regarding a graphics format. I would consider attempts to limit referances to purely open-source software over commercial software to be extremely POV. Personally I am a strong advocate of OSS and wish i were able to use something other than Illustrator but for my job it is simply not possible. The role of wikipedia is to provide the way the world is, not the purely OSS world that you wish it were. While you may object to commercial software you should not let that political belief affeect your editing of wikipedia. 62.49.1.131 00:05, 20 July 2006 (UTC)

Proposal to split

I propose to split this page with a such long list of external links and to create another page dedicated to demos, cliparts, example. A such page should not be a single list of link but must add descriptions of the demos with some info about the way they has been built. Waiting for your advices. Spankman 06:31, 6 May 2006 (UTC)

Removing the themes

Links to themes for Linux should put in Linux articles instead. We should not link here anything that use SVG or the page will become gigantic. Spankman 06:59, 6 May 2006 (UTC)

Created SVG Tools

Without to refuse proposals by Spankman above, I have created a new page of tools for SVG, in the model of other articles at Wikipedia, to reduce the size of this article that is too big and has a serious problem with external links. Booles 06:35, 8 May 2006 (UTC)

http://svg.startpagina.nl is only links, but quite a resource nevertheless. It's 99% english

Greetings, new here, please excuse format errors. Why are SVGX and SVGI, SVG Implementations being removed form resource area? cheers

Because there are too much links, and these one have no real content. But you can make a proposal for adding them in this discussion page. Users will judge and decide. Spankman 13:21, 27 May 2006 (UTC)
Implementations directory at svgi.org, what is the problem? Please note at http://www.w3.org/Graphics/SVG/ ,SVG Implementations is at SVGI.
I have found nothing about SVG. Can you put a link to a page rather than to the root of the site? HHaskell 09:47, 8 June 2006 (UTC)

PNG is still better

My example shows that PNG is superior. Compare this with the article's SVG example. renegadeviking

31.35 KB

The PNG image has limited resolution. You can compress svg files into svgz format. Using this I get a filesize of 23.8kb. Qutezuce 21:42, 24 May 2006 (UTC)
The key advantage with SVG is it's a vector format not a raster format. It is therefore resolution independent. With the original SVG, I could print a banner the size of a football field or even an American football field and it would still be sharp. With your crappy PNG, this would not be the case. I could also edit the SVG in many ways which could not be done with your crappy PNG. It's trivial (relatively) to rasterise a SVG. On the other hand, converting a raster file format in a vector is a very complex process known as OCR trace that doesn't work particularly well. In any case, as Qutezuce has pointed out, you're comparing apples with oranges. SVG is in XML and uncompressed. PNG is a compressed raster format. If you want to compare SVG to PNG, you should at least compress the SVG. Nil Einne 22:03, 19 June 2006 (UTC)
I did a quick and dirty comparison to show the difference. Also for clarification, my references above to your crappy PNG was only intended to explain my view of the file you created, and is not intended to cause any offense to you.

Nil Einne 23:07, 19 June 2006 (UTC) Why do you say 'crappy png' so many times in that comment? There's nothing wrong with pngs, for many purposes they are better then svgs... eg you don't always want nor need a picture that's scaleable to any resolution. They're for completely different purposes, so I don't see how anyone could call either format crappy =/, seems almost flamey to me. Themania 11:49, 19 October 2006 (UTC)

Using SVG images

I didn't know where to ask this so I am going to put it here. I have created a replacement for [4] at [5]. Do I have to get permission from anyone to start replacing the PNG images with the SVG one?

You shouldn't be replacing the image. Just replace all links to the image... You don't have to get permission. It probably would be polite to inform the content owner but there is a clear policy in favour of vector SVGs so permission is not necessary. Nil Einne 22:05, 19 June 2006 (UTC)

Advantages, uses

I think the article could use some information on what SVG is and will be used for, what advantages/disadvantages it has compared to competitors. For example, is it going to be used for gif and png type images or will it be used for jpg or even tiff type images? -- Kjkolb 19:45, 29 May 2006 (UTC)

I think you have misunderstood what a SVG is. Perhaps try reading the article again. SVG is not directly replacing any of these formats. It is a vector format not a raster one. However many people have been rasterising vector content due to the lack of a suitable format. Vector formats are far more suitable for diagrams and the like. Nil Einne 22:07, 19 June 2006 (UTC)
I reread the article but I still didn't find comparisons with other formats, advantages and disadvantages and such. In contrast to the other articles on image formats, like JPEG, PNG and TIFF, I don't think that the article explains what it is, how it works and what it is used for in a manner that most people can understand. -- Kjkolb 08:41, 24 June 2006 (UTC)
They are fundamentally different image types. Compare raster graphics and vector graphics. PNG, JPEG, and TIFF are all raster graphic formats. SVG is a vector graphic format. --ChrisRuvolo (t) 18:12, 25 June 2006 (UTC)

Editor Transparency

Greetings, why do certain editors(here), who wish to control(vender related?), hide behind screen names, do not provide email contact information? Transparency is good. -- Mpbolger 12:44, 02 June 2006 (UTC)

I agree to some extent, but unfortunately this information can be used for harassment. Some good Wikipedia contributors have been harassed into leaving the project using information available about them on Wikipedia and elsewhere online. The lack of transparency, in the form of real names, hurts us when it comes to people's perception of Wikipedia's reliability, though. -- Kjkolb 23:35, 2 June 2006 (UTC)

Article displays improperly

the box containing the second, larger image displays improperly for me under both Firefox 1.5 and internet explorer, althought the display problem is to a different extent. The second box obscures the bottom half of the second line of text in the third paragraph (it has 2 lines all the way across before it goes to narrow columns)

Basically, it should only have 1 line full width, but it has a second one thats obscured behind the box

example: 

#####################
############"""""""""
##########  |       |
##########  |       |
##########  |-------|
(where # is text, " is the top half of text, and | and - are a box around the image )

I've had a look at the source, and messed it around a bit in preview, but cant seem to figure out exactly the cause.

Kaldosh 09:23, 3 July 2006 (UTC)

This is a problem with any article that has 2 images in the same way, and unrelated to it being in SVG. does anyone know where a better place to note this would be? Kaldosh 17:05, 15 July 2006 (UTC)

Searching for Text within a SVG that is in the wiki

Hello, 

I am not sure, if this is the right place for the following question. 
If not, please redirect me to the right website. Thank you.

I am looking for a way to describe processes of a company. For this reason we want to use activity diagramms containing boxes and diamonds. Those diagrams need to have text inside (ie describing the boxes and diamonds).

Now I am wondering:

Can I create SVG graphics, place them in a mediaWiki and search the Wiki for the text inside?

Best regards,

Thomas —The preceding unsigned comment was added by Thbaero (talk • contribs) 19:11, 26 July 2006 (UTC)

I don't think that you can search for text within an svg image on Wikipedia. But what does that have to do with making activity diagrams for the company? Althepal 04:00, 6 March 2007 (UTC)

No Nazi Flag

In some countries this flag is forbidden by law - and there are good reasons for that. I think, it's okay to show the flag in a book about history, but not just for fun in this article. That's not funny! —The preceding unsigned comment was added by 84.168.130.195 (talk • contribs) 12:05, 28 July 2006 (UTC)

I am opposed to using the Nazi flag in an inappropriate manner. I do not think that there is a reason that the Nazi flag would be more useful for this article than any other symbol or image, and if there is not such a reason, it should be removed (I think it has already been removed, as I did not see it). However, I am strongly opposed to giving into laws against displaying Nazi symbols or symbols of any other type (like communist or terrorist symbols). Many things are banned in various countries, like the pictures we have of reproductive organs and the pictures of women whose bodies are not completely covered below the head. Even written information and covering certain topics is banned in some countries. For example, China blocks access to sites that have negative, but factual, information about it, and it also blocks sites that have content on the Tiananmen Square protests. We should only obey those restrictions that absolutely must be obeyed or we will be fined, sued or shut down (if we are out of the threatening government's/court's jurisdiction, we should still refuse, unless it would cause us serious problems, like if it is the U.K. who is complaining and Wikimedia board members would have to stay out of U.K. countries and their ISPs would have to block Wikipedia). Of course, we should not try to provoke a fight and should only use offensive symbols when it improves an article (actually, content of any kind should not go into an article unless it improves it). -- Kjkolb 10:51, 9 November 2006 (UTC)

SVG and wikis (original research)

The claim that The wikis that do not rasterize SVG images choose not to because rasterization using Batik is CPU-intensive and requires Sun's Java Runtime Environment, which is not free software. Besides the alleged original research, I would erase the requires Sun's Java Runtime Environment, which is not free software. There are other free VMs and Java libraries than Sun's. Hervegirod 16:17, 23 September 2006 (UTC)

But at the moment Batik doesn't run properly on the other VMs + GNU Classpath, so it's probably a reasonable claim that it requires Sun's VM. (Although I haven't tried IBM's...) heycam 02:26, 24 September 2006 (UTC)

Interactivity examples

Do you think some examples of interactive SVG's could be put into this article? Just a suggestion. 'FLaRN' (talk) 00:15, 19 November 2006 (UTC)

SVG not supported natively in Firefox 2

I changed the native support area from suggesting that SVG is natively supported in Firefox, to suggesting that SVG is natively supported in Firefox 1.5, because it isn't supported in Firefox 2. --—The preceding unsigned comment was added by Zeotronic (talk • contribs) 4:44, 22 November 2006.

That's not true, though. I've got Firefox 2 installed (well, Iceweasel :)) and it does indeed have native SVG support. --heycam 22:24, 22 November 2006 (UTC)
Well, let's try and get a reliable source to cite and fix the article one way or the other. Who knows their way around the Mozilla project's web sites? --Nigelj 18:17, 23 November 2006 (UTC)
Here's one you could use: http://developer.mozilla.org/en/docs/SVG_in_Firefox --heycam 22:49, 23 November 2006 (UTC)
Thanks for that, heycam - fixed in the article. It looks like Zoetronic was just trying to spread a little FUD ;-) --Nigelj 20:29, 24 November 2006 (UTC)

Orc image - and others

At 00:23, 25 November 2006, FrostyBytes deleted the orc image with the comment, "removed orc svg image - inappropriate in this particular article." I disagree, the image is quite professionally made and IMHO was very useful in showing an aspect of the flexibility of SVG: it is not only limited to creating plain diagrams and simple logos but can be used to produce complex, semi-realistic images. I would like it re-instated.

We also need more good SVGs showing other artistic capabilities - e.g. fancy typography following curved paths with shadow and 3-D effects, animations etc in my opinion. --Nigelj 09:57, 25 November 2006 (UTC)

The orc image is indeed effective in displaying the artistic uses of vector graphics in general. I still do not think that it should be displayed in this particular article, though it wouldn't be very far out of line. It would, however, be very useful in the vector graphics article, which I believe should be used for discussing the usage of vector formats in general; I would think it preferrable that this article focus on the details of the SVG format itself.
How about a brief mention of the uses of vector graphics, but deferring to the vector graphics article for detailed explanations of that subject? Maybe a sub-header in the Overview section?
A few of the images in the vector grahpics article are redundant; I think removing some of them and replacing with the orc image would be a good idea, so as to keep clutter to a minimum. -FrostyBytes 10:27, 25 November 2006 (UTC)
Maybe a more common drawing? I sure as heck don't know what an "orc" is. Perhaps a sloth or some other silly real animal? Also the idea of having different kinds of text... I like that. Similar to what I have on my userpage: --Indolences

My Computer Cannot Open SVG Files!

Does anyone know why?--Vintei 18:02, 24 December 2006 (UTC)

Because you haven't got an SVG renderer installed? --Zundark 20:32, 24 December 2006 (UTC)
What's that?--Vintei 23:55, 24 December 2006 (UTC)
Software that can render SVG images. If you want SVG files to display in your browser, you either need a browser that handles them natively (e.g., recent versions of Firefox or Opera), or you need a plug-in that can handle them (e.g., the Adobe SVG Viewer for Internet Explorer). --Zundark 09:15, 25 December 2006 (UTC)

Okay.Thanks a lot.--Vintei 18:01, 25 December 2006 (UTC)

If you want to save svg files and view them in a program, GIMP will support them. Batik is special for SVG. Inkscape is an awesome, free SVG tool which can view and edit SVGs. Althepal 03:50, 6 March 2007 (UTC)

Image in the infobox

It seems that this image contains elements that are not pure SVG as defined in the standard. There are some sodipodi and inkscape namespaces (sodipodi:rx, etc...) which can not be read by other SVG browsers, I think. It seems this problem concerns only the ball, the other parts of the image are OK. Hervegirod 19:05, 7 January 2007 (UTC)

Yes, the SVG markup is a mess. Validating it against http://jiggles.w3.org/svgvalidator/, it first fails to parse with a fatal XML error over an illegal and wrong namespace declaration ("xml"). When this is removed, we are left with 23 SVG validation errors! It's amazing it displays at all. There's clearly lots of repetition and WYSIWYG junk in there too. I'll have a go at fixing it bit by bit, by hand, over the next few days, but - no promises. --Nigelj 21:59, 7 January 2007 (UTC)
I don't see anything anything incorrect about the SVG file at all. What do you mean by an "illegal and wrong namespace declaration"? It's exactly the right namespace declaration for "xml" (which makes it redundant, but not wrong). And all the other "errors" are also not errors: the validator is complaining about declarations of namespaces that aren't mentioned in the SVG spec, but such namespaces are allowed - it's pretty much the whole point of having namespaces - and there are even examples of SVG files with such namespaces in the SVG spec (e.g., the example in section 21.3 - which the validator also complains about). Software that checks SVG files for conformance should remove such things before doing XML validation (see Appendix G.2 of the SVG spec). In short, I don't think this validator is very good. (But I agree that all the Inkscape cruft should be removed from the file - the file should serve as an example, and the cruft obscures things. An easy way to remove it is to load the file in Inkscape and save as Plain SVG. I can do this if you like.) --Zundark 10:05, 8 January 2007 (UTC)
OK, I tidied up the file. Now http://jiggles.w3.org/svgvalidator/ no longer complains about it, and it also passes XML validation at http://validator.w3.org/. It's also more readable, but could still be improved in that respect. --Zundark 12:02, 8 January 2007 (UTC)
Thanks User:Zundark for both the work on the file and the citations. Perhaps some of these points should be mentioned in the article, since this issue is likely to come up again. dr.ef.tymac 15:23, 8 January 2007 (UTC)

SVG in MS Internet Explorer browser v7

I can not see SVG images in MSIE 7. I was fooled by the png images substituted by wikipedia on the article page and on the image page. --Timeshifter 18:36, 17 January 2007 (UTC)

Well yes, as the page says you need a plugin 203.109.240.93 12:14, 27 January 2007 (UTC)
I am having the same problem. I just downloaded the Adobe plugin, and when I go to properties on right-clicking the image, it shows a link to a .PNG image.—King Bob324 14:22, 3 June 2007 (UTC)

MediaWiki automatically converts SVG files to PNG, probably based on the user agent string. Since no version of IE as of yet supports SVG natively it probably delivers a PNG to IE regardless of the plugin. — Sam 14:40, 3 June 2007 (UTC)

Need help with faulty svg...

Hey there. I hope this is the right place to ask this. I have been having trouble with making svg map files. I have uploaded one image as an example. The image views fine as a thumbnail and as smaller versions, but when you click on it to view it full size, it crashes Firefox, and IE7 only displays the coding. This image was created originally with ArcGIS and edited with Inkscape. Can anyone help me on fixing this or point me somewhere to a fix? I would sure appreciate it. 25or6to4 18:27, 24 January 2007 (UTC)

This file is big. I expect that is why it crashes FireFox. The reason why it is big appears to be due to three factors:
  1. Each road line on the map is actually composed of many tiny line segments that overlap each other.
  2. Each road line segment contains many data points, far more than would be needed viewing at any reasonable resolution.
  3. Some road lines have multiple lines on top of each other that will not be seen by the user, but taking up file space and rendering time. Example: the red line is over a blue line, which is over an orange line.
I don't know if the ArcGIS SVG export has options to tune these factors, but if possible, you should tune it there. If not, you might be able to fix it in Inkscape through some tedious work. First delete all segments that are not visible. Then select all the segments in each line and join them. Then you could smooth the line (possibly several iterations) to remove the extra data points. I hope this is helpful. BTW, IE7 doesn't have SVG support. --ChrisRuvolo (t) 19:21, 24 January 2007 (UTC)
My attention to detail was my downfall. I have found a better source with less points, and re uploaded a new file. It opens in Firefox now. And I completely forgot IE7 didn't support it. My bad. Thanks for the help! 25or6to4 14:44, 26 January 2007 (UTC)

Are SVG's fractals?

Are SVG's fractals? Fractals have infinite detail. So if you scale up an image and still see a smooth curve, isn't that a fractal? --C7796E2C 02:10, 4 February 2007 (UTC)

No, as written in the wikipedia article about fractals : a fractal is a rough or fragmented geometric shape that can be subdivided in parts, each of which is (at least approximately) a reduced/size copy of the whole. Hervegirod 11:17, 4 February 2007 (UTC)

Trouble printing svg

Using Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9 Under XP, home edition.

I have confirmed that many of the svg images (files) use a transparent background, so that the background color of the image is tha same as that of the page as a whole. This displays perfectly in my browser; when I print the image, however, the background is solid black, losing, in many instances, text printed in black. Images that are not svg do not seem to have this problem. (But I have not tried images with transparent layers.)

I first encountered the problem when attempting to print the images at Pentomino. In addition, color shadings were often lost.

I don't know whether this problem is due to the svg coding, the svg protocol, Windows XP, Firefox, the printer settings, or whatever. And I am entirely too busy at present to investigate it. I do think, however, that someone should look into it.

Too Old 06:55, 11 February 2007 (UTC)

I've seen similar results printing transparent GIFs on Firefox. Perhaps this is fixed in a FF 2.0? --ChrisRuvolo (t) 16:24, 11 February 2007 (UTC)

Seems to be a known bug with FF 1.5.. Think I'll switch to FF 2.0 Too Old 06:24, 22 March 2007 (UTC)

This is just a tad ridiculous, wikipedians.

Just as a question, why the hell are all images on wikipedia being converted to the .svg format?

I know the benefits already: vector graphics, higher quality images, no artifacting, etc. etc. But many people, especially IE users, do not have the means to save or edit .svg files. In addition, a number of people are having trouble with printing .svg images. Until .svg files are adequately supported by all systems and browsers, I think, we should stick to the .png format. Should we discuss any of the problems with .svg files in the article, or not?

That being said, does anyone have the flag of Denver, Colorado in .png format? Just a question. 76.18.140.105 18:17, 14 February 2007 (UTC)

Why don't you just use the PNGs that Wikipedia generates for the actual pages? For IE users, you should be able to just right-click or control-click and select the menu item to save. Here's the link I pulled for an PNG for the Denver flag. I still don't see the problem. While not perfect, the system seems very flexible in its current state, and I see no reason to do away with SVGs. Dancter 18:36, 14 February 2007 (UTC)
Yeah. And if an image is in svg, all you have to do is go to the sandbox, and type [ [ Image:IMAGENAME. svg|1000px ] ] (remove spaces). By adjusting the pixel size, you get pictures AS BIG AS YOU WANT in png format, ready to save as Dancter said. Althepal 03:46, 6 March 2007 (UTC)
Internet Explorer has a plug-in to support SVGs, you know (I think it is Adobe SVG viewer). But you should use Firefox anyhow: it is much more secure and isn't plagued with spyware cookies like IE is. Althepal 03:47, 6 March 2007 (UTC)
There is nothing ridiculous about it. To use "IE users" as a group of people who can't edit them is "a tad ridiculous". No browser has SVG editing capabilities, and IE does have the ability to save SVGs just as any other browser does (right click, then click "Save target as..."). I really don't see whatthe issue is when they get converted to PNGs on Wikimedia projects (therefore browser support is irrelevant, other than PNG support). And with regards to editing there is a fantastic free SVG editor available for all major platforms (Inkscape). I am currently an IE7 user and see no issues, in fact I've contributed a number of SVGs made in Inkscape (e.g. the alert sign (with the "!") in the article used as the code example).
If on the other hand, you were referring to some inability to get a vector editor (e.g. restricted resources) then the same can be argued for PNG - Paint's PNG support is adequate at best, but nowhere near complete: it does not support alpha channel, or proper compression. Therefore Windows users who just want to edit PNGs properly, also require additional software.
Also, I'll just add that if you want to continue your request to stop conversion to SVGs, this is not the place for it. Try meta:SVG image support - EstoyAquí(t • c • e) 13:27, 17 June 2007 (UTC)
I'm sorry to bother you, but by my reading, replacement of PNG images by SVG images is a violation of the GFDL license version 1.2 (see here for the text). PNG is a generically-editable or "transparent" version (as per Section 1 "Applicability and Definitions"), and SVG is a non-generically-editable and therefore "opaque" version (same section). If that is correct, then replacement of PNG by SVG images would be a violation of Section 3 ("Copying in Quantity"). I appreciate that many of the arguments have revolved around whether SVG is better than PNG. But it seems to me that it is definitely against the spirit of GFDL (a generically-editable image is being replaced by a non-generically-editable image), and, if my reading is correct, an *actual* violation of the GFDL license. Wikipedians who doubt this may wish to read the text of the license and make up their own minds. Thank you for your advice, User:Estoy Aquí, concerning where to take this: I will certainly do so. Regards, Anameofmyveryown 17:01, 10 August 2007 (UTC)
Not even close. In section 1, "XML using a publicly available DTD" is given as an example of a "suitable format for Transparent copies". As I'm sure you know, SVG is an open standard and meets these requirements easily. --ChrisRuvolo (t) 21:53, 10 August 2007 (UTC)
Thank you for that, User:ChrisRuvolo. You are of course correct: a closer reading of section 1 reveals that "Examples of suitable formats for Transparent copies include...SGML or XML using a publicly available DTD...". I still have issues over PNG->SVG conversion (not least that I can't edit SVGs!) but it seems that the GFDL vio argument is lost. I will just have to pursue my claim to be the sole legal inheritor of Manhattan instead :-). Kind regards, Anameofmyveryown 22:39, 10 August 2007 (UTC)

Bad SVG support in Wikipedia

I've noticed several SVG images that wikipedia has problems with. Hebrew letters don't seem to show up on wikipedia (though letters could be transformed to path before uploading). Some files don't show parts of them smaller than a certain size on Wikipedia, even when those files are fine in Batik, like Image_talk:Winvista.svg. And when wikipedia downsizes an svg, it is not as smooth as when downsizing pngs and gifs. Althepal 03:55, 6 March 2007

Could it be the font that you're using for the letters? I know there are some standard fonts that Windows ships with, that Wikimedia doesn't support (I'd say there's Mac ones too). AFAIK it's 'supposed to use the closest matching font it does have, but I've had issues with latin letters too, in fonts which weren't supported - they didn't default to another font, they just didn't render. Try a very common font and see how that works (I think Arial is supported, but I might be wrong - I'm almost sure Times New Roman is though - at the very least, MediaWiki defaults correctly with Times New Roman) - EstoyAquí(t • c • e) 12:56, 17 June 2007 (UTC)

How dose someone get SVG on thier computer?

--J intela 03:43, 18 March 2007 (UTC)

What a question. First, you have to be able to view svg. In firefox, this works. You need a plugin from adobe to view this in Internet Explorer. Then, when you click on the svg so that is the only thing on the screen, go file, save page as, image.svg. Althepal 00:28, 22 March 2007 (UTC)

SVG "Icon"

Anyone else think it might be better to have an SVG which shows of the capabilities of the format a bit better than the current one - e.g. using filters, masks etc. There's nothing wrong with the current one, but it's hardly very impressive. I know its been said before, but I'm not suggesting to show scripting or animation as was mostly suggested - only things which can be converted to a single-frame raster. - EstoyAquí(t • c • e) 12:56, 17 June 2007 (UTC)

Scalable Vector Graphics Naming

All vector graphics are scalable; that is the practical difference between vector graphics and raster arrays. There must be an appropriate way to explain the origin of the name, perhaps historical or anecdotal. Were the originators given to redundancy? Would not VGML make a lot more sense?

Kwstork 05:03, 28 June 2007 (UTC)

Text file?

Is the SVG format really just a (not so) simple textfile, then? They can be edited with Notepad++, which I find really amazing. Zeratul En Taro Adun!So be it. 19:45, 6 July 2007 (UTC)

Yes, they are text files (in some encoding, usually UTF-8). --Zundark 22:17, 6 July 2007 (UTC)

SVG is a file format

List of file formats says so ;) --Kjoonlee 12:17, 22 July 2007 (UTC)

It is not strictly a file format. It is XML markup that can be embedded in other XML. For example, SVG can be embedded in XHTML. Yes, it can also stand alone as a file format, but that is not its only use. --ChrisRuvolo (t) 19:33, 22 July 2007 (UTC)
So XML files can embed other XML files. Isn't this also a valid point of view? --Kjoonlee 19:54, 22 July 2007 (UTC)
SVG is absolutely not a file format. How SVG may or may not get represented within a disk file is partly defined by the top line XML declaration - UTF-8, UTF-16 etc - and partly by designer preference - e.g. zipped. As ChrisRuvolo says above, though, SVG exists in many important ways that are not just files with .svg endings: embedded in other XML documents by namespace; generated by server-side technologies like PHP and streamed over a network or the internet; in-memory DOM representations held in a browser, viewer or such a generator; attached to other documents as MIME extensions; stored in databases... It is definitely wrong to say that SVG is a file format.
So what is it? Trying to remember the best terminology the other day when I edited it, I looked in the XML article, found that list of examples (XHTML, RSS, MathML, GraphML, Scalable Vector Graphics, MusicXML) in the lead section and followed the links - the most common phrase in those was is an application of XML. Prior to that I had been thinking is an instance of XML, but I knew that was clunky. I was happy with Hervegirod's alteration (a few minutes after my edit) back to is an XML markup language because that page he linked to is particularly relevant and interesting in this case.
There is no mileage in 71.63.13.71's issue with RAS syndrome, as s/he fails, in that, to understand that XML is a meta-specification: The XML specification does not define a markup language per se, but a framework for the definition of markup languages, such as the list of examples above and thousands of others. It is XML that is actually slightly misnamed, and so its acronym is best not expanded, or if it is expanded then it is best not to put too much store by the words you find in it.
So, the definition of what SVG is, is very important to get right in the opening sentence of the article. SVG is an important example of the use of XML, so what we say here has a bearing on all the other XML dialects too. And it's definitely wrong at the moment, so without everyone merely edit-warring on the basis of "Hmmm, I think I prefer...", what, exactly, are we going to say? --Nigelj 21:01, 23 July 2007 (UTC)
Whenever I come across debates like this, I love to tear off my bland and unremarkable outer shirt to reveal the huge WP:RS on my chest. Because, at that moment, I become Resolve-The-Dispute-With-References-to-Reliable-Sources-Man! ... and whirlwind debates over personal preferences immediately collapse into dust. No, I'm not a super-hero, and the ladies aren't too impressed by this, but it does help in Wikipedia-land.
So what do the references say? dr.ef.tymac 22:10, 23 July 2007 (UTC)
  • Perl Graphics Programming
    • In Chapter Six, we describe SVG, an XML file format
  • Svg for Web Developers
    • Jasc's WebDraw uses SVG as its native file format
  • Using Adobe Photoshop 7
    • Illustrator creates rollovers using the SVG file format, but this file format is not widely supported yet.
  • Webobjects Developer's Guide
    • What is SVG? SVG is an open standard published by the W3 Consortium
Conclusion: describe SVG as a file format if you want to, and if you want to point out the sloppiness of this term, feel free to do so in a footnote, the same way we handled Talk:XML#Not_a_markup_language. As far as the lead section goes, the most expansive and authoritative definition should be used first. "File format" doesn't seem to meet this test, since SVG need not ever be encoded and stored as a file in the first place (e.g., transmission over HTTP).
This seems like a reasonable solution to the common problem of clarifying "introductory-level language" that is technically inaccurate, but nonetheless widespread. Hope that helps, comments and feedback of course welcome. dr.ef.tymac 22:19, 23 July 2007 (UTC)
Well, in the context of a 'File' -> 'Save as...' dialog, SVG may be one of the available 'file formats' that you may choose (Jasc's WebDraw, Adobe Photoshop). We need an informed and referenced discusssion, based on knowledge, rather than either the edit war that is still going on or just grabbing a few user manuals and treating out-of-context phrases like definitive sources.
For the mix, I have "SVG is an XML-based graphics standard from the W3C" and "SVG is an application language of XML, the Extensible Markup (Meta) Language"[1]
I don't particularly like that wording, Nigelj, as the W3 wording "SVG is a language for describing two-dimensional graphics and graphical applications in XML." Seems more concise. Nevertheless, I agree there should be some resolution here to prevent a "lamest edit war" award.WP:LAME. dr.ef.tymac 17:10, 24 July 2007 (UTC)

An attempt to move forward

I flagged this article as "in use" because people still seem to be edit warring over the "file format" point despite the efforts to resolve this with reliable sources. User:Dreftymac and Nigelj have made some proposals based on reliable sources. Please review these, or make your own, before modifying the article. The "in use" tag should not remain in here long, so it's going to be taken out soon. Hopefully there will be some resolution before the tag gets removed. Thanks for your consideration. dr.ef.tymac 17:09, 24 July 2007 (UTC)

Wikipedia's SVG obsession

Why PNG images need to be converted into SVG? I can start editing PNG images instantly from Microsoft Paint. Its resolution is higher and the file size is smaller in comparison to SVG. For instance, this derivative SVG image is 26 times larger than the original PNG image I uploaded. it means the web page loaded quicker with a PNG than with a SVG as now.

It is better to confine SVG versions to Commons and not replace each and every article with it. Else, each page is load slower and slower.

How do I view a SVG image anyway? I downloaded the SVG version of the above map. But I cannot see it (except on the web site of Wikipedia). Should I install additional software?

Modern browsers already support SVG natively. I suggest you try Opera, Safari or Firefox. --Fenring (talk) 18:35, 11 April 2008 (UTC)

I just downloaded Inkscape. It is scalable indeed to practically any resolution. But I am such a stickler to speed that the very idea of switching, to a 1MB file when a 30KB version is available, tantamounts to blasphemy.

Also, I don't feel comfortable with people replacing PNG with SVG in articles. It is a sure prescription for traffic jam for the 684 million visitors to wikipedia.org annually. PNG was specifically developed for the Internet and handheld device markets. SVG was developed specifically for the advertising print media market.

Optimisation gives speed for SVG

There is one more issue. Is anyone actually checking if the SVG versions ofimages uploaded to Commons are optimised. For instance, check this SVG out. It is half the size of the original PNG image I uploaded. I reused all objects. Hence the smaller file size. But many SVG images I see in Commons are so huge they cannot be used efficiently.

I agree that many SVGs in Wikimedia Commons are inefficient. But your SVG doesn't work at all, as it relies on a link to a file BlankMap-World.png on your hard disk. (And if you were aiming for efficiency, why did you leave all that Inkscape cruft in the file?) --Zundark (talk) 19:03, 11 April 2008 (UTC)

Optimisation saves space for Commons

User:Ch1902 said --> I think you're missing the point. When you upload SVG images to wikimedia projects, the thumnails used in articles and displayed on the image page are PNG images generated from the SVG by a renderer. The 1MB SVG image isn't used in articles at all, the 800px PNG render of the SVG map is only 76kb compared to your original of 86kb. However, I could download the SVG map, recolour the countries, relocate the dots and move the key in a matter of minutes and re-upload and the new PNG would still be only ~76kb but that kind of change is impossible or incredibly time consuming with the original PNG only.

Yes, but it means the SVG image stored in the Commons is still 1MB. Suppose, the storage space available for Commons is only 1TB. It means, only 1 million SVG images. If they are optimised (by object re-use), atleast 10 million SVG images in the Commons.Anwar (talk) 16:00, 11 April 2008 (UTC)

XP Desktop

I could not save a SVG image as my desktop background on my XP. Until, Microsoft begins default support for SVG, all images in Wikipedia articles ought to be only in PNG format. Otherwise, the 684 million visitors to wikipedia.org annually would see whitespace in each page.Anwar (talk) 16:03, 11 April 2008 (UTC)

Um, nope. --Kjoonlee 16:35, 11 April 2008 (UTC)
Huge SVGs (too big when a small SVG would do the job just fine) sound awful, and I think something must be done about them. I think you should bring this up at community portals, instead of venting steam here. --Kjoonlee 16:38, 11 April 2008 (UTC)

Talk page references

  1. ^ Watt, Andrew (2003). SVG Unleashed. Indianapolis: SAMS. p. 7,8. ISBN 0-67232-429-6. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

DOM

The article needs a section on DOM access to scripts. Anwar (talk) 15:03, 5 August 2008 (UTC)

Just a minor improvement; please don't be offended.

I edited the article like so, only for it to be reverted.

http://wiki.riteme.site/w/index.php?title=Scalable_Vector_Graphics&diff=231099866&oldid=231091840

I know a lot of people feel very strongly about topics that concern open standards and such, but please keep an open mind. Being an open standard is not a requirement for the existence of multiple specialised development environments. Doc files can be editted with Microsoft Word and Open Office for example.

As the article already clearly states SVG is an open standard (no need to mention it a second time) and there is no strict relation between an open standard and the existence of multiple specialised development environments, I've reinstated my change. —Preceding unsigned comment added by 145.97.202.97 (talk) 21:18, 11 August 2008 (UTC)

Access to the spec - i.e. an open spec, not a secret or confidential closed spec - is a necessary but admittedly not a sufficient requirement for multiple implementations. I can't see how 'multiple' programming teams would produce 'specialised development environments' to produce instances of a complex file format for which they could not legally obtain a specification. The OOo developers spent many years carefully reverse engineering the binary MS Office file formats to gain some compatibility, and probably risked all kinds of legal repercussions in the process, I imagine. They also never really finished an endless game of catch-up while MS themselves continued to add features like 'reviewers comments', 'highlight text' 'accept/reject changes' that seriously broke their earlier attempts. No one else even tried to do this.
However, despite these facts, if you feel so strongly that this cannot be mentioned in the lead, I'm not offended (should I be?), but I'm not going to edit-war with you over it. --Nigelj (talk) 21:39, 12 August 2008 (UTC)

It's just that the section reads better this way. I also don't like duplication of information. Cheers. —Preceding unsigned comment added by 145.97.202.97 (talk) 12:12, 13 August 2008 (UTC)

'Filter effects' section

There is a large section in the article on filter effects - about 370 words, including a table and code example. There is not a single citation in this highly technical section and anyway, it seems out of place. The SVG 1.1 spec defines 14 important functional areas or feature sets, listed below, of which Filter Effects is only one. The section seems to me to be misplaced in this overview article, aimed as it is at a general readership. I was tempted to 'be bold' and delete it now, saving a copy here for reference, but I thought I'd ask for the thoughts of others before doing so.

  • Paths
  • Basic Shapes
  • Text
  • Painting: Filling, Stroking and Marker Symbols
  • Color
  • Gradients and Patterns
  • Clipping, Masking and Compositing
  • Filter Effects
  • Interactivity
  • Linking
  • Scripting
  • Animation
  • Fonts
  • Metadata

SVG 1.1 spec contents list 8 - 21 --Nigelj (talk) 21:17, 12 August 2008 (UTC)

I agree. An overview of the capabilities of SVG would be more appropriate. -- Globbet (talk) 11:40, 16 August 2008 (UTC)
Okay. Being in agreement with both Nigelj and Globbet, and seeing no contrary opinions, I pulled the excessively technical section out of the main article and created a new article SVG filter effects which is linked to this main article. I also used Nigelj's summary as the basis of a new Functionality section subdivided as per his list (above). For the first four, I have written capsule summaries of the purpose of these categories of functionality. As I have the time, I'm willing to complete the other ten similar descriptions, or others can do this if they are so inclined. -- Objectivesea (talk) 05:18, 25 August 2008 (UTC)
Good work, Objectivesea. Well done. --Nigelj (talk) 09:14, 25 August 2008 (UTC)

Corporate Politics, W3C Vision, and SVG

Is anyone following this article bold enough to add a section addressing the incredibly interesting standoff between the leading web visionaries (Berners-Lee), along with the overwhelming support of the W3C standards committee, versus the corporate interests of Microsoft and Adobe and who knows what else? This history is fascinating and can only be motivated by billions of dollars of profit/loss on one side versus light years of rapid advance in web 2/3 presentation capacity on the other. The mechanics of how all this happened - how SVG slowed to a crawl between 1999 and 2009 - 10 years! - has to be available out there, and I am frankly too lazy and jaded to go find it. But someone could, and should. KTyson (talk) 13:17, 15 September 2008 (UTC)

Compressability a feature?

I just read the article and the second paragraph proudly states that because SVG is written in XML it can be compressed. The article makes it look like it's a feature of XML. But i think that saying this is a feature is putting the world on its head. Compressebility just means that the format is somehow unefficient. XML actually adds extra's to data to make it human-readable. So it's not so much that XML is compressible, it's more like XML is intentionally inflated to serve it's purpose. Then, of course, you can remove the air out of it. It is a feature of all human-readable representations of data. Books are compressible, so is source code. —Preceding unsigned comment added by 82.95.177.116 (talk) 13:18, 17 September 2008 (UTC)

Perhaps compressibility is misplaced if it really looks to reader as if a feature of SVG, if so move it gently. Compression is not a feature, its a strategy to compensate for the downside of a real feature, that is, readability. Is anyone arguing against readability as a feature of XML, SVG, or, by extension, HTML? Readability is crucial and inefficient. Compressibility compensates a little.KTyson (talk) 13:30, 20 September 2008 (UTC)
Splendidly put, both of you. (I do love the level of debate we get round here.) Have any of us got the energy (and the references) to put a few sentences expressing something like this into the main article, so that it is more fair to mention it in the lead (given that the lead is meant to summarise the main points of the article)? Something maybe also comparing the file sizes of typical binary representations of a simple (and maybe also a complex) image with its uncompressed and its zipped SVG equivalents? I could begin to do the original research for all this, but that's no good to us, we need references. --Nigelj (talk) 14:33, 20 September 2008 (UTC)
Hmmm, this is really a general statement about XML, and probably ought to made in that context and only briefly mentioned here. I can see why it deserves mention, if the majority of other vector graphics formats use dense non human readable encodings. Dcoetzee 10:12, 20 November 2008 (UTC)

UI Development Tools

I suggest to add a new section about tools that help programmer to use SVG as description language of UI. I had a project, called MadButterfly at http://www.assembla.com/spaces/MadButterfly. It translates SVG into C code and have a framework that application can manipulate SVG objects to interact with users. And, I found another tool, SPARTK at http://spark.sourceforge.net/, that is a WEB framework leverage SVG technical. I am a newbie, here. Is it feasible to add a new section for this topic? ThinkerYzu (talk) 03:21, 20 September 2008 (UTC)

It certainly is feasible. Be familiar with the basic WP policies and guidelines, if you want it to stay. Particularly in this case, be aware of notability and be sure to cite verifiable sources for every main point (and any contentious points) made. In your case, look out for the risk of relying on self-published material, and especially avoid opening yourself to accusations of self-promotion. But don't let all that put you off - it's not really a total jungle in here, it's just that everybody wants the best for WP :-) There are also people who have points-of-view for and against the use of SVG (some preferring other approaches, invented by others). In order to end up with neutral overall coverage, some such counter-arguments may have to be mentioned in the end, in line with their relevance and notability. Good luck. --Nigelj (talk) 12:42, 20 September 2008 (UTC)
As tools are mentioned: Happens that the W3Schools have some online live SVG Examples you can edit. I personally think it's the quickest + easiest way to understand SVG mark-up. I checked: W3S is mentioned many times so I gather that it's considered a reliable source(?) Can it be added? I'll check this page in a while and if I see no objections I'll add it (unless some else does it) － Cy21 ➜ discuss 19:40, 30 March 2010 (UTC)

Naming conventions for image file formats

Please see the discussion at Talk:Image file formats#Naming_conventions_for_image_file_formats on naming conventions for articles on image file formats. Dcoetzee 00:47, 25 October 2008 (UTC)

Another article 'dumbed down'?

I see that this article too has been considerably dumbed down in the last couple of weeks, with lots of the interesting content removed. This'll soon be 'Wikipedia for toddlers', I fear! Is everyone happy with this, because I can't really be bothered to argue it any more? --Nigelj (talk) 19:16, 11 November 2008 (UTC)

At a brief look it seems that Thumperward for one, has exercised 'quality control'. I am not sure all of his excisions are justified. Chopping useful information out of an article on a current developing technology just because a reference has not been found yet may not be as helpful as trying to find references. If you think stuff should go back in, put it back. In particular, I don't understand what is so bad about internal links. Globbet (talk) 00:41, 20 November 2008 (UTC)
Awesome. Let's review the changes I made, to see how I "dumbed down" the article.
  1. An entire paragraph on IE plugin minutae from the lede was removed. Unsourced trivia of little interest to anyone except readers looking to view SVG in IE, who would be better served with a manual. No encyclopedic value.
  2. The "See also" section was trimmed of MoS violations. "See also" sections should contain wikilinks to other articles - not to the Wikipedia namespace, and certainly not to external sites. No encyclopedic value.
  3. An arbitrary collection of SVG resources were removed and replaced with a link to the Open Directory Project. ODP contains a much more complete seletion of resources and has its own quality control mechanisms. This is in line with our policy on external links. No encyclopedic value.
  4. A list of applications with varying degress of SVG support was trimmed to remove less relevant examples. An exhaustive list would have been impossible here, and the examples removed did not count SVG support as a major feature, nor was SVG manipulation their key feature. An exhaustive list would belong on list of articles with SVG support or the like. Little encyclopedic value.
  5. two more personal recommendations on IE plugins from Wikipedia editors were removed. This isn't someone's blog, to offer advice to the Internet on random subjects. No encyclopedic value.
  6. Two arbitrary external resource promotions were removed. See #5.
And that's it. If the removal of this "interesting content" has made the article "for toddlers" then we can surmise that the article as it stands is worthy of reading by the under-10 group, whereas Real Men read Web browser manuals to find out about the world. Chris Cunningham (not at work) - talk 09:43, 20 November 2008 (UTC)
I think inserting the 'primary sources' templates in these particular instances is officious and unhelpful. If the article should contain some detail about SVG functionality, then the best source of that information has to be the document that defines that functionality, and the only authoritative source of information about Adobe's intentions for the future of its plugin is Adobe. If this flies in the face of MoS guidelines, then it is an instance in which MoS guidance should be flown in the face of. Globbet (talk) 20:52, 20 November 2008 (UTC)
The article should contain some detail about the format's functionality. This should not be the purpose of the article. The majority of the article's content should be information on the format's impact, its influences, what it is used for et cetera, not technical information of little use to anyone except implementors. Chris Cunningham (not at work) - talk 11:34, 9 December 2008 (UTC)
I wonder which, if any, WP policy Chris is espousing here, and how it relates to the hundreds of mathematical, chemistry, physics etc articles? (to pick a few examples at random). I've never seen it anywhere here, but I'm sure that I have read in the press that one of Jimmy Wales' reasons for starting WP was to gather 'all of human knowledge' into one huge web site. I don't mean to restart any old arguments, I just came across this and realised that I may still not understand something fundamental. --Nigelj (talk) 21:38, 27 April 2009 (UTC)

Caveat about text needed

The text in an SVG file may not be portable.

The same font files need to exist on the machine where the image was made as on the machine used to view the image. Otherwise, the viewing machine may substitute a different font, perhaps de-centering text (due to different aspect ratios in the substitute font) and it may transliterate Greek characters to something from an English alphabet. An SVG image uploaded to Wikipedia may not render as expected in a visitor's browser — nor in the preview PNG image created by Wikipedia because the Wikipedia server may not have the same fonts as the machine where the images was created.

The foregoing rendered the effort to create the image here wasted. -Ac44ck (talk) 09:41, 15 January 2009 (UTC)

Yes, fonts are a problem. See Wikipedia:SVG_Help#Font_issues. --Zundark (talk) 10:33, 15 January 2009 (UTC)
The @font-face CSS standard (originally invented by Microsoft but adopted by W3C) is now supported by all modern browsers in their current (unstable) beta builds. This property also works for SVG in Opera - not other browsers yet but I'm sure they will adopt it soon enough so the problem with fonts might not be around long. I know MediaWiki uses rsvg which isn't in use in any browsers (FF uses Cairo, Opera uses Presto, others use WebKit) but it may come round. ɹəəpıɔnı 02:37, 19 March 2009 (UTC)

Proposed Merge: from SVG animation

Three things:

  • Deja Vu. I think there has been an SVG animation or similarly named page merged here before?
  • There is not enough content at SVG animation to justify a separate page.
  • Animation is a pretty significant part of the point of SVG (it's just that there is not so much of it about yet). Globbet (talk) 01:56, 3 March 2009 (UTC)
Hi, I created both iterations of the article, and I think it qualifies for a separate article now due to the greater (but not full) support for SVG animation by web layout engines in recent times (including WebKit). The only thing that holds it back from greater exploitation-as-example (As in a wider number of animated SVG files abounding on the Web) is the lack of editor support for SVG animation, which is noted in the article as well. --Toussaint (talk) 00:49, 4 March 2009 (UTC)
I am not clear what your argument is against merging. Globbet (talk) 23:34, 4 March 2009 (UTC)
"It's just that there is not so much of it about yet" - there's a lot more of it about than is indicated in the current SVG Animation article. (Not criticising the article, it's fantastic that it was even written separately as this feature is not even known to some people because of the fact that only Opera and WebKit have any real level of support, and even then it is poor.) Definitely warrants a separate article which could do with expansion too. ɹəəpıɔnı 21:34, 6 March 2009 (UTC)
I vote against a merge ;), the main SVG article is already huge in my opinion, and there is already more than a stub in SVG Animation. Merging would only further increase the size of the main article. Manual of Style advice is to spawn new articles when the content of one article begins to be too big. Hervegirod (talk) 10:44, 7 March 2009 (UTC)
I'm also against a merge. Other engines will also get more increase of the svg animations. (ff +smil pack for example, see codedread), and the svg isn't only used in browsers! (for example mobiles) mabdul 0=* 12:39, 7 March 2009 (UTC)
If there is an advised upper limit for page size, one most take into account that it will increase from the current 53 kB by 10%. It would result in a 58 kB page. If this not the case, however, I would merge it into the SVG article. SAE1962 (talk) 09:40, 16 March 2009 (UTC)
32kb is the recommended ideal. This is of course a rough guide and not a rule or regulation, but all articles over 30kb show the size while you're editing in order to alert you to this. More on this here. ɹəəpıɔnı 17:49, 17 March 2009 (UTC)
I am also against a merge. As we 'drill' deeper into SVG here on WP, and as the web itself continues to adopt it more and more, there will be more to say. At 50-odd Kb already, this main article will not hold all there is to say. Rather than merging other sub-topics into this (as we would for a static or moribund topic, or one of ever-reducing interest to the readership), we should be branching the topic out - adding ever more detail to child articles and making this parent article more like an overview page with sub-sections that refer the reader to separate 'main' articles for more detail on sub-topics like SVG animation. --Nigelj (talk) 22:26, 17 March 2009 (UTC)

OK. The proposal has been up for a fortnight and nobody else seems to like it, so I will abandon it for now and get rid of the merge templates. Globbet (talk) 21:51, 19 March 2009 (UTC)

Alternative to merge proposal

This is probably the wrong place to post this as it's purely related to the animation article, but since this is already being discussed here... The current SVG animation should be merged into Scalable Vector Graphics as a section, and it should link to a new article on SVG SMIL animation. The current SVG animation article discusses three methods - ECMAScript animation, CSS animation and SMIL animation.

  • ECMAScript animation is incidental really - it can be used to supplement the other two, or two animate anything at all SVG or no. Most significantly though, there is no specifically animation oriented section of ECMAScript or the DOM standards that I know of; animation is done through looped adjustment of element positions and styles - there is no "Animate()" function or similar. What I'm basically saying is, while it has the widest support, there's nothing extra to it. If you understand ECMAScript and SVG then you can perform ECMAScript animation - there's nothing additional to be learnt, so an article on this would have excessive crossover with existing articles on DOM scripting.
  • CSS Animations is a non-standard, proprietary CSS extension that is unlikely to be adopted by anyone else as far as I can tell. It is generally frowned upon by standards evangelists as it is behavioural while CSS is not.
  • SMIL animation is the recommended standard, a standard about which there is significant information available and a standard which is likely to grow in use (even if adoption is not necessarily widespread and immediate). If the animation article is left as is and expanded its content is likely to be dominated by SMIL, while the other two methods will probably only remain as mentions in the lead-in. ɹəəpıɔnı 01:50, 19 March 2009 (UTC)
The consensus seems to be for a separate article on animated SVG, and in that case I think it should cover the whole subject. Personally, useful though SMIL is in its place, the animations I do are virtually impossible with SMIL as the motions require complex calculations, and those motions are dependent on user interaction. The possibilities with scripted animation are vastly more sophisticated than with SMIL and deserve to be exposed. I think you will also find that the CSS Working Group is currently discussing animation standards. Globbet (talk) 21:43, 19 March 2009 (UTC)
My point about scripted animation is not that it's not worth talking about, but rather that it's incidental. Obviously scripting SVG to animate it is a far more sophisticated and useful method than any other and is a far larger area than SMIL. However, it's existence as a method is not due to anyone creating a scripting technology purely for the purpose of animating SVG. The ability to animate SVG results instead from the fact that Ecmascript exists, SVG exists and they're compatible. You can animate (x)html, MathML or any other visual xml or sgml using Ecmascript, javascript, jscript or even vbscript in the correct environment. There is no isolated technology for scripted animation in SVG. SMIL is however a separated technology.
As vast as the possibilities with Ecmascript and SVG are, I don't really see what could be put in the article about it that wouldn't be better suited to the Ecmascript (or javascript) article. With SMIL however, there's nowhere else for it.
That is of course just my 2¢, just a suggestion but if consensus is reached then forget it. ɹəəpıɔnı 00:32, 21 March 2009 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:SVG/Archive_1&oldid=1149984298"