Good question. Here are two easy-to-understand and philosophically valid answers, that are not the real reason why I'm doing this:
- Because the whole font ecosystem is written in Python, so there should be a Python shaping engine.
- To understand how Harfbuzz works and make that easy to understand for others.
- To provide an independent reference implementation of OpenType shaping.
- To allow for customization and instrumentation of shaping operations.
Here's the real reason, which is a bit more tricky to grasp: I'm writing an intelligent layout rules creation system, and as it's creating rules, it needs to be able to reason about the effects of the rules it's created thus far. So I need a shaping engine which is able to take in a set of glyphs, rather than characters, and partially apply a subset of shaping rules to determine the "state of play" so that it can emit further rules based on that.
Let's motivate that with an example. If you have an Arabic font with a cursive positioning feature (which was auto-generated by your anchor rules), the layout system may then want to apply further positioning rules to do collision avoidance. So you need to run your current positioning rules on a string of glyphs to determine their positions, working out if there are collisions, then emit new positioning rules to avoid those collisions. This is a lot easier to do if you can "plug in" to various stages of the shaping process and introspect the output.
Eventually the plan is that namvezvez will take a set of fontFeatures objects as well as a font, but that can only really happen once I have ordinary OT shaping working.