Vector Graphics On The Web? 18
Rob asks: "Bitmaps take up valuable bandwidth and are displayed at different sizes depending on your screen resolution, but Flash animations are big and clunky. Will the increasing take-up of alternative means of browsing (PDAs, mobile phones, TVs, ...) with corresponding variations in screen display and connection speed lead to the emergence of a compact, widely used standard for vector graphics? What are the obstacles which need to be overcome? What vector formats are already in use on the Web?"
SVG (Score:3)
the xml basd svg (scalable vector graphics) format.
http://www.w3.org/Graphics/SVG/Overview.htm8
Adobe are supporting SVG.
They have a browser plugin to view svg graphics for windows and mac. (Mozilla also supports svg)
Adobe's drawing products have svg output.
http://www.adobe.com/svg/
Some other links:
http://www.blackdirt.com/graphics/svg/
http://sis.cmis.csiro.au/svg/index.html
Well, I worked on NGP back in the 70s... (Score:1)
Well, I'm really showing my age by saying this, but I worked on Network Graphics Protocol on the APRAnet in the early 1970s, with the results of my work and the work of others published as RFC 493 in 1974. Originally, NGP (as it was known in 1972) worked only with line segments; text and bitmaps were added after I had left the project.
The basics are simple: the drawing field is 65536 by 65536 virtual pixels, with the coordinates interpreted as an integral fraction (or scaled integer, if you prefer).
The RFC is not available online, but I have a copy as printed in the 1985 DDN Protocol Handbook.
Here is an interesting quote from RFC493: "When reason decends on the world, the TELNET negotiation mechanism (see NIC 15372) will be used to establish the willingness to transmit graphics information (DO, DONT, WILL, WONT, GRAPHICS) and a subnegotiation transmission will transmit the socket number [of the independent graphics connection]. In the case of an intelligent graphics terminal attached to a TIP [terminal interface processor], the TIP TELNET responds to the negotiation and establishes the connections."
Some additional details: there is a Z-axis, or intensity, specification in the primatives. The Microsoft Windows concept of different co-ordinate systems may well have had its roots in this 30-year-old protocol, because NGP has one system for vectors, another system for text, and a third system for areas.
The protocol also allowed for input devices. You know this predates mice from this quote: "The state of a coordinate device is a pair of coordinates in the screen coordinate system. These coordinates could be derived from a tablet and stylus, from a light pen, from two knobs [emphasis added], from a keyboard (by typing in values, or using a keyboard-propelled cursor) or whatever." The invention of the mouse was to take the "two knobs" and put them in a housing that could be moved by the hand.
If you are interested in reading this old, old RFC, I could be talked into scanning the RFC from the printed copy and posting it on my web site. It's a government publication.
See also the /. article (Score:1)
Well, there is the W3C standard [w3.org], mentioned in a Slashdot article from Saturday. [slashdot.org]
Louis Wu
"Where do you want to go ...
Re:Well, I worked on NGP back in the 70s... (Score:1)
By "line segments" do you mean simple straight lines? Any more complex curve support? Fills? (should wait for the scan I guess).
And one last thing, the old Tektronix vector terminals had a stream protocol too. Just over a serial line (probably HPIB as well, can't recall and the ones I used only had a serial i/f). But they're a bit more recent than this.
Re:See also the /. article (Score:2)
This is a common and easy misunderstanding to make.
In defense of Flash (Score:2)
What tends to make it big and clunky is the habit designers have of embedding bitmap images into the .SWF either intentionally or unknowingly: the worst offender in this regard is Adobe's 'Flash-killer', LiveMotion which does some really evil things to generate .SWFs - from what I've been able to extract from LiveMotion-generated .SWFs, it seems to flatten all the layers it uses internally into a single bitmap and then stick it into the .SWF as is which is, unsuprisingly, somewhat inefficient.
--
Cheers
NAPLPS? (Score:1)
It was most popular in the classic Progidy interface, as it allowed them to create graphics despite the old slow modems. Of course, it is easier to create cartoons with vector graphics than it is to create detailed images -- but that's an implementation issue.
RFC 965 (Score:2)
Check out Xara X (Score:1)
http://www.xara.com [xara.com]
What about photos? (Score:2)
Incidentally, I think Kodak was once promoting an image file format/server software combo that would provide several levels of resolution, depending on what the client asked for. AFAIK, it didn't take off.
TrueType/OpenType (Score:1)
Hmm - if one is willing to turn one's vectors into glyphs then this could be a great format. Create "myvectorimages1thru128.ttf", specify the font and appropriate glyph at the desired size in your code and instant embedded vector image. The only problem is that there's no reliable way (that I know of) of getting a font to a browser.
-- Michael
Tektronix (Score:1)
coordinates)?
Re:What about photos? (Score:1)
http://www.turingarchive.org/
It's got a little GPL java client/server for image viewing (which I did part of).
Re:In defense of Flash (Score:1)
Flash "movies" do not HAVE to be big and clunky, they just usually are. Flash is a lot of rope with which the FrontPage/GoLive crowd out there hangs itself. But it doesn't have to be that way.
Used judiciously, it is the fairly light weight vector format for which you are looking.
Java! (Score:1)
Anyway, my point is that transporting some kind of graphics manipulation code as Java bytecode might be easy IN SOME CASES, and a hell of a lot less frustrating than waiting for the major browser vendors to implement support for SVG. There's always more than one way to do it ;-)
--
Re:What about photos? (Score:1)
Basically, a large, high-res image is split up into 'tiles' - recursively subdivided, if you like. The tiles are also rendered at various resolutions, and all packed into the same file for storage (this tiling/resampling can of course be done on the fly)
This means a client with a fixed-sized viewport can request a rectangular region of the image, and a server (or file loader) can return the appropriate set of tiles.
Basically the idea is that you should never have to send more information across the wire (either internet, the PCI bus, whatever) than the clients viewport can display - i.e. if youure viewing a 10,000 x 10,000 pixel image with a 400 x 300 window, its pretty pointless to send the entire image down the wire, since its going to consume enormous bandwidth and memory on the client.
Instead, you give the client zoom and pan controls, and stream down the appropriate tiles as the client requests them.
This works really well, and there was a product from LivePicture (the LivepPicture image server) - i think LivePicture have gone out of business since, but it was a sound technology.
Wavelet compression on photographs does work - i belive JPEG-2000 uses wavelet compression or something similar to it to achieve better quality at the same size reduction as JPEG.
IT doesn't offer, in the general case, an enormous improvemnt over existing techniques, but in some instances, wavelets offer dramatic advantages. Motion Video codecs are starting to use wavelets, and i think this is where they will really shine.
CGM (Score:1)
Alice, from U of Virginia (Score:1)
I just searched here, and it seems this little plugin got no attention at all from /. yet.
First, the home page [alice.org] and a little description:
One last thing: the server was incredibly slow for me, a little patience might help. Here's the google copy [google.com] just in case.
PS: this plugin runs on top of Python.