If a zero value appears in a SinglePos statement, feaLib continues to
produce ValueRecords of format 0. But if a zero value appears in a
PairPos statement inside a horizontal compilation context, feaLib now
produces ValueRecords of format 4. Likewise, if a zero value appears
in a PairPos statement inside a vertical compilation context, feaLib
now produces ValueRecords of format 8.
The OpenType Feature Syntax specification is completely silent about this,
but the new behavior matches that of makeotf.
https://github.com/fonttools/fonttools/issues/633
`font.FDSelect[i]` returns a GID, not an index of `font.FDArray`.
Before this commit `.notdef` might have wrong glyph width in CharStrings,
if its fdSelectIndex is not 0 in the input font.
We now correctly handle nameid statements with surrogate pairs and
old-style macOS-encoded names (provided that fonttools supports the
specified encoding).
Resolves https://github.com/fonttools/fonttools/issues/842.
Also fixes a bug where glyph alternates in MTI feature files were
wrongly sorted by glyph name. After this change, the output is using
the same ordering as in the input MTI feature file.
Fixes https://github.com/fonttools/fonttools/issues/833.
So we have:
descriptor.filename: the path to the UFO, relative to the documentpath
descriptor.path: the resolved, absolute path to the UFO
This means we have to be aware of a couple of situations, described in updatePaths() and testPatgNameResolve().
Case 1: both filename and path attributes are None. Action: write the descriptor as is, without filename attr.
Case 2: filename attribute points somewhere, but the path attribute is None. So we can't actually verify if the UFO really exists, but we don't have to. Action: write the filename attribute as is. We could calculate a new path though.
Case 3: filename attribute is None, path attribute has a path. So there is no legacy value for filename that we need to look out for. Action: we can calculate a new relative path and store that in filename.
Case 4: filename and path attributes are not None, but they're in conflict, pointing to different places/ So the absolute path of the UFO and the absolute path of the document produce a different relative path than is stored in filename. One of them must be wrong.
When a new filename is set, make sure to set the path attribute to None and vice versa.
