W3C home > Mailing lists > Public > www-svg@w3.org > March 2004

Re: Profiles in SVG 1.2

From: Peter Sorotokin <psorotok@adobe.com>
Date: Tue, 02 Mar 2004 09:56:32 -0800
To: Jim Ley <jim@jibbering.com>, www-svg@w3.org
Message-id: <>

At 02:13 PM 3/2/2004 +0000, Jim Ley wrote:

> > As nice as it is, I'm not entirely
> > buying the multiple SVG viewers with different capabilities one.
>So Batik, KSVG etc. will become basically useless after Adobe release an RCC
>capable UA until the kind open source developers find the time to implement

There has to be a second implementation for the Rec, right? RCC is not hard to
implement. Also, Mozilla's XBL is almost true superset (with different tag 
names) -
so it's not like there totally no new open source work in this area.

>The Use case is simple, getting content to users, if the users UA doesn't
>manage RCC, I need to have that UA degrade, switch may get us there, but it's
>an awful lot of data being shipped, for all the clients.  Shipping 200k of

Oh, have you came across a 200k RCC component? In my experience RCC tends
to make things smaller, not bigger. It's normally either geo data, 
"excessively rich"
graphics that makes big files - or stuff generated from template like a 
fancy 2k
bar repeated 100 times to make up a bar chart (and RCC deals with that
case nicely).

>  to TinyLine at 10USD a MB is pretty nasty given that all it'll get at
>best at the end is 5k of static SVG image that it could deal with - In 
>it's likely to get nothing it can render at all.
> >  > Alternatively I'd like to see RCC
> >  > etc. reformulated so it will simply degrade to valid static content
> >  > showing the same information in SVG 1.1 user agents - at the moment
> >  > that degrade path is onerous.
> >
> > That is certainly a worthy goal, but do you have a plan for that?
>Nope, I feel it's a rather complicated goal, and would much rather deal 
>with it
>outside of the document.

I'd rather keep the document clean. Having both RCC and static content in
one file seems like a mess.


Received on Tuesday, 2 March 2004 12:56:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:00 UTC