Re: hmtx transform - thinking out loud (yet again)

On 9/9/15 22:14, Levantovsky, Vladimir wrote:
> Hello WG,
>
> As a follow up to my previous email below and our discussion today
> during the WG call:
>
> We only have two mechanisms available  to signal the transform-specific
> conditions – flags and transformLength. For the ‘hmtx’ table in
> particular, the only parts that can be subjected to transform are either
>
> -lsb array that is part of the longHorMetric structure (for proportional
> glyphs), or
>
> -leftSideBearing array (for monospaced glyphs), or
>
> -both of them.
>
> There are no other possible conditions that can be exploited for ‘hmtx’
> table optimization and we only have three possible flag values that
> could be to indicate a transform version number. If we are comfortable
> using up all of the available flag values for the ‘hmtx’ table and
> leaving no room for future updates (and the only reason I am even
> considering this possibility is because I cannot see anything else that
> could be done to define the updated ‘hmtx’ transforms in the future)...

I'm a bit reluctant to take this approach, essentially closing off the 
possibility of alternative 'hmtx' transforms in future updates. It's not 
totally implausible (IMO) that we might want to investigate other 
approaches. E.g. how about dropping the 'hmtx' table altogether for 
OT/CFF fonts, and reconstructing it from glyph widths in the CFF 
charstrings? How about a transform where each advance is stored as a 
delta from the previous glyph's advance, instead of an absolute value?

I think it would be preferable to use a single flag (transform version) 
value for the current proposal of dropping lsb values when they're all 
equal to xMin. To allow for the three sub-versions (drop the lsb field 
from longHorMetric; drop the separate leftSideBearing array; drop both) 
we can prefix the transformed 'hmtx' data with a flags byte that 
specifies which of these operations has been applied. Yes, that's one 
additional byte (prior to Brotli compression), but it buys us vastly 
more flexibility.

So in summary, we'd have something like this:

   hmtx transforms:
     version 0 = null transform, hmtx table is stored unchanged

     version 1 = LSB elimination, as follows:

       UInt8 flags
         bit 0: lsb field in longHorMetric was removed; reconstruct
                it from xMin values in the glyf table
         bit 1: leftSideBearing array was removed; reconstruct it from
                xMin values in the glyf table
         bits 2-7: reserved, must be zero
       followed by the transformed hmtx data

One question is whether we should allow the LSB elimination transform to 
be used, but with its flags all set to zero -- indicating that neither 
option was actually applied -- or if that should be considered an error. 
I don't have a strong view either way.

We should specify that this transform may ONLY be used for fonts that 
have a glyf table; it is not valid for fonts that use CFF outlines (or 
have only bitmap or SVG glyphs).

JK

Received on Wednesday, 16 September 2015 08:31:34 UTC