- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 28 May 2009 17:05:56 +0200
- To: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
- Cc: "public-exi@w3.org" <public-exi@w3.org>, "fujisawa.jun@canon.co.jp" <fujisawa.jun@canon.co.jp>
Hi, On May 28, 2009, at 14:42 , FABLET Youenn wrote: > As some of you may remember, we had some discussions during TPAC > 2008 about how to use EXI for better SVG path compression. > During that discussion, I said that we made some experiments on > applying EXI compression on path data structured as XML trees. > The results were showing that, although the current compact syntax > does a really nice job, using EXI on XMLized path data would > certainly improve the situation, at least in the scenarios we are > aware of. Thanks, this is interesting and matches the research we'd done back when I was with Expway. Without even going into complex SVG-specific codecs you can also gain quite a fair bit by losing the absolute/ relative semantics which only very few authors care about. That brings the number of commands from 19 down to 10 (you list 20, but z and Z are identical). Where it concerns precision, large tracts of content out there has too much of it — a lot of it could use integers, or perhaps two decimals tops. It's hard to do anything smart in there without becoming SVG specific, but some tricks include looking to see if zoomAndPan=disable (which does *not* mean that zooming is impossible, but can be used as a hint) and looking at the viewBox definition and its relationship to the size of the canvas — that can help derive the necessary precision one actually needs unless massive zooming occurs (you rarely need to place things more precisely than 1/10th of a pixel). Anyway, interesting stuff! Don't hesitate to share more :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Received on Thursday, 28 May 2009 15:06:33 UTC