Re: CFF redundancy

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
>
>