Re: Question about Stylable SVG

Jon Ferraiolo wrote:
> 
> At 07:23 AM 3/8/00 -0800, Apu Nahasapeemapetilon wrote:
> ...
> >SVG is different from most other W3C specs in that
> >it won't be browser-makers that implement the best
> >viewers -- it will be graphics companies. These
> >graphics companies don't also have access to a ready
> >stack of other web-related technologies.

> Implementing the SVG spec in and of itself was indeed quite a bit of work,
> but nothing like than the level of effort needed to implement support for
> (for example) the HTML side of the web world. 

That is a good point. I mean, consider the effort needed to implement an
HTML browser in some new device or OS or whatever. First you read the HTML
spec. Maybe you implement it, which isn't so hard. Then you add HTTP and
FTP and mailto and GIF and JPEG, the latter on the basis of a hunch rather
than anything in the spec. Then you do some field testing and discover that
99.9999% of the content doesn't work in you r implementation, so you sink
50 man-years into installing Netsxcape 1.2, 2.0, 3.0, 4.0, IE2, IE3, IE4,
IE5 (and thats just on the Windows 98 platform), and then carefully reverse
engineering whgat they do on thousands of sample test files and try to
build a model of how they render. Which is difficult because there isn't a
model and they don't all render the same - but you need to figure out which
quirks people rely on, which they avoid and which they write a sniffer
script for. Then you figure out how to fool the sniffer script into
treating you liek a browser it already knows about. At this point you
probably have four or five parallel "parse trees" in memory, for different
purposes - one which treats </p> as <p> , one for figuring out where forms
start and stop, and so forth. Heaven help you if you want to try
implementing CSS or DOM on top of all this stuff.

After succesfully having done all this (and lots of very large, even
massive, companies have tried and failed, never reaching this point here)
suppose you were suddenly filled with some sort of philanthropic urge to
document for posterity what the actual, 'what you really have to know',
spec for "an HTML browser" was. it would be huge, and incredibly complex.

SVG is a big and complex spec and calls in a bunch of other specs, too.
Yes. But its *several orders of magnitude* smaller than the philanthropic
spec I mentioned above. And the thing is, to figure out what to do, you
read the spec and implement exactly what it says.

For things that may be unfamiliar, like Porter-Duff compositing, we provide
explicit details and pointers to the literature and pseudo code, and
examples together with renderings of them. I can tell you, it wasgreat to
see two independent implementations give the same results, it really shows
what a complete and detailed spec can do.

Plus, the SVG WG is working on an SVG test suite which will be a great help
to implementors, and to authors who are evaluating products. It should be
very easy to compare what an implementation does with what the test suite
says it should do and how the sample rendering looks, and the test suite
should then allow explicit referencing back to a particular part of the
spec which is incorrectly implemented.

> And SVG's re-use of other W3C
> technologies has allowed Adobe (as one implementer) to share large amounts
> of code across engineering efforts. And I guarantee it will be much easier
> for people starting work today as there is more and more off-the-shelf
> software that can be deployed, rather than having to write everything from
> scratch.

This is also a good point, and of course helps smaller companies as much if
not more so since they can't afford to waste time re-inventing all this
stuff.

--
Chris

Received on Wednesday, 22 March 2000 16:55:58 UTC