Improve varLib model algorithm.
This, basically means any varfont built that had an unusual master
configuration will change when rebuilt.
Here's a good test: a two-axis with 8 masters at unusual locations:
2-----------------5----------3
| |
| 7 |
| |
| 6 |
| |
| |
| |
0-----------4----------------1
Previously, the reach of master 3 (Black Extended) would
have started from A=.4, ie, the A position of master 4.
It now correctly starts from 0. Same thing with masters
after it. Ie, master 5 gets a span on the A axis from
0 to 1, whereas before it was getting from .4 to 1.
Previously, the on-axis masters always cut the space. They
don't anymore. That's more consistent, and fixes the main
issue Erik showed at TYPO Labs 2017. Same issue was also
causing the reach of master 3 to be limited, which I think
is the issue being discussed in the linked issue. Both should
be fixed.
It's hard to describe exactly what happened before / after.
Best to read the actual support values:
Before:
Sorted locations:
$ ./fonttools varLib.models 0,0 0,1 1,0 1,1 .4,0 .6,1 .5,.5 .7,.7
[{},
{'A': 0.4},
{'A': 1.0},
{'B': 1.0},
{'A': 1.0, 'B': 1.0},
{'A': 0.6, 'B': 1.0},
{'A': 0.5, 'B': 0.5},
{'A': 0.7, 'B': 0.7}]
Supports:
[{},
{'A': (0.0, 0.4, 1.0)},
{'A': (0.4, 1.0, 1.0)},
{'B': (0.0, 1.0, 1.0)},
{'A': (0.4, 1.0, 1.0), 'B': (0.0, 1.0, 1.0)},
{'A': (0.4, 0.6, 1.0), 'B': (0.0, 1.0, 1.0)},
{'A': (0.4, 0.5, 1.0), 'B': (0.0, 0.5, 1.0)},
{'A': (0.5, 0.7, 1.0), 'B': (0.5, 0.7, 1.0)}]
After:
$ ./fonttools varLib.models 0,0 0,1 1,0 1,1 .4,0 .6,1 .5,.5 .7,.7
Sorted locations:
[{},
{'A': 0.4},
{'A': 1.0},
{'B': 1.0},
{'A': 1.0, 'B': 1.0},
{'A': 0.6, 'B': 1.0},
{'A': 0.5, 'B': 0.5},
{'A': 0.7, 'B': 0.7}]
Supports:
[{},
{'A': (0, 0.4, 1.0)},
{'A': (0.4, 1.0, 1.0)},
{'B': (0, 1.0, 1.0)},
{'A': (0, 1.0, 1.0), 'B': (0, 1.0, 1.0)},
{'A': (0, 0.6, 1.0), 'B': (0, 1.0, 1.0)},
{'A': (0, 0.5, 1.0), 'B': (0, 0.5, 1.0)},
{'A': (0.5, 0.7, 1.0), 'B': (0.5, 0.7, 1.0)}]
TODO: We should add this as a test case.
There's another improvement I want to make, but that's separate.
This would make it easier to construct feaLib AST from code,
where the location is not defined and thus should be None.
Also, we can make other arguments as kwargs with a default
value, now that the first parameter is no longer 'location'.
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.
`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.
