I'm also unimpressed by the copy-pasted bounds logic in hhea and vhea,
and the fact that that's coded in there instead of calling a function
on CFF / glyf tables respectively.
all otData arrays are decompiled as lists (see otConverters.BaseConverter.readArray).
If one tries to call the subsetter on a GSUB table that was not read from file
but was just built from feaLib, it crases with a TypeError because it's expecting
list but finds tuples.
Traceback (most recent call last):
File /home/clupo/Github/fonttools/Lib/fontTools/subset/__init__.py, line 1462, in prune_lookups
lookup_indices = self.table.FeatureList.collect_lookups(feature_indices)
File /home/clupo/Github/fonttools/Lib/fontTools/subset/__init__.py, line 1263, in collect_lookups
if i < self.FeatureCount), [])
TypeError: can only concatenate list (not tuple) to list
Travis CI has been experiencing maintainance problems with the OSX infrastructure
and it has become too slow. It's better we temporarily enable 'allow_failures'
in combination with 'fast_finish' for the OSX builds, so that the CI goes green
as soon as the other builds have completed.
`tables=None` by default will build all supported tables;
To build only some of these and ignore the others, one can pass a
subset of supported tables tags: .e.g. `tables={'GSUB'}` will only
build the GSUB, even if the feature file may contain e.g. GPOS
related features.
Currently, the feature file parser always resolves included files,
parses their content and inserts it in the resulting AST. The original
`include` statement is lost.
This commit introduces an option to not follow inclusions. Instead, the
output AST will contain an `include` statement. This allows to process a
feature file on its own, and allows to round-trip it.
For example in glyphsLib, when going from a UFO to a .glyphs file, a
UFO feature file will be sliced up into Glyphs.app classes (e.g. a
GSFeaturePrefix with code `include(../family.fea);`) and when going back
from .glyphs to UFO, the feature file will be patched back together.
same as harfbuzz hb_script_get_horizontal_direction.
We just hard-code the set of RTL script here, as it doesn't change often anyway.
The function is just syntactic sugar as it all does is basically looking up the
constant RTL_SCRIPTS set.
It's nice to have it here in a central place alongside 'script', 'script_name', etc.
