CFF redundancy

All,

Per today's meeting, I looked into the possibility of creating a CFF without any horizontal advances specified in order to see whether Adobe applications would instead use 'hmtx' metrics. This was harder than I figured. What I found is that if were to remove the horizontal advance declarations in the source data, which are name-keyed Type 1 fonts, our tools will insert zero (0) advance widths when creating the CFF.

I dug deeper (mainly because I am somewhat ignorant of the implementation details of CFF and Type 2 charstrings), and found that CFFs have a very efficient mechanism for storing horizontal advances. Each hint dictionary (CID-keyed fonts can have more than one) declares defaultWidthX and nominalWidthX values that are able to either eliminate an explicit horizontal advance altogether (if it is the same as the defaultWidthX value) or can be made smaller (data size-wise) via the nominalWidthX value. I dumped the hint dictionary (aka FDArray) information for Source Han Sans (aka Noto Sans CJK) Light, and created the attached table that shows each hint dictionary (there are 19), the CIDs (glyphs) that it includes, the number of glyphs that correspond to the CIDs and CID ranges in the previous column, and their defaultWidthX and nominalWidthX values.

While removing the horizontal advances in a CFF may result in a smaller CFF, I expect that the size reduction will be extremely small, especially for CJK fonts tat include thousands or tens of thousands of glyphs whose horizontal advances are the same as the declared defaultWidthX value. And, even if this is done, I would advise against it primarily because my own tests show that Adobe applications tend to prefer the horizontal advances in the CFF over those in the 'hmtx' table.

Regards...

-- Ken