Where more than one run is used, it's only the first run's first point
that is absolute, all other values are relative.
Similar fix landing in FreeType soon. Fixes lizzard glyph (glyphname
"dollar") in Zycon.
Changed the merge algorithm to properly handle cmap subtables
of type 4 and 12 with platform id and encoding ids of 3/1 and 3/10
respectively. All other subtables are not merged and ignored.
The resulting merged cmap table includes a subtable of format 4/3/1
and a format 12 subtable iff there are mappings outside of the BMP.
If one font has two codepoints that point to the same glyph,
and another font has the same code points pointing to two other glyphs,
keep the behavior where the first replacement glyph is stored in 'locl'
and output the third glpyh (or more) to let the user know that they were
dropped, instead of failing to merge the font.
Fixes#444Fixes#322
Before, if someone tried to set the language before setting the script
a None/language language system would be created (with actual tag
"None" stored in the feature table). This defaults to tag DFLT and
fails when a non-dflt language is set for DFLT, since that's illegal.
This is to fix what I think was a misunderstanding of the exclude_dflt
keyword (and the implicit include_dflt option active by default).
Rather than including the following lookups in the default language
systems, I think it is used to include the lookups specific to default
language systems in the system defined by the current language
statement. Thus instead of registering a lookup in all default
systems when include_dflt is true, we should exclude the lookups
registered with default systems from the current system when
include_dflt is false.
The glyph coordinates in glyf table are going to be rounded when
writing out, so we should use the same mode of conversion to
integers. Otherwise the xMin of a glyph might end up being
different from its actual minimum X.
I noticed this issue while porting compreffor to py3. In my test fonts, the binary
CFF tables as generated with python 2 sometimes were slightly different from the
ones generated with python 3, although the TTX dump was identical!
It turns out, when running in Python 3, cffLib adds extra entries to the
list of CFF indexed strings, because of bytes vs str.
The `IndexedStrings.getSID` method takes an input string 's' and and returns
the SID integer for that string. If it's a new string, it gets appended to the
list, as well as to an internal strings-to-SID mapping, so that the same SID
value is returned for any given string.
The problem with python 3 was that, if the input string was of `bytes` type
instead of `str`, then the test for inclusion (the dict's `__contains__`)
would return False, and as a result the "same" string (e.g. "Regular" and
b"Regular") could be encoded twice in the list of CFF strings.
(yes, we desperately need unit tests for cffLib...)
