- From: Taki Kamiya <tkamiya@us.fujitsu.com>
- Date: Thu, 28 May 2009 17:59:34 -0700
- To: "'Robin Berjon'" <robin@berjon.com>, "'FABLET Youenn'" <Youenn.Fablet@crf.canon.fr>
- Cc: <public-exi@w3.org>, <fujisawa.jun@canon.co.jp>
Hi, I think your research is in a sense making an epoch because it is an effort that seeks synergy between EXI and SVG, both of which are W3C technologies, and should set a nice example of using EXI by the organization defining it. Thanks for taking up the effort! I'd like to make one suggestion that might help taming the issue of the choice between integer and float. Instead of choosing between integer and float, you can model the structure such as follows, with x and y defined as elements with optional attribute "decimals" that represents the number of decimals after the decimal point. <M> <x decimals="1">101</x> <y decimals="1">201</x> </M> Since the attribute "decimals" is optional, it occurs only as necessary, and the extra markup cost is 1 bit that is needed for indicating its presence. When "decimals" does not occur, each data can be represented as 1 + 9 = 10 bits (at minimum), instead of the full blown float which constantly uses at least 18 bits. You also indicated that SVG schema is huge. (Maybe you can call it even small compared with Docbook schema, I suppose. ;-) You may want to separate the schema used for exchange from the more stringent, constraining schema used for validation. One simple schema may just declare element and attribute names so that their names get into the initial string table. You should be able to calibrate the schema by defining some element content as repeatable choice of child elements so that the generated grammar is of minimal size, as necessary. Paraphrasing Robin's last note, please don't hesitate to explore and relish EXI more. ;-) -taki -----Original Message----- From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of Robin Berjon Sent: Thursday, May 28, 2009 8:06 AM To: FABLET Youenn Cc: public-exi@w3.org; fujisawa.jun@canon.co.jp Subject: Re: [public-exi] <none> 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 Friday, 29 May 2009 01:00:28 UTC