Re: Announcing new font compression project

--00235452e6b0a071ef04bcb67d43
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 2, 2012 at 9:03 AM, Chris Lilley <[email protected]> wrote:

> On Friday, March 30, 2012, 1:20:24 AM, Sylvain wrote:
>
>
> SG> Re-enacting old battles never goes out of style but if there is
> SG> such interest in it I suggest starting a separate thread
> SG> (tentative subject line: =91The MTX conspiracy!=92).
>
> Thanks Sylvain. I was just composing a similar message.
>
> SG>   I=92d rather read concrete feedback on Raph=92s intruiguing proposa=
l
>
> Yes.
>
> So concretely, this is a WOFF update that uses the same overall structure
> and has similar benefits (such as inclusion of license and other metadata
> along with the font) but produces improved compression due to three thing=
s:
>
> - MTX-derived table rearrangement to pre-compress and remove redundancies
> or derivable information
> - LZMA compression (or is it LZMA2)?
>

It is LZMA and not LZMA2. I had some discussion with Igor Pavlov (the
creator of LZMA) about this, and he agrees that not using LZMA2 is
appropriate. The latter format contains optional transforms (I believe
mostly useful for compressing things like binary machine code), and also
the ability to concatenate multiple streams. Neither is appropriate within
this context, and the extra filesize overhead and code complexity is
significant.


> - optional multi-table streams rather than one stream per table
>
> When considering a new compression scheme for something already widely
> deployed, the following questions seem pertinent:
>
> - is the improved compression significant enough to warrant a change (it
> seems that the answer is yes here, although it would be good to see more
> data with a wide variety of fonts)
> - is the compression scheme well documented, with an open and freely
> implementable specification (seems so but again this needs to be verified=
)
> - is there implementor interest
> - are there any concerns regarding security
> - are there any concerns regarding patent claims
>

I definitely agree that these are the most relevant questions, and feel
optimistic about the answers.


>
>
> --
>  Chris Lilley   Technical Director, Interaction Domain
>  W3C Graphics Activity Lead, Fonts Activity Lead
>  Co-Chair, W3C Hypertext CG
>  Member, CSS, WebFonts, SVG Working Groups
>
>
>

--00235452e6b0a071ef04bcb67d43
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 2, 2012 at 9:03 AM, Chris Li=
lley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">[email protected]</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Friday, March 30, 2012, 1:20:24 AM, Sylvain wrote:<br>
<br>
<br>
SG&gt; Re-enacting old battles never goes out of style but if there is<br>
SG&gt; such interest in it I suggest starting a separate thread<br>
SG&gt; (tentative subject line: =91The MTX conspiracy!=92).<br>
<br>
Thanks Sylvain. I was just composing a similar message.<br>
<br>
SG&gt; =A0 I=92d rather read concrete feedback on Raph=92s intruiguing prop=
osal<br>
<br>
Yes.<br>
<br>
So concretely, this is a WOFF update that uses the same overall structure a=
nd has similar benefits (such as inclusion of license and other metadata al=
ong with the font) but produces improved compression due to three things:<b=
r>

<br>
- MTX-derived table rearrangement to pre-compress and remove redundancies o=
r derivable information<br>
- LZMA compression (or is it LZMA2)?<br></blockquote><div><br></div><div>It=
 is LZMA and not LZMA2. I had some discussion with Igor Pavlov (the creator=
 of LZMA) about this, and he agrees that not using LZMA2 is appropriate. Th=
e latter format contains optional transforms (I believe mostly useful for c=
ompressing things like binary machine code), and also the ability to concat=
enate multiple streams. Neither is appropriate within this context, and the=
 extra filesize overhead and code complexity is significant.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
- optional multi-table streams rather than one stream per table<br>
<br>
When considering a new compression scheme for something already widely depl=
oyed, the following questions seem pertinent:<br>
<br>
- is the improved compression significant enough to warrant a change (it se=
ems that the answer is yes here, although it would be good to see more data=
 with a wide variety of fonts)<br>
- is the compression scheme well documented, with an open and freely implem=
entable specification (seems so but again this needs to be verified)<br>
- is there implementor interest<br>
- are there any concerns regarding security<br>
- are there any concerns regarding patent claims<br></blockquote><div><br><=
/div><div>I definitely agree that these are the most relevant questions, an=
d feel optimistic about the answers.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
=A0Chris Lilley =A0 Technical Director, Interaction Domain<br>
=A0W3C Graphics Activity Lead, Fonts Activity Lead<br>
=A0Co-Chair, W3C Hypertext CG<br>
=A0Member, CSS, WebFonts, SVG Working Groups<br>
<br>
<br>
</font></span></blockquote></div><br>

--00235452e6b0a071ef04bcb67d43--