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

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) - we can simply use all available flag values now so that:
00 - would indicate no transform for 'hmtx' table (as is currently the case);
01 - would indicate a transform where only lsb array from longHorMetric was eliminated;
10 - would indicate a transform where only leftSideBearing array was eliminated;
11 - would indicate a transform where both lsb and leftSideBearing arrays were eliminated from the 'hmtx' table.

This would exhaust all possible flag settings but it also offers a complete coverage of all possible transform conditions. The main benefit of doing this would be an opportunity to distinguish the cases for CJK fonts where a much smaller lsb array may be left intact while the larger leftSideBearing array can still be eliminated.

>From the implementation point of view - I don't see any additional complexity that would be introduced by using additional flags settings. With "all or nothing" approach, the encoder is expected to run (lsb == xmin) check on both lsb arrays values and decide whether the transform can or cannot be applied. A more flexible approach would still require the same (lsb == xmin) check on both arrays but the only difference is that the encoder is able to specify precisely which of the array can be eliminated as a result of the transform and signal it via flags.

The reverse transform is also trivial - using the flags and the numGlyphs and numberOfHMetrics values a decoder will simply reverse the transform by recreating a particular data array using xmin numbers from associated run of glyphs.

Again, this will use up all available flag settings and all possible transform combinations at the same time - I really don't see any downside of doing so because if we keep the reserved flags values for this particular table they will likely remain unused for eternity.

Comments are welcome!
I would like to hear your opinions on this and would really appreciate if we can quickly finalize this on the email list (so that the bulk of what's written here can become a part of the amended spec - one way or another).

Thank you,
Vlad

P.S. For every reply to this email Rod will contribute an undisclosed amount to cover our lunch during the F2F meeting in October - don't be bashful and send your comments and replies in, ASAP!


From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com]
Sent: Thursday, September 03, 2015 10:09 PM
To: w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: hmtx transform - thinking out loud

Folks,

As I am getting my hands on the spec piece related to 'hmtx' transform, a question came up that I would like to discuss with the group.
In order to setup the discussion, here is the hmtx table structure:

typedef struct   _longHorMetric {
         USHORT   advanceWidth;
         SHORT            lsb;
}  longHorMetric;
longHorMetric [numberOfHMetrics]; /* provides aw and lsb values for all proportional glyphs in a font */
SHORT leftSideBearing [numGlyphs - numberOfHMetrics]; /* optional, provides lsb values for all monospaced glyphs in a font */

(As you can see, the second leftSideBearing array is an optional component which could have a length of zero if numGlyphs = numberOfHMetrics, otherwise it contains the lsb values for the run of monospaced glyphs that all share the same advanceWidth.)

Here is the issue I am trying to resolve - besides the transform number bitfield (two bits of flags which are supposed to be set to '01' for the hmtx table) we have only one tool in our possession to signal whether the table has or has not been transformed - the "transformLength field. However, there are three possible cases to consider:

1)    A font that has only proportional glyphs with lsb values encoded as part of longHorMetircs array (and empty leftSideBearing array);

2)    A font that has only monospaced glyphs with longHorMetric represented by a single value followed by the leftSideBearing array of lsb values;

3)    A font that has a run of proportional glyphs followed by a run of monospaced glyphs (such as e.g. a Chinese font that has proportional Latin glyphs followed by monospaced Kanji), where the longHorMetric array will include the lsb values for proportional glyphs and leftSideBearing array will provide lsb for monospaced portion.

The first two cases are easy - once we check and confirmed that lsb values in an array match the xMin for each glyph we can simply remove them from the 'hmtx' table and encode the new transformLength in woff2 table directory. However, in case 3, there may be fonts that

a)      Have lsb values matching xMin for the proportional glyphs but not for monospaced, therefore while lsb field of longHorMetric can be eliminated the leftSideBearing array must stay;

b)      Vice versa, the lsb values of the proportional glyphs don't match the xMins but the monospaced portion of the font does; therefore, we would need to keep longHorMetric[] as is but can eliminate the leftSideBearing[];

c)       Both proportional and monospaced glyph runs are well-behaved where lsb = xMin for all glyphs, and both lsb field of the longHorMetric and the leftSideBearing[] can be eliminated.

Last option 3c would be easy to implement since it's similar to "all or nothing approach" we take for cases 1) and 2). Supporting options 3a and 3b however would also be desired (especially option 3b for a large CJK font) but they require additional signaling to indicate what part of the hmtx data was eliminated and which one stayed. I am struggling to come up with the way to accommodate this additional signaling.

Any creative ideas would be greatly appreciated!

Thank you,
Vlad