Re: CFF redundancy

Behdad,

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

In any case, I am taking the necessary steps to change this behavior in our applications, but keep in mind that it may take one or two release cycles until this behavior might be exorcized from our code.

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.

This has been a good discussion.

-- Ken

> On May 28, 2015, at 2:51 PM, Behdad Esfahbod <behdad@google.com> wrote:
> 
> Hi Ken,
> 
> I agree that the savings for CJK and monospace-like fonts are minimal.
> 
> That said, your recommendation and concern that Adobe applications tend to prefer the horizontal advances in the CFF over those in the 'hmtx' table goes against Adobe's stance in initiating the change in OpenType to reverse the order.
> 
> Again, removing these widths is an optimization path that can (and should) happen outside of WOFF2 encoder/decoder.
> 
> Anyway, given the small returns and significant overhead of deconstructing and reconstructing CFF tables, I think we can conclude that WOFF2-specific transformations that I had in mind are not worth it at this time.
> 
> Thanks all,
> 
> behdad
> 
> On Wed, May 27, 2015 at 4:13 PM, Ken Lunde <lunde@adobe.com> wrote:
> 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
> 
>

Received on Thursday, 28 May 2015 22:33:01 UTC