Talk:Scalable Vector Graphics

From Wikipedia, the free encyclopedia

This article may be too technical for a general audience.
Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details.

This is the talk page for discussing improvements to the Scalable Vector Graphics article.
Please sign and date your posts by typing four tildes (`~~~~`). Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Ask questions, get answers. This is not a forum for general discussion about the article's subject.	Be polite Assume good faith No personal attacks Be welcoming	Article policies No original research Neutral point of view Verifiability
Archives: 1

	This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
B	This article has been rated as B-Class on the quality scale
High	This article has been rated as high-importance on the importance scale

Archives
Archive 1

1 Annoyance
2 Using on the Web
3 Curiosity
4 How this SVG markup appears in a capable viewer
5 Digital cameras?
6 Problems with re-uploading SVGs
7 No Units in Translate Transform
8 Portal
9 Wikipedia's SVG obsession

[edit] Annoyance

These things just seem useless to use since most programs can't run .svg extensions with programs. What are the point of these? —Preceding unsigned comment added by 71.75.81.13 (talk) 00:38, 4 February 2008 (UTC)

This useless format which is apparently only viewable in web browsers is bizarrely widespread on wikipedia. The two desktop display renderers for Windows I have investigated, Irfanview and Renesis player, are ugly, buggy and basically nonfunctional when it comes to displaying SVGs. I see the point of nice scalable vector images but this format is incredibly difficult to use.jackbrown (talk) 21:29, 15 February 2008 (UTC)

I've no idea what Irfanview and Renesis are like, but the Adobe SVG Viewer (which requires Internet Explorer) and Batik Squiggle (which requires Java) both display SVG files correctly in my experience. --Zundark (talk) 22:34, 15 February 2008 (UTC)

Right. Internet Explorer=Web Browser (see above comment). Displaying in a web browser clearly isn't a problem which is why wiki uses it so much. I will investigate your Batik recommendation, thanks. jackbrown (talk) 15:05, 18 February 2008 (UTC)

Okay, Batik sucks too. It's a Java implementation. No drag n drop, sucky non-standard UI, unintuitive zooming. Renesis is the best desktop SVG viewer I've seen yet, and it ain't that great. Crappy-to-nonexistent printing for starters. By the way, anyone who tells you to use Irfanview is nuts. jackbrown (talk) 15:27, 18 February 2008 (UTC)

Batik is the best implementation you'll find (I mean the most conformant to the specs, including animations, ...). But it's basicaly a library for java. You can develop a UI around. But what are you looking for exactly ? A renderer ? The Opera browser is currently the best desktop renderer for Windows, I think. An editor (you mentionned drag&drop) ? Try Inkscape then. All these informations are in the article. But you'll find more informations in forums about SVG. --Fenring (talk) 17:25, 18 February 2008 (UTC)

How SVG is interpreted doesn't seem to be well standardized yet. For example, I picked up an SVG graphic here, and neither Dia nor GIMP nor Firefox was able to display the text in the third part properly (among other things), but InkScape got it right. — NRen2k5^(TALK), 16:59, 19 March 2008 (UTC)

That file isn't a good example, as it's not a conforming SVG file. It's not surprising that Inkscape displays it as intended, since it was made with Inkscape - and Inkscape is to blame for it being non-conforming (Inkscape bug #167335, "flowed text (flowRoot) must be moved to inkscape namespace"). Your general point is correct though: even conforming SVG files often display differently in different viewers. But this isn't because the interpretation isn't standardized, it's just because the SVG specification is large and complex and there are very few complete implementations at present. --Zundark (talk) 19:17, 19 March 2008 (UTC)

[edit] Using on the Web

Is it possible to use SVG pictures on html pages? (e.g. <img src="file.svg">, etc.)? — Chesnok 08:08, 20 October 2007 (UTC)

Yes, but it has to be done in a rather strange way in order to work with a reasonable range of browsers. There's some information on the SVG Wiki, though I don't know how accurate it is. The latest alpha version of Opera 9.5 supports SVG in HTML 'img' elements, but that's not currently a viable way of doing it (due to lack of support in other browsers). --Zundark 09:55, 20 October 2007 (UTC)

Thank you. — Chesnok 17:18, 20 October 2007 (UTC)

[edit] Curiosity

