- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Fri, 9 Oct 2015 21:26:27 +0100
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>, "w3c-webfonts-wg (public-webfonts-wg@w3.org)" <public-webfonts-wg@w3.org>
On 9/10/15 19:31, Levantovsky, Vladimir wrote: > As a follow up on the last telcon discussion about allowing null > transform for any and all tables (including glyf/loca) and > considering the changes that have just been implemented w.r.t. > transformLength field (clarifying that it is never optional) - one > solution that may not be pretty but functional - treat the presence > of the transformLength field in table directory as a global transform > flag, and the flag bits purely as a transform number. Unless I'm misunderstanding something, we can't do that: there's no separate indication of whether transformLength is present. The presence of this field is implied by the fact that a non-null transform is used for the table. So a decoder has to first read the table tag and flag bits, to determine whether a non-null transform is involved, and only then does it know whether to read a transformLength field. It can't "detect" the presence of the transformLength field independently, can it? > By doing so we > can introduce the null transform option for glyf/loca tables without > breaking anything that has already been deployed. > > Comments? AFAICS, this doesn't work! See above. JK
Received on Friday, 9 October 2015 20:26:57 UTC