- From: Cosimo Lupo <cosimo.lupo@daltonmaag.com>
- Date: Thu, 21 May 2015 11:01:31 +0100
- To: public-webfonts-wg@w3.org
Hello, regarding Vladimir’s suggestion on hmtx transformation: > we can easily determine this case by analyzing the table directory entry for 'hmtx' - comparing the actual decompressed table size against the 'original' size I believe there’s a problem. How could we extract a transformed hmtx table data from the decompressed font data stream, if the htmx entry in the table directory does not have a “transformLength” field (currently reserved for glyf and loca only), but only an “origLength” value? If the hmtx was not transformed, then the length of the original table would also be the length of the decompressed table. But if the hmtx was indeed transformed, then origLength would be greater than the decompressed size of the transformed table data, and we would risk reading off data from another table that follows hmtx in the decompressed stream... On the encoder’s side, how can we store a transformed hmtx in the WOFF2 font data stream, but only store the original length in the table directory, when there are no offsets to individual tables, nor any flag that tells the decoder to look for an optional transformLength? I can’t see how to make this work this without modifying the specification, to explicitly signal that hmtx was indeed transformed — thus also breaking compatibility with the current WOFF2 implementations. I’d be nice to know what you think about that. Thank you. PS: By the way, yesterday’s "mystery guest” was actually me. I apologise for my little “intrusion”! :) -- Cosimo Lupo, Font Design, Dalton Maag Ltd 9th Floor, Blue Star House, 234-240 Stockwell Road, London, SW9 9SP, UK Mobile: +44 7825 324360 London Office: +44 20 7924 0633 Registered office: Mutfords, Hare Street, Buntingford, SG9 0ED, UK Registered in England and Wales: 3103619
Received on Thursday, 21 May 2015 10:02:01 UTC