How does this work, exactly? I don't think the article explains it and am dead curious! --Mad Tinman _T _C 21:11, 6 November 2007 (UTC)

Maybe you want to read Vector graphics first. Then get Inkscape to try. --AVRS 15:08, 7 November 2007 (UTC)

[edit] How this SVG markup appears in a capable viewer

The image shown is an SVG. Regardless of how the browser is showing it, will not the caption still say it is being displayed correctly? --81.168.41.80 14:29, 11 November 2007 (UTC)

The image presented to the browser is a PNG file (rendered from the SVG by the server), so it doesn't require the browser to be able to render SVG. (Of course, the reader may still not see the image, for any of a number of reasons.) --Zundark 16:02, 11 November 2007 (UTC)

[edit] Digital cameras?

The article actually never mentions cameras - do any digital cameras have as an optional format? If not, why not, when it looks like cell phone cameras (if I understand the article correctly) do so? -- John Broughton (♫♫) 20:57, 1 December 2007 (UTC)

Digital cameras produce raster graphics. SVG isn't well suited for this, and it's mainly used for vector graphics. I suspect the SVG support in phones is probably mainly for use in applications such as games, or maybe for backdrops. CountingPine 09:55, 2 December 2007 (UTC)

Very obvious to someone who has a deep understanding of what raster versus vector graphics means, or who goes and reads those articles. Not necessarily obvious to the casual reader, or to someone like me, who has been reading through the documentation about image uploads to Wikipedia and the Commons, and came to this article looking for a quick answer, because that documentation didn't mention that SVG isn't (I think you're saying) supported in modern digital cameras. -- John Broughton (♫♫) 22:04, 2 December 2007 (UTC)

No, cameras do not output photos in SVG format. But if you don't understand the concept of vector graphics, then don't worry about the SVG format. It relates to digital cameras about as much as a musical score relates to a microphone. However, if there is general information elsewhere about uploading images for Wikipedia that has caused this confusion, then maybe it's worth asking for clarification there. CountingPine 02:30, 3 December 2007 (UTC)

However since you mention digital cameras, some use SVG for the user interface. The Canon D40 is one example. --82.226.191.237 (talk) 23:18, 20 February 2008 (UTC)

To my understanding svg format allows for raster images to be stored and treated like any other svg element so digital cameras could use svg to place items onto the picture such as time and date, logo or combining photos into panoramic scenes etc ... But if a raster image is converted to an svg the result would be a very large svg file which does not contain any more information than the original raster (lossless) -- 81.105.21.49 (talk) 00:53, 27 December 2007 (UTC)

You could store a raster image as a large amount of vector squares with certain colours, but this kills the point of having it as vectors to begin with. 130.89.228.82 (talk) 20:25, 16 January 2008 (UTC)

Yeah as above, a trace is generally the preferred choice when needed, but it is lossy. Even if you got an incredibly powerful tracer (which could use things like partial-opacity gradients for shadows etc., or use filters to store complex information more efficiently - no tracer can do this, even though it may be ideal) then although the result may be extremely close to the input (possibly negligiblely different) it would not be the exact same. But a tracer this powerful doesn't even exist, so current results are generally very obviously different from input. - ^Estoy_Aquí^{(t • c • e)} 00:06, 1 February 2008 (UTC)

[edit] Problems with re-uploading SVGs

I just wanted to note that sometimes, when downloading SVGs from a Wiki, then uploading them to another MediaWiki, the SVGs tend to become distorted. An example is shown here. Although when viewing the image by itself, the image is not distorted. This may have something to do with imagemagick or GD2 issues. --198.150.12.32 (talk) 17:15, 15 February 2008 (UTC)

That's not a conforming SVG file: there are loads of 'midPointStop' elements in it, but there's no such element in the SVG specification. These elements probably come from Adobe Illustrator, but Adobe puts them in a non-SVG namespace, which is OK. Some badly behaved software (or maybe a badly behaved person!) must have moved them into the SVG namespace, which is not OK. However, I don't think this was caused by downloading from one wiki and uploading on another, since the copy on Wikipedia has the same problem. The difference in rendering on the two wikis is probably caused by using different versions of ImageMagick (or whatever it is that MediaWiki uses for rendering SVG files) - old versions are significantly worse than newer versions, and some versions may handle the 'midPointStop' garbage differently. --Zundark (talk) 17:49, 15 February 2008 (UTC)

Thanks for telling. I think I'll use flash (when I get it in April) to handle that by converting the vector-based GFX to PNG-24/8. --iyeru42 —Preceding unsigned comment added by 198.150.12.32 (talk) 19:09, 15 February 2008 (UTC)

[edit] No Units in Translate Transform

Can some one explain why the translate transform does not allow units to be specified? I've searched all over the web for this with no success. It seems dumb to me. You either use units and somehow avoid translations or specify everything in pixels. The only other alternative is to manually convert units into pixels every time you need to translate. Is this a bug in the SVG spec, is there a really good reason for it, or is there a work round I haven't found? —Preceding unsigned comment added by 86.165.109.58 (talk) 21:30, 18 February 2008 (UTC)

Physical units are for interfacing an entire graphic to a surrounding context (like a web page). Even then, they make a scalable format non scalable :) You need to understand the concept of a coordinate system and avoiud trying to make user units equivalent to pixels in your mind. They are not the same thing. --82.226.191.237 (talk) 23:20, 20 February 2008 (UTC)

