RE: Agenda for telcon Oct. 7

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 Wednesday, 7 October 2015 20:13:07 UTC