It seems like sets are hashed differently in CPython and PyPy.
Because of this, the returned list of class sets may have a different sort
order (within each class size) between the two implementations.
For now, I make the test pass on both CPython and PyPy by casting the returned
list of sets into a set of (frozen) sets, and asserting that its *content* is
correct, without considering the *order* of the sets in the list.
set objects have different __repr__ on python 2 and 3
Python 3:
>>> {1, 2, 3}
{1, 2, 3}
Python 2
>>> {1, 2, 3}
set([1, 2, 3])
(one among the several reasons I don't particularly like doctest...)
A couple of modules were relying on the fact that the 'sys' module was being implicitly imported by 'from py23 import *'.
The 'py23.__all__' does not include 'sys'. I think it's better to always import 'sys' explicitly when needed.
Since py23 modifies some essential builtins, it's safe to import
everything all the time. At least, that's how it was designed.
It's a bug if importing * breaks some code.
The previous 'allXMaxIsLsb' name was misleading.
The 'allXMinIsLsb' boolean variable cooresponds to the head table's Bit 1.
This is set whenever all glyphs have the bbox.xMin equal to the respective
left sidebearing (and therefore "left sidebearing point at x=0").
Today, Apple has kindly fixed a bug in the [specification of the
meta table](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6meta.html). The existing fonttools implementation matches the
revised specification. Therefore, the comments about fonttools
intentionally deviating from Apple's spec can be removed.
'featurefile' can be either a path (string) or a file object, like in TTFont or XMLReader and XMLWriter constructors.
If a file object does not have a 'name' attribute, a default "<features>" name is
used and the current working directory is assumed as the root for relative includes.
The code that is being removed is untested and does not seem to make
fixing an overflow any easier. The fixer code just needs to know
which subtable caused the overflow and does not care about the item
within. As such, no point in trying to find a "right" item.
In fact, leaving item as is, is more useful in debugging overflows
as it reflects which item's offset actually overflowed.
Part of fixing https://github.com/behdad/fonttools/issues/537
