- 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
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 >RCC? 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 >RCC'd SVG 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 >reality >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. Peter >Cheers, > >Jim.
Received on Tuesday, 2 March 2004 12:56:08 UTC