Note: the `expect_ttx` test is passing, but the `check_ttx_dump` which ensures the TTX dump is the same after saving and reloading the font, is currently failing, as the "ValueRecordSize" count is None
```
--- /Users/cosimolupo/Documents/Github/fonttools/Tests/varLib/data/test_results/Build.ttx
+++ /var/folders/7k/fl5q53lj51g0d8hxdkrx9_z80000gn/T/tmpoBCAua/tmp1.ttx
@@ -174,8 +174,7 @@
<MVAR>
<Version value="0x00010000"/>
<Reserved value="0"/>
- <ValueRecordSize value="8"/>
- <!-- ValueRecordCount=2 -->
+ <ValueRecordSize value="None"/>
<VarStore Format="1">
<Format value="1"/>
<VarRegionList>
```
* Initialize the avar segment map with required default entries
* Set default values only after deciding that a segment map is needed for this axis
* Correct dict update call
There can only be one TopDict in an OpenType font, whether CFF or CFF2;
plus in the latter, TopDict INDEX and Names INDEX are gone, just the
one TopDict is left. Most of the time, one simple wants to get to
that single TopDict instance.
So instead of doing this:
topDict = font['CFF '].cff.values()[0]
one can alternatively do this now:
topDict = font['CFF '].cff[0]
Pass a maximum lookback of n to the circle-breaking DP of size 2*n.
This should theoretically speed up that DP by a factor of 4 or 8 or something...
Empirically it's far from that, but solidly measurable.
Again, gvar table size got a slight improvement, which I didn't expect... It
might be that my one test is hitting lucky cases with point encodings.. or it
might be just me wishfully thinking so.
Drives it into acceptable speed now. Note that I'm getting better
gvar size after this patch, which I didn't expect. So, either this
algorithm or the previous one was buggy. :(
The `_SimpleT2Decompiler.execute` method expects that handlers for
hintmask/cntrmask operators return a tuple of (hintMaskBytes, index).
The index value is used to skip to the next token following the
hintmask bytes.
However, the `_DehintingT2Decompiler.op_hintmask` method was returning
None, thus the hintmask bytes were evaluated as the following token
instead of being consumed as such; but since in legacy python 2
`isinstance(token, basestring)` is True for both operators and
hintmask bytes, the latter might sometimes be wrongly interpreted
as operators!
For example, the hintmask bits '0110111101110010', encoded as a
bytes string `'\x6f\x72'` was being confused for the unimplemented
`'or'` operator...
Fixes#1006
