NeuralType: A Post-OpenType Font Format

The inflexibility of OpenType shaping and the existence of a fixed set of alternate glyphs is certainly a limitation which makes certain Arabic styles very difficult. But I'm not terribly convinced that this justifies something like a ML model for every glyph; the principles of efficiency and simplicity suggest we should at least attempt to find the smallest set of primitives which could bridge the gap. An obvious extension of the OpenType model which would do this would be to allow multiple axis positions within a single glyph run, and to allow contextual shaping rules to affect or set per-glyph variable glyph axis positions. This would allow glyphs within a parametrically designed font to stretch, lengthen, twist and turn to match the surrounding glyphs in their contexts.

John Hudson said:

We certainly need a technology that a) can work as widely as OpenType and b) is capable of handling all the dynamic complexity of nastaliq and other cascading Arabic script styles. In recent years, brute force GPOS contextual lookups have gotten us further than before, thanks to Simon Cozen’s upstream tooling, but it still isn’t as flexible as the script grammar employed by a trained scribe.

A dozen or so years ago, I was able to sit down with Eliyezer Kohen, one of the original inventors of OpenType Layout, and talk through the difficulties of cascading Arabic. He told me something that neither I nor any of my colleagues working with Arabic to that date had been aware of: he never expected OTL to be able to handle cascading Arabic, which he considered to be outside the scope of the technology. Unfortunately, this information was lost because Eliyezer had left Microsoft before OpenType became widely adopted. As Eliyezer put it to me at the end of our conversation, he had been happy in the mid-1990s to target 98% of the world with OTL and for Tom Milo to have the rest.

A lot of time and effort has been wasted over the years trying to force cascading Arabic into OTL.

The technology exists for decades made by Decotype, as well since this year with out solution as well. The only problem is the lack of interest and knowledge. Steve Jobs wanted to implement Decotype's solution, but he died soon after that, and the management later didn't care about the idea, since the "users didn't complain". The same users who until today don't know the difference between quasi-Arabic and real Arabic script.

As well Decotype's fault is for not keeping the products transparent and publishing more on it, so there is always two sides of the story.

We in Kunst X developed the multilingual workflow in our Pub Suite beta branch with custom engine. So far it has only lame bitfont example, but the architecture is there ready to implement any world script with all advanced features.

Eli Hauer is going in the interesting direction. I adviced him. If he listens and learn certain script grammar foundations and implements that, he will produce a good out come as well. If he stays stubborn, he will just prolong the slop of the past in little more advanced shell.

So far the tech side is covered, only interested and aware group of typeface designers and developers are needed to implement the tech. Producers of engines on which OTF runs can't produce better even when they would want, since they first need to hire linguistics and typography experts to advice them.

All or most of the current Arabic typeface designers are people who follow ways of amateur orientalists who thought they know about Arabic script, and created this awful structure of Venezian-Arabic/Euro-Arabic, quasi-Arabic script, which is an approximation of Arabic, mutilated and forced into the "western" typesetting enviroment.

We could pretend that these problems are not influenced by world politics, colonial narratives, Stockholm syndrome of countries using non-Latin scripts, and "western" industry domination, but let's not pretend.

Changes need time, but not so much time as the overall interest.