hmtx transform optional or required? [was Re: Telcon reminder and agenda for Wednesday Sep. 23]

On 23/9/15 16:59, Levantovsky, Vladimir wrote:
> Hi Jonathan,
>
> On Wednesday, September 23, 2015 11:46 AM Jonathan Kew wrote:
>
>> As currently written, ISTM that the draft spec REQUIRES the
>> encoder to check the LSBs against the 'glyf' table xMin values, and
>> use transform v.1 if they match.
>
>> I was assuming the use of this transform would be optional; the
>> encoder would always be allowed to use v.0 (i.e. the null
>> transform), even if the LSBs are such that one or both of the
>> lsb/leftSideBearing streams could be omitted.
>
> What the rationale would be to make it optional? In order to improve
> the compression gains we made the transforms for other two tables
> (glyf and loca) mandatory - what do we gain by not transforming the
> hmtx even if the data suggests certain things can be omitted? I would
> understand that the existing woff2 font files do not have this
> transform applied but the requirement to check and apply the
> transform is for the AT, not FF so by introducing this new option we
> do not invalidate any existing files.

I find it a bit strange to have this as a conformance requirement for 
the encoder if the file format does not require it. If a file that uses 
v.0 (even though it could have used v.1 and discarded LSBs) remains a 
conforming WOFF2 file, then an encoder should be allowed to create such 
a file.

>
> I understand that from the UA point of view having to support the
> transform when the flags indicate it was applied would be a necessity
> (unless it's an unlikely case when an old UA hasn't been updated yet)
> - but why define this as an option for the encoder? I'm not sure I
> see the benefit, or the use case, that would justify this (as you
> know I have a tendency to avoid options in the spec whenever we
> can).

There's no particular benefit or use case (that I have in mind, at 
least), except for the argument of backward compatibility (with existing 
WOFF2 files) and consistency (between the requirements of the file 
format and the encoder that creates the files).

If we make this compulsory, then we're saying that existing encoders 
today are no longer conformant. Maybe that's OK; after all, the spec is 
still only a draft. But will we do the same if/when we introduce a new 
transform for some other table in the future -- so that encoders written 
to the WOFF2 v1.0 spec will be non-conforming according to WOFF2 v1.1?

Given that UAs will have to continue supporting the older transforms (so 
as not to break existing files), ISTM that there's no downside to 
allowing any new transforms we introduce to be optional for the AT; 
creating a WOFF2 file that uses the v.0 transform for all tables should 
always be a valid option. This avoids the anomaly where existing 
encoders become non-conformant according to new versions of the spec.

JK

Received on Wednesday, 23 September 2015 16:50:11 UTC