- From: Raph Levien <raph@google.com>
- Date: Mon, 29 Jun 2015 09:17:03 -0700
- To: Cosimo Lupo <cosimo.lupo@daltonmaag.com>
- Cc: Ken Lunde <lunde@adobe.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
- Message-ID: <CAFQ67bPj3QkHNPdx4v1ctYf5WYCuYPd9OY9Sv4oyV23OeDykVQ@mail.gmail.com>
No, by "padding" I'm referring to the dead space between tables. This is almost always 4-byte alignment by convention, but that isn't mandated by any spec. So with the information currently plumbed through WOFF2 it would be very easy to make a font that would fail DSIG validation. Raph On Mon, Jun 29, 2015 at 9:09 AM, Cosimo Lupo <cosimo.lupo@daltonmaag.com> wrote: > thanks for your reply, Raph. > I imagine the 'padding' you are referring to is within the glyf table' > glyph entries, so as such it shouldn't concern CFF fonts. The padding > between sfnt tables or between data blocks inside WOFF2 is not optional. > I'm afraid I don't know what you mean by other 'subtle details'. > > As far as I understand this, the only change required would be to ensure > the original CFF font's table order is kept when encoding it to WOFF2, by > simply saying that the WOFF2 table order (i.e. same as the WOFF2 directory > order) is a trace of the table order in the original CFF font; and that > this same table order should apply upon decoding (here I mean the offsets > to the table data, not the order of directory entries which in sfnt must be > sorted alphabetically). > > I know that DSIG is not currently checked for webfonts, and some may well > see it as a waste of bytes. Fair enough. > > It just believe that if an encoder/decoder manages to not invalidate a > digital signature, whenever it can, then it's doing its job well. > > Anyway, I don't want to push this too much. As I said, it was Chris Lilley > who asked me to reopen the issue here. > > Thanks again, > > All best > > -- > Cosimo >
Received on Monday, 29 June 2015 16:17:31 UTC