![[Home]](http://meatballwiki.org/meatball.gif)
ScalableVectorGraphics
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesScalableVectorGraphics is a new standard [not so new, Vs 1.0 in 1999, Vs. 1.1 in 2003] emerging from the W3C to represent vector-based graphics, images, animation and simple interactions in an XML syntax.
A vector image is one composed of geometric shapes or other algorithmic primitives. In contrast, a bitmap is composed of the end-result rendering to a pixel buffer. A vector image can have geometric transformations applied to it without changes in resolution. For instance, one can scale in or out a vector image without loss in definition, whereas one cannot zoom into a bitmap and preserve the density of detail.
Vector graphics are particularly interesting because they are trivial to generate programmatically. A vector graphic description language that is XML-based is even easier to generate. Moreover, it is also easy to manipulate. In particular, SVG can be very useful for InformationVisualization.
Currently, the best available SVG viewer [comes] from [Adobe], although the Apache group's open source Java implemenation, [Batik], is close behind. Another SVG viewer comes from Corel.
The non-proprietory SVG-standard is a possible future competitor to Macromedia Flash.
Current problems:
- lack of browser support out of the box, usually you have to install a plugin (more than one plugin if you use more than one browser)
- version (1.0/1.1/1.2 Tiny? Basic?) and compatibility problems
- SVG viewer are loading slowly from local disk on the first SVG they display
Advantages:
- rather simple, comparable to HTML, one can "write SVG"
- .svg file are normal text, should be easy to integrate in wiki
- .svg files are rather small
- one can mix SVG and other XML namesspaces, use DOM mechanisms e. g. with Javascript, so really nice complicated things (could) become possible
At BitFlash?, where I work, we are currently working on a mobile version of SVG that is less featureful, called [SdVG] (Small Device Vector Graphics). While I obviously have an interest in SVG, I have found much of it particularly useful. It definitely solves some of my problems with emitting graphs and other images for my InformationVisualization research. And, hey, if you think that the Adobe SVG Viewer is too large to install as an ActiveX control, perhaps I can make an unsigned SdVG? plug in for y'all. -- SunirShah
Anybody know what the tag would look like for a wiki to embed SVG? -- DennisDaniels
At BitFlash?, I just added an <embed/> tag, but that's because I can beat people who spread viruses with it. The problem with SVG is that InternetExplorer is not aware of it, so you need to tell it explicitly how large to make the ActiveX control in the <embed/>, unlike a normal <img/> like a GIf where IE will pull the width and height from the graphic. Perhaps something as simple as http://example.com/file.svg(width,height)? But SVG is scriptable, so allowing it to be embedded is almost as bad as RawHtmlWiki. -- SunirShah
Thanks a bunch Sunir! Now to play!
I finally connected your name. I'd sent you an email sometime ago regarding SVG whiteboard. If I remember correctly you were trying something with a JabberProject/MozillaBrowser combo, but I don't find any refs to your work on that here at MeatballWiki. I see enormous potential in a Whiteboard 'like' environment, given the work that AlexShapiro has done with TouchGraphWikiBrowser
It's clear that the technology will eventually allow for real time dynamic vector graphic generation. I searched quite a bit for an ASCII UML diagram creator to compensate for email and Wiki restrictions. Jave http://www.jave.de/ was the best tool I found for ASCII UML for creation, but always had trouble on sending/recieving the diagrams. Long story short, SVG became my preferred output format. And wiki had the dynamic flexibility but not the graphical interface.
My personal dream since discovering UML and Wiki is to combine the two into a dynamic graphical problem solving environment. I'm not much of a programmer but I'm a pretty damn good user ;). So the trick was always how to combine the graphical language tool we call UML and the node based communication tool we call Wiki. UML Wiki.
This way users can describe their issues/help questions directly to the node that represents the GUI of the application. Activity and Sequence diagrams appears to be the simplest because they are sequential and easier to manipulate with fewer controls. Developers can respond directly to the node with answers questions etc. For the curious users they could go take a look at the source code.
The 'easiest way' I've found so far to keep all this data together and dynamic was some kind of data base generated image, preferably with lots of HyperLink?s. UmlSvgWiki? became my fixation ;) --DennisDaniels.
I never managed to resolve the synchronization problem within an acceptable amount of bandwidth. (Though see ParableOfTheBook) In fact, even allowing desyncrhonization, sending SVG quickly overwhelms the default 10kb SurgeProtector on the Jabber server. Thus, I was inclined to write a peer-to-peer Jabber stream (i.e. a Jabber connection between clients, not going through the server), but then I got distracted with the politics of Jabber, and then finally with work more important to the core business of BitFlash?, my employer at the time. More recently, EricMurphy? has put an SVG whiteboard into Jabberzilla. [1] Others are also working in this space. -- SunirShah
What about XmlRpc? Could that be an option for synchronization problems? This site is using an SVG and xmlrpc though I've not investigated thoroughly...the demo is pretty cool though http://www.protocol7.com/svg/opml/ and here's the spec http://www.protocol7.com/svg-wiki/default.asp?SvgExtensions hth ;) --DennisDaniels
No; the problem is not in the protocol, but in the distributed algorithm.
See also WhiteboardTools.