search

fontforge / fontforge

Free (libre) font editor for Windows, Mac OS X and GNU+Linux
http://fontforge.github.io/
Other
6.35k stars 695 forks source link

UFO: support AFDKO T1 hints syntax #1933

Open adrientetar opened 9 years ago

adrientetar commented 9 years ago

So currently it looks like we are outputting T1 hints to UFO under the com.fontlab.hintdata namespace. I don't know what the vendor support for this is aside from FontLab but if we adopt the AFDKO syntax we could run makeOTF on UFOs directly.

FontLab will be using it in FontLab VI (maybe we want to support both for now?).

davelab6 commented 9 years ago

Supporting both and having flags to select which to output would be good

davelab6 commented 9 years ago

The FDK syntax breaks the spec, so I'm not sure this is good. Looks like @readroberts will update the FDK to use a new plist-compliant form so when he had done that then we should support it

adrientetar commented 9 years ago

Agreed.

readroberts commented 9 years ago

I originally planned to get to this sometime in the next year, but since the non-list compliant issue is breaking workflows, I'll try to make the changes to the FDK tools in the next month.

I hope that this representation will evolve further. I think it is useful to have a Type1hint data representation specified in UFO so that multiple developers can share tools. and it would be nice to get it out of the glyph.lib private data, so it could be XML instead of plist compliant. That said, I am in no hurry to see anyone spend a lot of time on this. This may be somewhat Adobe-centric, because in the Adobe Type Dept, all Type1 hinting data is temporary stuff that people don't need to be able to read/edit easily. This is because we work fairly hard at not manually editing hint data. Manual hints are a pain for long-term font maintenance, because if you edit the manually hinted glyph, you must manually hint the glyph again, and you need smarter tools than we have in order to tell you that the hints need to be redone. We can usually fix problems with autohinting by manipulating alignment zones or the outlines. As a result, the T1 hint data in our UFO based workflow is really just a private cache of temporary data, required for building the final font. I did look at not caching it all, which would have avoided the need for a UFO representation, but unfortunately this made rebuilding the final OTF after editing the source UFO data painfully slow - 10's of seconds per face. This is why an important part of the FDK workflow is not only the T1 hint data, but also logic for noticing whether not the glyph data is been changed since it was hinted, so the autohinter can decide whether or not the glyph needs to be hinted. I bring all this up because I hope other tool developers will support a similar approach to handling T1 hinting - make it easy to build final fonts without saving permanent hint data - or have some system to discard hints from glyphs that have been edited.