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

On Wednesday, September 23, 2015 12:50 PM Jonathan Kew wrote:

>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 don't think I'd agree with this approach in general. An encoder has a complete info about an input font file and can make an intelligent decision on whether the hmtx transform can or cannot be applied. Both outcomes are plausible and perfectly valid, so while it would make sense to mandate that encoders do the best job they can do the same cannot be blindly duplicated for file format requirements - whether the transform could or could not be applied isn't known after the woff2 file was created, the validator won't be able to determine if the hmtx transform was a viable option, and the file format requirements ought to be flexible for this very reason.

>>
>> 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).
>

The existing WOFF2 files will remain compatible by design, I don't think there is a concern there, at least not at this point. As far as consistency, between encoders and the file format  - I don't think we can always equate them in term of mandatory requirements, encoders have access to a lot more info than file validators and UAs.

>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?
>

The spec being a WD makes it a moot point (we've seen a lot more drastic changes being made to e.g. WD CSS3 specs) but I don't think it's even expected that an implementation claiming conformance to spec ver. 1.0 must remain conformant when the spec ver. 1.1 or 2.0 is introduced. This is not the case for UA, why it should be an expected outcome for encoders? The key point here is that we don't brake anything and do not invalidate the existing WOFF2 files, but introducing a new feature can't guarantee that both the UA and encoders remain conformant with the new version of the spec unless they are updated.

>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.
>

I think that what you call an anomaly is actually the only driving force of progress. IMHO it would be unreasonable to expect that once an implementation of a spec is finalized it will remain compliant with all the future spec modifications and upgrades - if that were the case there would have never been a need for an upgrade. The conformance is claimed to a particular version of the spec and once the new spec is released the expectation is that the implementations have to be upgraded at some point to comply. The downside of making something optional is that it eliminates the need to for implementers to do anything, and in many cases (not this one in particular) too many optional features cause the specs and their implementations become fragmented. In our particular case, the downside is to allow encoders to not do something useful  to improve the compression efficiency and I simply don't see a good reason for it. It's simple to do, it doesn't break anything - why we'd let the encoders be sloppy when we can mandate them to do the best job they can do.

Thank you,
Vlad

Received on Wednesday, 23 September 2015 18:59:59 UTC