You are making things unnecessarily difficult for yourself. You should stick to using default units (they aren't really pixels) in the main part of the SVG. If you want the final SVG image to be in physical units, you can do that with 'viewBox', 'width' and 'height' attributes on the main 'svg' element. So, for example, you can write the SVG as though 1px = 1mm, and then set the attributes in such a way that this is effectively the case. --Zundark (talk) 22:03, 18 February 2008 (UTC)

Thanks for that, but if that is how SVG is designed to be used, why allow non-physical units at all, and as they are provided why not allow them in translations? I'm interested in the motivation of SVG's designers. Did they just get it wrong, which is how it seems, or is there some deep reason for allowing units everywhere accept in translations so that your work round is required? Using units directly, particularly when describing images to be printed at a particular size, e.g. cutting templates, would seem much easier and more direct.—Preceding unsigned comment added by 86.165.109.58 (talk) 10:00, 19 February 2008 (UTC)

The reason for allowing physical units in so many places appears to be compatibility with CSS. In places where CSS compatibility is not an issue, there's often no provision for physical units, especially when they would greatly complicate things (e.g., in paths). I don't consider the method I described as a work-around - this is the way to do it, and there really isn't any other portable way (unless you completely avoid paths and translations). And, although you may disagree, I think it's easier to type one 'viewBox' attribute than to type "mm" (or "cm" or "in" or whatever) all over the place. --Zundark (talk) 11:46, 19 February 2008 (UTC)

I agree that it is easier not to have to write units every time, but only if all the units you are using are the same. It isn't easier if for example you want all lengths to be in millimetres but want to specify text in point sizes for compatibility with other printed documentation. But we are getting away from the point. Why were units left out of translations in the first place. It seems so inconsistent. Adding units to translations does not loose anything and really does not complicate the rendering engine in any significant way as it already has to handle units everywhere else. If it were included, it solves my problem and you can still work in single units and sort it all out in the 'viewbox' if you want. Everybody wins. —Preceding unsigned comment added by 86.165.109.58 (talk) 15:58, 19 February 2008 (UTC)

I see your point about wanting to mix "mm" and "pt". As for consistency, it appears that they have consistently not allowed units in anything that was complicated enough that they had to give a BNF grammar: path data, polylines, polygons and transforms. Making an exception for translations wouldn't have helped many people, as almost all SVG files use paths. (Allowing units in all these things is listed in the SVG 1.1/1.2/2.0 Requirements document as a possibility for SVG 2.0.) --Zundark (talk) 17:53, 19 February 2008 (UTC)

[edit] Portal

I am a extremely pleased wikipedia uses the SVG format for diagrams, but I have a problem with Image:S-Da DNA base pair.svg which opens fine in both inkscape and illustrator but not here and have no idea if there is a help portal for vector graphics, which would be great. This site should definetely have the link to the svg guide present in the "/wikipedia:" place in the top of the page. --Squidonius (talk) 19:22, 8 April 2008 (UTC)

Image:S-Da DNA base pair.svg references a font called ArialMT. The server probably doesn't have that font, so it substitutes another, which causes the overlapping text. Converting the text to paths should fix that problem. --Zundark (talk) 19:54, 8 April 2008 (UTC)