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

Rod, all,

Do we know for sure that the fonts that didn’t pass the “transform eligibility test” failed on both counts, meaning both longHorMetric.lsb[] and leftSideBearing[] arrays couldn’t have been transformed? Or is it the case that only one of them was misbehaved causing us to drop that font from consideration and losing a potential transform savings by eliminating one array but not another?

Yes, finding a concrete case to prove that this would be a benefit is good (and I will be looking once I can get my hands on sufficient CJK corpus) but in general I am for an approach that gives flexibility and extensibility from the start at minimal or no cost, and the one suggested by Jonathan wins on both counts.

Thank you,
Vlad


From: Roderick Sheeter [mailto:rsheeter@google.com]
Sent: Wednesday, September 16, 2015 9:02 AM
To: Jonathan Kew; Levantovsky, Vladimir; w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: Re: hmtx transform - thinking out loud (yet again)


Based on measurements to date most fonts benefit from the simple all or nothing approach. In absence of evidence that the additional variations are a win my inclination would be to use one of the extension values to indicate we followed the original suggestion and leave the other two available. That is, to take the all or nothing route unless we can show there is a solid win for the additional variations.

This allows us one more transform before we need to introduce something like transform 11 means a uint8 transform is present. As an aside, perhaps that should be a general standard for the transform field?

IMHO that means we need a corpus of CJK fonts to confirm/deny that the variations are a sufficient win for CJK fonts to justify inclusion in the spec.

Cheers, Rod S

On Wed, Sep 16, 2015, 1:31 AM Jonathan Kew <jfkthame@gmail.com<mailto:jfkthame@gmail.com>> wrote:
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