Re: CFF redundancy

Behdad,

Apologies for the tardy reply to this.

Anyway, you wrote:

>> I share your concern that Adobe apps do one thing, but that the OpenType Specification, which is effectively co-authored by Adobe, says another (and as a requirement). I am also concerned because this limits the practical use cases for CFF-based collections whose component fonts may share the same glyphs but may use different 'hmtx' settings for them, which is explicitly mentioned in the 'hmtx' page of the specification (see the paragraph after the table):
>> 
>>   http://www.microsoft.com/typography/otspec/hmtx.htm
> 
> Right.  So the idea is to be able to assign different advance widths to the same glyphs, from different faces.  One would think that it would be useful to be able to adjust the lsb of the glyphs at the same time.  But can you confirm, that no Adobe application you know of, actually adjusts the lsb of glyphs in a CFF font based on the lsb value in the hmtx table?

I am not aware of any such uses, and my guess is that a CFF consumer completely relies on one or the other table for all glyph-width data, at least for horizontal. For vertical, the 'vmtx' table must be used.

>> About removing the CFF horizontal advances, this doesn't seem to be possible due to what seems to be a requirement to include defaultWidthX and nominalWidthX values in the hint dictionary (or dictionaries). The only thing that I can see happening would be to zero them out, which would currently break a non-zero number of implementations.
> 
> I was thinking about setting defaultWidthX to some non-zero value, and assigning default width to all glyphs.  That will result in most compact representation of the CFF width data.

Wouldn't a value of 0 (zero) for all glyphs in a CFF be a much better indicator for conveying to CFF consumers that the 'hmtx' widths should be used instead? A value of 0 (zero) is also guaranteed to use minimal space (pun intended).

Regards...

-- Ken

Received on Tuesday, 2 June 2015 12:51:16 UTC