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