- From: Oliver Hunt <oliver@apple.com>
- Date: Tue, 10 Apr 2007 14:59:56 -0700
- To: Chris Lilley <chris@w3.org>
- Cc: Bill Dwyer <themadcreator@gmail.com>, www-svg@w3c.org
I had an earlier response which seems to have been lost in the ether, however most of the points i mentioned have been covered in earlier response (By both Chris and David) On Apr 10, 2007, at 7:37 AM, Chris Lilley wrote: <snip> > So your point is well made, except for your "unecessarily > compressed" and "meaningless savings in space". In real world > usage, these are far from meaningless and far from unnecessary. Additionally there are time efficiency concerns outside of data transfer. No matter how fast your XML parser is it will still be slower (due to recursion, memory usage, simple I/O) than the parser for SVG paths, it's an unfortunate, but nonetheless important fact. For simple paths this isn't a problem, but if you start looking at (for example) the SVG maps at http://www.carto.net/papers/svg/ samples/ the paths get very large - so parsing speed becomes a consideration. <more snipping> > > BD> But as I got more involved, I discovered that > BD> SVG is not as easy to handle as other XML languages, and > required a > BD> lot of extra unnecessary work. > > Extra work, agreed. unnecessary work, no. Not necessarily extra work -- managing the construction (and repaint issues) of more elements is non trivial, anyway you can parse the path syntax in a (relatively) simple iterative loop. --Oliver > > > > -- > Chris Lilley mailto:chris@w3.org > Interaction Domain Leader > Co-Chair, W3C SVG Working Group > W3C Graphics Activity Lead > Co-Chair, W3C Hypertext CG > >
Received on Wednesday, 11 April 2007 00:48:04 UTC