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...)
All these debug messages were disabled, and I don't wish to re-enable them
while running TTX in verbose mode. So here I use a custom level less than
logging.DEBUGm to make sure they will be muted even when the logger's level
is equal to logging.DEBUG.
The latter hits the __eq__ method and can fail because we now
do not allow comparing objects of different types.
For example, was failing subsetting Andika-R.ttf.
Our footprint in the Python module namespace is all under
fontTools now. User code importing sstruct should be updated
to say "from fontTools.misc import sstruct".
# 1) speed optimizations
# 2) fixed parseCharset0 to support CFF-CID fonts.
# 3) fixed CharsetConverter.read to work a font that actually has one
of the pre-canned encodings.
# This fixes a stack dump.
# I did not try to support using these encodings when writing a font,
# as the cases will be so rare as to not justify the processing
overhead for all other fonts.
(Read: I took out some of your loop optimizations since I believe they
made the code a lot less clear. I also have my doubts whether they were
actually performance improvements.)
git-svn-id: svn://svn.code.sf.net/p/fonttools/code/trunk@509 4cde692c-a291-49d1-8350-778aa11640f8
T{1,2}OutlineExtractor is not backwards compatible and this change
basically makes them private classes: CharStrings now have a .draw()
method that takes a Pen object (see fontTools.pens.*), so you never
have to deal with the extractor objects yourself. Only lightly tested.
git-svn-id: svn://svn.code.sf.net/p/fonttools/code/trunk@417 4cde692c-a291-49d1-8350-778aa11640f8
