Re: CFF redundancy

On Thu, May 28, 2015 at 3:32 PM, Ken Lunde <lunde@adobe.com> wrote:

> 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


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?


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

Understood.


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


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