Avoid "reloading" TTFonts in PostProcessor.__init__

Going from https://github.com/fonttools/fonttools/issues/1095, quite some time is spent serializing/deserializing fonts somewhere inbetween compiling the final binary. This slows down the entire process. PostProcessor.__init__ seems to “reload” every font, maybe to clean up loose data? I think it should maybe just work with what it’s given?

[behdad]

Would this conflict with fT’s ability to carry and serialize meaningless/wrong input data in loaded fonts or is it sufficiently high level that that makes little sense?

The count values are always ignored when compiling the font.

Is that even a design goal?

Nope. We don’t even pretend.

These *Counts are written as comments in TTX, so probably can be kept regardless of the API change. In Python, LookupCount would be replaced by len(Lookup) and so on. May be the first step would to stop using these *Counts internally but set them when decompiling, so code building tables from scratch don’t have to set them, and later be removed entirely.

Or replace them with properties that warn when accessed; set a deadline for removing them, and advise code to switch. The replacement code can even be offered in the warning.

[behdad]

So, a lot of this would be a non-issue if we were dealing with immutable data types, such that any modification would involve copy-on-write duplication… Many functional languages work that way. In Python, I’m sure there’s some dark black magic with metaclasses to get some of that, but there will be dragons. Also, there’s no way to get compile-time errors for violations with Python.

Anyway, attrs2 on this: https://www.attrs.org/en/stable/examples.html#immutability