RE: Compression was: What is wrong with SVG?

Various members of the SVG working studied various compression techniques.
I personally spent quite a bit of time on it. My personal conclusions are:

1) Standard gzip (part of HTTP 1.1) does a bang-up job compressing most XML
grammars, and it has lots of great attributes, such as being streamable at
the byte-level (i.e., you can progressively render gzip'd data) and being
open source
2) Custom gzip compression dictionaries (e.g., an SVG-specific dictionary)
doesn't provide any compression benefit in most cases because of how good
of a job gzip does in creating dictionaries automatically
3) SVG's path data compresses to some level via gzip, but the best results
come from squeezing every possible extraneous character out of the path
data first, and then gzip'ing
4) A newer compression scheme, bzip (I think that is its name), looks
promising as a way to compress XML data even more than gzip. (Howver, bzip
isn't part of HTTP 1.1)

Overall, I doubt if an SVG-specific compression scheme would be worth the
effort.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

At 11:46 AM 6/12/00 +0100, Dave  J Woolley wrote:
>> From:	Vader@t-online.de [SMTP:Vader@t-online.de]
>> 
>> I'd really like such a compression algorithm. But I think that all XML
>> data would profit from one and thus I think there should be only one
>> algorithm for the whole XML (but one that gets supported by all XML
>> readers, editors, ...).
>> 
>	[DJW:]  Compression is already present in the web, although
>	maybe not as well supported as it might be; it is considered
>	the role of HTTP, not HTML or XML (including SVG), although
>	images have traditionally been compressed, bur probably 
>	for historical reasons (Compuserve, disk space, and the fact that
>	you cannot edit them as text, anyway).
>
>	Incidentally, the easiest way of getting good deflation with
>	something like SVG would be to implicitly prefix the file
>	with a training set of SVG, and remove the result of compressing
>	this from the data transmitted.  This would break the layering,
>	that I mentioned above, and would therefore, in my view, be 
>	undesirable. (deflate encodes the distance back to 
>	a previous occurrence of s astring and the length of that string.)
>

Received on Monday, 12 June 2000 10:33:12 UTC