The glyph coordinates in glyf table are going to be rounded when
writing out, so we should use the same mode of conversion to
integers. Otherwise the xMin of a glyph might end up being
different from its actual minimum X.
The `collections` module provides a set of abstract base classes that can be used to
test whether a class provides a particular interface (e.g. whether it is a mapping).
It's better if ufoLib uses that with `isinstance` rather than requiring instances of
`dict`, or subclasses of `dict`.
I noticed this issue while porting compreffor to py3. In my test fonts, the binary
CFF tables as generated with python 2 sometimes were slightly different from the
ones generated with python 3, although the TTX dump was identical!
It turns out, when running in Python 3, cffLib adds extra entries to the
list of CFF indexed strings, because of bytes vs str.
The `IndexedStrings.getSID` method takes an input string 's' and and returns
the SID integer for that string. If it's a new string, it gets appended to the
list, as well as to an internal strings-to-SID mapping, so that the same SID
value is returned for any given string.
The problem with python 3 was that, if the input string was of `bytes` type
instead of `str`, then the test for inclusion (the dict's `__contains__`)
would return False, and as a result the "same" string (e.g. "Regular" and
b"Regular") could be encoded twice in the list of CFF strings.
(yes, we desperately need unit tests for cffLib...)
This is a work in progress update of UFOReader and UFOWriter that
supports UFO in its package and zipped forms. Reading works. Writing is
not yet implemented.
I'm building a base file system (that lives on top of fs for now and
maybe in the long term) that the reader and writer then subclass. This
base class implements the file system interaction so that the reader
and writer can be blissfully ignorant about file systems.
Additionally, I ran into a problem with the local plistlib.py creating
an import error, so I've temporarily renamed it plistlibShim.py so that
I can continue working.
Did I mention that this is a work in progress? It's a work in progress.
The C implementation of ElementTree is included in CPython since 2.5.
It's got the same API and is up to 20 times faster than the Python implementation.
We'd better use it.
