WIP: Add fontGlyphs. A module to get all font glyph inputs

[m4rc1e]

I talked last week about having a better HBInputer generator (I've wanted to write this for years) so I decided to write one using this Lib.

Improvements over HBInput:

• Faster
• Output isn't random, Fixes https://github.com/googlefonts/nototools/issues/500
• Allow users to enable/disable OT features and choose scripts and langs. This mimics the behaviour of DTP apps. HbInput will try and get all features in one go. This often leads to an over use of the "aalt" feature since lookups for this feature are often ordered first.
• Proper handling of contextual and chaining lookups. HBInput will try to map each input to a glyph. fontGlyphs maps to input sequences instead of glyphs.
• locl feature support. We can choose script and lang :-)

If I run this on Poppins, we get 36,000 possible inputs

# simple
 'dvDD_RA': {'features': {'rkrf'}, 'input': 'ड्र'},
 'dvDD_VA': {'features': {'half', 'pres'}, 'input': 'ड्व'},
 'dvDD_YA': {'features': {'half', 'pres'}, 'input': 'ड्य'},
...
# contextual
dvK_KA-dvmII': {'features': {'half', 'psts', 'pres'}, 'input': 'क्की'},
'dvKxA-dvmII_Anusvara': {'features': {'psts', 'abvs'}, 'input': 'क़ीं'},

Todo:

• Tests
• Logging
• name/cleanup

@simoncozens I may need to chat to you at some point about some of the assumptions I'm making. They don't feel quite right.

[ctrlcctrlv]

I don't quite get what this is for, or why it should be in the default distribution, which as I understand it is meant to support FEE. Why not have this in a separate GitHub project? Maybe Simon disagrees though. I think if there's no direct relationship to improving FEE it should probably not be in this repository.

[m4rc1e]

Having the ability to access all glyph inputs in a font is very useful for QA purposes. It gives us the ability to check whether an updated font's glyphs/inputs are still accessible.

I think if there's no direct relationship to improving FEE it should probably not be in this repository.

I don't mind if this exists in its own repo. However, I've included it since this repo also has other helpful utils like otf2fea.

[simoncozens]

Just as a general point, the fontFeatures distribution is not primarily about supporting FEE. In fact I do wonder if FEE belongs in a specialised repository. For example, Flux uses fontFeatures to model OTL operations, and fontFeatures.shaperLib to execute them, but it doesn't use FEE. (Indeed, FEE doesn't use the shaperLib at all, although it probably should in places.) fontFeatures is a general object model for OpenType Layout, FEE is something cool you can do once you've got such an object model.

That said, I can see that this might be potentially useful for building FEE plugins. I need to get my head around it. "Get glyph inputs" is a bit vague, so we may need to find a better way to explain what it's doing. I'm guessing it's basically "running the shaper backwards": "find me a combination of features/input that leads to a given glyph", right?

[m4rc1e]

I'm guessing it's basically "running the shaper backwards": "find me a combination of features/input that leads to a given glyph", right?

Kind of. It's more "give me all possible glyph input sequences for a given Script, Lang and set of OT features". e.g

>>> `FontGlyphs.inputs(script="DFLT", lang="dflt", features=["liga"])`
[
    {"input": "ff", "features": {liga},
    {"input": "ffi", "features": {liga}
]

Agree that naming and code is substandard, so it shouldn't be examined too deeply. I mainly made the PR since Simon works at 7500rpm so I was worried we may be working on the same thing.

[ctrlcctrlv]

Just as a general point, the fontFeatures distribution is not primarily about supporting FEE. In fact I do wonder if FEE belongs in a specialised repository.

I would support moving feeLib to its own repository called e.g. fee-language or even simoncozens/fee. Please wait for me to push and you to review and merge my change to the parsing engine first though since it covers a lot of ground.

[behdad]

Thanks Marc. This is nice.

To add my perspective: to generate sequences that exercise features of the font is indeed a good goal. I've been wanting to do that as part of a package to automatically generate specimen for fonts. Fetching the chain sequences from the font is easy. But when you get to the script-specific shaper logic is where we lose..

The holygrail would be, for a given gid, enumerate all minimal input sequences that generate that gid...

[m4rc1e]

The holygrail would be, for a given gid, enumerate all minimal input sequences that generate that gid...

Agreed. Perhaps it would be best if such a feature was in HarfBuzz instead of a python lib? also if I was to undertake this task, could you help plan/architect?