[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod wrote:
> Joshua Allen wrote:
>> ... The lack of viewers which are hosted in the web browser should
>> not be seen as lack of capability, but simply lack of volition in the
>> absence of any compelling reason to hook the viewers up (so long as
>> Adobe ships a sufficient viewer)
>
> I think that you and I have very different use cases for SVG. I'm not
> looking for a vector graphic rendering platform. It's cool for that and
> was designed for that, but I just don't have problems that require that.
> I'm looking for a dynamic, graphical rendering platform. For that I need
> the full suite of specifications implemented in the Adobe viewer: SVG,
> JavaScript (built-in implementation), XLink, SMIL, DOM events, etc. Many
> people are building apps on this "dSVG" platform and most only run on
> the Adobe implementation.
I don't think that contradicts what Joshua says (or if it does I have a
problem because I agree with both of you ;). Yes, the most interesting
part of SVG is when you use the complete family of specs: you get a
complete and modern graphical toolkit that's extremely powerful and
rather easy to use. Currently, it's true that the only serious option
(that I know of, on the desktop) is Adobe's Viewer (Batik in some cases,
with a heavy biprocessor and ~2gigs of ram). I think however that were
ASV to disappear tomorrow, it wouldn't be long before an open source
gorilla would get into gear and implement a complete viewer. One good
place to start would be to finish the Mozilla implementation (because
it's guaranteed to be portable, and you have a lot if not most of the
technologies you need already done). Another place would be KDE which
already has Konqueror and kSVG.
> Implementing "dSVG" is in fact a pretty big task -- it is on the order
> of difficulty of building a dHTML renderer and how many people have done
> that?
Not that many, but imho enough that a viewer would be implemented rather
fast should a strong need arise. I think we will see complete
implementations other than ASV some time in 2003.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|