Type 1 hinting in UFO by the AFDKO

[rrob...@adobe.com]

In order to be able to use UFO fonts in the Adobe Type Dept workflow, I came up with a representation for PostScript hint data. At the moment, this is private data, kept in the GLIF file under: <glyph><lib><dict><key><com.adobe.type.autohint><key>. See bottom of this message for an outline of the syntax.

When official support for  font hints are added to the UFO specification, I do plan on immediately supporting that version. I do hope that the UFO spec version ends up somewhat similar to what I have done, but am not counting on this.

The format basically echoes the Type1 hint operators. The element "<hintSetList>" contains all the hint data for a glyph. The 'id' attribute of the <hintSetList> contains a hash of the glyph path operators. This must be compared with a current hash to make sure that the glyph has not been edited since it was last hinted: if the hashes do not match, the hint data should not be used.

The <hintset> element contains the list of stem hints that are in use at a  given point in the outline. The target UFO point in the outline is identified by the attribute "pointName". A  hint set is applied starting at the UFO point with the attribute "name" whose value matches. The syntax of the point name is arbitrary.

For a UFO line or move, a hint set may be referenced by giving the UFO point a name attribute whose value matches the pointName attribute value of the hint set. If there is such a reference, the hitn set is applied starting before the path segment.

A UFO curve  may contain two hint set references. A hint set which is to be appplied before the curve segment is referenced by the first of the three UFO points which comprise a curve. However, another case is required when then curve is the last path segment in a closed path. This is because in the UFO syntax, the third point (which carries the 'type="curve" attribute) is placed first in the UFO path segment list. This point becomes the move-to in a PostScript path, and there must be a way to specify the initial hint set, which is applied before the start of the path. I did this by referencing the initial hint set from this curve point.

For the <stem> element, I did consider Tal Leming's suggestion that the stem width not be explicitly stated as a numeric value, but instead be identified by point names for two UFO points: the stem value would then be derived as the x or y distance between the two points. This would clearly be useful when editing hints manually, and would be directly transferrable to TrueType anchors.  However, a Type1 stem hint is not an anchor: its link with the distance between two points is much weaker, and forcing that link can be counterproductive. A  single stem value may control more than one stem - this happens a lot in ideographic fonts - and may exactly match none. A stem hint will capture any stem whose width is +- some integer value of device pixels, and this property is often used deliberately.  I think this means that a Type1 hint format must allow specifying a stem width as numeric value, chosen by the type editor. This is also convenient when working with an autohinter, and is what I have currently implemented.  

This does not mean that also specifying the link as an anchor between two named points is a bad idea: I think it is a good idea, would be appropriate for the vast majority of Type 1 hints, and should also be supported in any spec for UFO hint data. I suspect that the main use case will be manual hinting in a font editor.

Type 1 hint format implemented in latest FDK download.

 <glyph>

...

<lib>

<dict>

<key><com.adobe.type.autohint><key>

<data>

<hintSetList id="hash of source glyph path operators">

<hintset pointTag="point name">

(<hstem pos="<decimal value>" width="decimal value" />)*

(<vstem pos="<decimal value>" width="decimal value" />)*

            <hstem3 stem3List="n0,n1,n2,n3,n4,n5" />* # where n1-5 are decimal values

            <vstem3 stem3List="n0,n1,n2,n3,n4,n5" />* # where n1-5 are decimal values

</hintset>*

(<hintSetList>*

(<hintset pointIndex="positive integer">

(<stemindex>positive integer</stemindex>)+

</hintset>)+

</hintSetList>)*

 <flexList>

<flex pointTag="point Name" />

 </flexList>*

</hintSetList>

</data>

</dict>

</lib>

</glyph>

Example from "B" in SourceCodePro-Regular

<key><com.adobe.type.autohint><key>

<data>

<hintSetList id="64bf4987f05ced2a50195f971cd924984047eb1d79c8c43e6a0054f59cc85dea23a49deb20946a4ea84840534363f7a13cca31a81b1e7e33c832185173369086">

  <hintset pointTag="hintSet0000">

<hstem pos="0" width="28" />

<hstem pos="338" width="28" />

<hstem pos="632" width="28" />

<vstem pos="100" width="32" />

<vstem pos="496" width="32" />

  </hintset>

  <hintset pointTag="hintSet0005">

<hstem pos="0" width="28" />

<hstem pos="338" width="28" />

<hstem pos="632" width="28" />

<vstem pos="100" width="32" />

<vstem pos="454" width="32" />

<vstem pos="496" width="32" />

  </hintset>

  <hintset pointTag="hintSet0016">

<hstem pos="0" width="28" />

<hstem pos="338" width="28" />

<hstem pos="632" width="28" />

<vstem pos="100" width="32" />

<vstem pos="496" width="32" />

  </hintset>

</hintSetList>

</data>

The format is also described in the header of the file:

the new file,

FDK/Tools/Shared/FDKScripts/ufoTools.py

[Tal Leming]

Hi Read,

Thanks for the very thorough documentation of this. I opened an issue over on our GitHub tracker and I'll start thinking about how this could be supported officially when I have some time.

Thanks,
Tal

> --
> You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Yuri Yarmola]

Hi Read,

It is OK if we will just follow this syntax to store t1 hinting data from our VFB format?

Yuri

[rrob...@adobe.com]

Hi Yuri;

Certainly. This syntax is intended as a proposal for public use, with no ownership or rights implied. The only caveat is that it it probably temporary - I expect that the UFO developers will not implement it as is when they get around to supporting hints in the UFO format.  If you want more examples,  the current public download of the FDK will work on UF font files, and will save the hint data in this syntax.

- Read