Re: Agenda for telcon Oct. 7

Vladimir and others,

When it comes to fonts with CFF outlines, there are two aspects of the 'hmtx' table that must be considered.

One is the horizontal advances, which match those in the 'CFF ' table. Contrary to what is stated in the OpenType and OFF Specifications, the rendering and layout engines in Adobe apps use the horizontal advances in the 'CFF ' table, not those specified in the 'hmtx' table.

The other aspect is the LSBs, and I was never able to fully reconcile the fact that the 'hmtx' table specifies them, but that the 'CFF ' table does not. The Type 2 Charstring specification states the following:

"...all sidebearings are considered to be zero and hence unencoded in Type 2 charstrings."

My own experimentation suggests that Adobe apps ignore the LSBs that are specified in the 'hmtx' table.

Regards...

-- Ken

> On Oct 7, 2015, at 2:11 PM, Levantovsky, Vladimir <vladimir.levantovsky@monotype.com> wrote:
> 
> Thank you Jonathan,
> I am wondering whether hmtx table is used with CFF outlines today, I remember there were something specific mentioned about hmtx use as a primary source with CFF-flavored fonts and font collections, I am hoping Ken Lunde will be able to bring some clarity on this.
> 
> Thank you,
> Vlad
> 
> 
> -----Original Message-----
> From: Jonathan Kew [mailto:jfkthame@gmail.com] 
> Sent: Wednesday, October 07, 2015 3:30 PM
> To: Levantovsky, Vladimir; w3c-webfonts-wg (public-webfonts-wg@w3.org)
> Subject: Re: Agenda for telcon Oct. 7
> 
> Following up on the discussion of the 'hmtx' transform versions, a couple of weeks ago, here's what I suggest:
> 
> -------------------
> 
> First, I propose that we drop this paragraph from the draft:
> 
> # The encoder MUST check that leftSideBearing values match the Xmin # values of the glyph bounding box for every glyph in a font file and, # if the conditions are met for each of the proportional or monospaced # glyph runs the encoder MUST set hmtx transform version number to "1", # MUST eliminate the corresponding array from the hmtx table and MUST # set the appropriate Flags bits.
> 
> Instead, we can have a note such as:
> 
> | [INFORMATIVE NOTE: An encoder can use this transformation format only 
> | when the font is TrueType-flavored (i.e. has a 'glyf' table), and 
> | after checking that the leftSideBearing values for each glyph in the 
> | proportional and/or monospaced glyph runs in the 'hmtx' table exactly 
> | match the corresponding xMin values in the 'glyf' table.]
> 
> -------------------
> 
> Then, in the section on Table Directory Format, we modify the text about flag bits, something like this:
> 
> # For all tables in a font, except for 'glyf' and 'loca' tables, # transformation version 0 indicates the null transform where the # original table data is passed directly to the Brotli compressor for # inclusion in the compressed data stream. The transofrmed table
> 
> (Typo: s/transofrmed/transformed/)
> 
> # formats and their associated transformation version numbers are # described in details in clause 5 of this specification.
> 
> INSERT:
> 
> | Where more than one transformation version is defined for a given 
> | table tag (which is currently the case only for 'hmtx', but others may 
> | be added in future revisions of the specification), an encoder may use 
> | any of the defined transformations that is applicable to the input 
> | data; a decoder MUST be prepared to accept any of the defined 
> | transformations.
> 
> | [INFORMATIVE NOTE: Where multiple transformation versions are defined 
> | for a table, an encoder should normally choose the transformation 
> | version that results in the smallest transformed table length, unless 
> | the reduction is so slight as to be insignificant.]
> 
> before continuing with the existing text:
> 
> # If a decoder encounters a table entry that specifies an unknown # transformation version number the entire font MUST be rejected as it # cannot be correctly decoded.
> 
> --------------------
> 
> We also need to update the later sentence:
> 
> # Optionally, for 'glyf' and 'loca' tables that are subjected to # additional transformations, the transformLength specifies the length # of the transformed version of the table.
> 
> to mention 'hmtx' with transformation version 1, in addition to 'glyf' 
> and 'loca'.
> 
> Also, I think the word "Optionally" should be dropped here. This field is never optional; in any given table directory entry, it is either required or prohibited. Something like this:
> 
> | The transformLength field is present in the table directory entry if, 
> | and only if, the table has been processed by a non-null transform 
> | prior to Brotli compression. This is the case for the 'glyf' and 
> | 'loca' tables with transformation version 0, and for 'hmtx' when it 
> | uses transformation version 1. For tables that are not transformed, no 
> | transformLength field is present in the directory entry.
> 
> --------------------
> 
> 
> JK
> 
>

Received on Thursday, 8 October 2015 13:30:46 UTC