Re: Compressed SVG? (and a couple of announcements)

On 23/8/14 00:50, Behdad Esfahbod wrote:
> However, no amount of optimization can address the fact that in current
> SVG table, SVGs are stored as plain text.  So I want to suggest that we
> address that by introducing a binary version of the SVG table.
>
> Now, one can argue that this is not a problem as compressing the whole
> fonts or using WOFF is a possibility.  However, in both those schemes,
> one would either need to decompress the whole font / table to get one
> glyph out, or has to keep the decompressed font around (in each
> process).  Both are a non-starter.
>
> So, what I like to propose is to keep the current structure of the SVG
> table, but compress each SVG document independently.

One trade-off to consider here is that it may be desirable to put all 
the glyphs into a single SVG document (or at least put large groups of 
related/similar glyphs into the same document) in order to share common 
components, and to reduce the number of separate SVG documents that need 
to be instantiated by the rendering process.

So using a separate SVG document for each glyph may be convenient in 
that it allows a single glyph to be decompressed independently of the 
rest of the table, but I suspect it'll carry substantial other runtime 
overheads compared to a well-designed multiple-glyphs document.

JK

Received on Saturday, 23 August 2014 07:40:03 UTC