KeyError: 'post' on some fonts that have the 'post' table

I initially reported this as https://github.com/rosettatype/hyperglot/issues/24, but it seems to be a fonttools bug:

I’m seeing KeyError: 'post' on some fonts that have the ‘post’ table.

The attached ZIP contains two test fonts and a simple test script to reproduce the problem.

Here’s the script:

from fontTools.ttLib import TTFont

def process_font(path):
    print('processing: %s' % path)
    font = TTFont(path, lazy=False)
    cmap = font["cmap"]
    font.close()
    return [chr(c) for c in cmap.getBestCmap().keys()]

filename = 'NotoSansDevanagari-Regular.ttf'
c = process_font(filename)
print(len(c))

filename = 'NotoSansMalayalam-Regular.ttf'
c = process_font(filename)
print(len(c))

…and here’s what I get:

$ python3 fonttools_test.py 
processing: NotoSansDevanagari-Regular.ttf
270
processing: NotoSansMalayalam-Regular.ttf
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/fontTools/ttLib/ttFont.py", line 372, in __getitem__
    return self.tables[tag]
KeyError: 'post'

fonttools_test_with_fonts.zip

[justvanrossum]

The error message I got was: “ValueError: I/O operation on a closed file”. But it was reported as an error occurring during the handling of KeyError: ‘post’, which was confusing. (#2251 takes away the KeyError in this case, so it’s more obvious that there’s an I/O problem happening.)

[justvanrossum]

FWIW, I figured out why the one font failed and the other succeeded:

• cmap subtables are loaded lazily, and usually a subtable get decompiled only once you access its subtable.cmap
• When there are multiple subtables, it is checked whether there are subtables that have identical data offsets, and if so, it is ensured that only one subtable is decompiled
• The way this is implemented prevents to also do lazy loading, so the shared subtable’s data is decompiled immediately.

Ergo, in the hyperglot scenario / test script in this issue, if the source font has two unicode cmap subtables that share their data (which is common: (0, 3) and (3, 1) subtables are frequently both present, sharing their data) the cmap is loaded eagerly, and the premature font.close() doesn’t cause any trouble. But if the font does not share subtable data, cmap subtables are indeed loaded lazily, in which case the premature font.close() does cause trouble, as the glyph order has then not yet been loaded, and for that, the post table is needed.

Working font: two unicode cmap subtables Failing font: one unicode cmap subtable