This is a breaking change (but the COLRv1 API was already marked as unstable and subject to change)
The changes in this PR are meant to match the changes from the COLRv1 draft spec at:
https://github.com/googlefonts/colr-gradients-spec/pull/302
This does two things:
1. Intersect subsetter glyphset with the table's Coverage before
passing to ClassDef1 for subsetting. Anything that doesn't
get past Coverage wouldn't ever get to ClassDef1,
2. Never reuse class0 of ClassDef2. There's unspoken assumption
that ClassDef2's class0 is never used for actual kerning, since
that's the unbounded "every other glyph" class. Previously our
ClassDef subsetter was reusing class0 if "every other glyph"
happened to become empty because of the subset glyphset. Don't
do that for PairPos's ClassDef2. As a result of this assumption,
don't keep a PairPosClass2 subtable if only ClassDef2's class0
survived subsetting.
Would be good to add tests for both.
Related to https://github.com/harfbuzz/harfbuzz/issues/2703
* Replaced all from ...py23 import * with explicit name imports, or removed completely when possible.
* Replaced tounicode() with tostr()
* Changed all BytesIO ans StringIO imports to from io import ..., replaced all UnicodeIO with StringIO.
* Replaced all unichr() with chr()
* Misc minor tweaks and fixes
In COLR.closure_glyphs augment the subset with the glyphs rechable from the COLRv1 base glyphs already in the subset.
In COLR.subset_glyphs, subset and rebuild LayerV1List and BaseGlyphV1List with the base glyphs to keep. Drop COLR if emptied
Allow specifying which LangSys tags to accept for each script, using
script.lang form. For example:
--layout-scripts=arab.dflt,arab.URD,latn
To keep DefaultLangSys and “URD” language for “arab” script, and all
languages for “latn” script.
While False does get the job done, the value is not always treated as
a boolean. It is overloaded so that 1 or greater is True, but more than
1 has a different meaning than 1. Hence usage should always be as an
integer as documented so that it's clear(er) this isn't just an on/off
toggle.
This import is causing an unsightly DeprecationWarning.
I checked manually: the only names being used from py23 are
open, range and zip, which are defined to be the same as the
corresponding Python 3 builtins, so this should cause no
visible change except for suppressing the warning.
This adds a `help` verb (and `--help` option) to the `fonttools` command line tool. Submodules will be listed in the help text if they have an importable `main` function with a docstring, and `main`'s docstring will be used as the one-line description for the help text.
Fixes https://github.com/fonttools/fonttools/issues/1879
In ChainContext{Subst,Pos}Format3, the array of input coverages is called
InputCoverage, whereas in non-Chain Context{Subst,Pos}Format3 subtables it
is called simply Coverage.
After subsetting some strikes might be empty (strikes don’t have to
cover all glyphs equally) which would cause a key error later when
saving the table.
Fixes https://github.com/fonttools/fonttools/issues/1633
When --recalc-bounds option is used the font extents in the head table
need to be updated, but since tables are lazy-loaded by default the
table will not be recompiled and will keep the old value. Force
recompiling the table by adding it to prune_post_subset tables, though
I’m not 100% sure this is the best approach.
deltas in VarData[0] are directly look up by GID so compacted
if any deltas are referenced by LsbMap / RsbMap but not used for advance widths, they are moved to the end of VarData[0]
updated expected test result expect_HVVAR.ttx accordingly
