RE: WOFF-ACTION-176: Test hmtx transformation over google fonts corpus (how many lsb == x-min for all glyfs, what savings)

On Thursday, May 21, 2015 6:34 AM Jonathan Kew wrote:
> I think you're right that Vlad's suggestion doesn't work as written, 
> as we don't have any way to determine the "actual decompressed 
> table size" to compare with the "original" size recorded in the directory.

I guess I should've been more specific but what I actually meant was very similar to what you described here - comparing the actual size of the hmtx table recorded in the WOFF2 table directory to the 'original' size that could be easily calculated.

> All existing WOFF2 fonts would continue to work after decoders are 
> updated to recognize this convention, because they have the trueHmtxLength 
> stored in the origLength field, meaning the transform has not been applied.
> 
> However, my preference would be to avoid this sort of complex interdependency, 
> and instead bring back an 'isTransformed' flag in the TableDirectoryEntry flags byte. 
> This is so much simpler and cleaner -- and more extensible, if we come up with a 
> transform for any other table whose "true original size" may not be predictable 
> from other data in the font.

Yes, during our discussion yesterday I quietly lamented the decision to get rid of the "isTransformed" flag - would have made the spec easily extensible, and our lives easier. When the case was made that only two tables would ever be subjected to transformations and the transforms would always be applied, it seemed reasonable to simplify things and not rely on the flag to indicate the obvious, but from the extensibility point of view having the "isTransformed" flag is definitely an advantage.

Considering the fact that we already encountered a problem when the lack of extensibility may potentially make future technology improvements harder to implement - should we revisit that topic and see where we stand on this? 

We do have two reserved bits in the "flags" field, so modifying the meaning of one of them will not change the wire format of the file (in term of bytes served) and it may not even have an immediate effect on woff2 fonts that are currently in circulation - existing decoders won't look for "isTransformed" flag and will continue to process glyf and loca tables as transformed tables, and future implementations (including woff2 compressed fonts) will be updated to comply with the new spec requirements where the new flag is defined.

> Ideally, we'd define an isTransformed flag, and require it to be set for all tables 
> that are transformed (including 'glyf' and 'loca'); this would imply that font producers 
> would have the option of NOT transforming 'glyf' and 'loca' if desired. But existing 
> fonts have these tables transformed, and do not have the flag set; to avoid breaking 
> compatibility with them, perhaps we need to specify that those two tables are 
> ALWAYS transformed, and the flag is ignored.

I think that we made a reasonably strong case for glyf/loca transforms to be normatively mandated, and the compression gains definitely justify an additional implementation complexity, so I see no need to change that. So yes, stating the fact that glyf/loca transforms are always applied, regardless of the flag setting, will solve the problem of backward compatibility with existing woff2 fonts.

Thank you,
Vlad

> For tables other than 'hmtx' (and 'vmtx', which can be handled similarly), setting the 
> isTransformed flag would currently be an error, as no transform is defined for them 
> and the decoder wouldn't know what to do.
> 
> JK

Received on Thursday, 21 May 2015 14:10:56 UTC