RE: Agenda for telcon Oct. 7

Yep, classic "chicken and egg" problem! 
I completely forgot that we currently rely on table tags to determine the presence of transformLength field.

Vlad


-----Original Message-----
From: Jonathan Kew [mailto:jfkthame@gmail.com] 
Sent: Friday, October 09, 2015 4:26 PM
To: Levantovsky, Vladimir; w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: Re: Agenda for telcon Oct. 7

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:51:44 UTC