With this I can finally follow xlink:href and url(#...) sort of
references within the SVG doc and subset the elements accordingly so
that only those that are reachable from the initial set of glyph
elements are kept.
support for namespaces and xpath is insufficient in built-in ElementTree; supporting both lxml and ElementTree is too complicated, let's simply require lxml to be able to subset SVG for now
this drops svg document records when they no longer intersect the subset. It keeps them in their entirety (for now) when they still intersect the subset, only renaming all the id='glyphXXX' to point to the new glyph indices after subsetting. Unused, unreferenced elements are not pruned yet.
relying on ClipList.compile to drop unused clips based on updated glyphOrder won't work when font is loaded lazily (default for subsetter), because ClipList gets decompiled too late (after glyphOrder has already been modified) and this produces warnings about missing glyphIDs.
Better to make the subsetter explicilty prune unused clips.
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
