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. :(
Otherwise it will try to sniff the plist format and call `seek`
method on the file object, but the zip filesystem does not support
that...
UnsupportedOperation: seek
in pyfilesystem2, movedir copies the content from one directory to
antoher, optionally creating the destination if create=True.
When the destination is exists and is a directory, shutil.move moves
the source directory inside the destinatinn directory.
shutil.copytree also fails if the destination already exists; so here
we resort to distutils.dir_util.copy_tree (it's part of python std lib)
The 'mode' and 'allow_zip_64' arguments are no longer there in
pyfileststem2's zipfs module; allow_zip_64 is the default now,
and the 'mode' is replaced by a 'write' boolean argument
The "contents" root dir must be created manually.
as pyfilesystem2 works internally with unicode strings, some methods
(e.g. self._fs.exists()) fail with TypeError if passed bytes strings
(on python 2 bytes == str).
We decode bytes path strings using the system's default filesystem
encoding.
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
* Removed `CFFContext`
* Added `isCFF2` argument to CFFFontSet.decompile/compile, used from
respective ttLib classes
* Index classes get a `isCFF2` argument in constructor (used for
decompiling); must be True/False if `file` argument is not None;
it is stored as self._isCFF2 to support lazy loading
* Removed `TopDictData` class; reuse same `TopDictIndexCompiler` for
both CFF and CFF2
* `CFFWriter` and all `*Compiler` classes get an `isCFF2` argument;
defaults to the parent compiler's `isCFF2` attribute
* Removed `size` argument from `produceItem` method as unused and
useless (`len(data)` is the same)
* psCharStrings: removed useless ByteCodeBase class
* A reference to the TopDict's VarStoreData is passed down to all
the FontDicts' PrivateDict, so it can be used to get the number of
regions while decompiling blend and vsindex operators
See dicussion:
https://github.com/fonttools/fonttools/pull/968#issuecomment-309920007
