jalt feature in Arabic fonts: support and practical experiences?

There is no implementation specification for the jalt feature (or, indeed, for OpenType Layout in general), which means neither application nor font makers have clear guidance on how it might work. It is one of those features that were registered fairly early, in a kind of speculative way: someone looked at Arabic text traditions and saw that sometimes wider forms of letters were used to justify lines of text, and thought ‘We should have a feature for that’, without considering further how the feature should be applied.

As it stands, the jalt feature is just a discretionary feature that a user could apply manually to characters within a line of text to improve justification (presuming that software provides access to the feature in the UI). There is no interaction between the jalt feature and justification algorithms in apps, and there can’t really be such interaction without radically changing how line-breaking and justification works in software. The problem is that all OpenType Layout GSUB and GPOS shaping is finished at the point when software applies line-breaking, because it is only after that processing that the software knows how many of the shaped glyphs will fit in the measure (the available line length). So there is no possibility to access GSUB after line-breaking, and the risk that if one were to run GSUB — or some portion of GSUB — again after line-breaking to improve justification, that could change the number of glyphs that fit on the line, triggering a change to line-breaking, triggering a new round of GSUB, triggering a processing loop.

Back in the mid-2010s, the ad hoc OTL working group that existed at that time spent a lot of time talking about this problem, and about how post-linebreak glyph layout could be applied and how it would have to work in order to avoid processing loops. Various ideas were discussed — my notion was a single OTL feature that ring-fenced post-linebreak substitutions and positioning, applied within algorithmic rules that ensured the output remained equal to or shorter than the measure — but in the absence of any more general implementation specification for OTL, there wasn’t any clear way forwards.

There is also the complication that justification mechanisms needs to be prioritised, especially in the case of Arabic, where several different methods are observed in calligraphy. That prioritisation needs to be applied as part of a justification algorithm, so that different methods can be applied in sequence to achieve best results, e.g. word-final extended forms first, then word-internal extended forms, then spacing adjustments. And if extended forms of different widths are available, one might want to balance them across the line. And these methods are always to some extent design-specific, and certainly style-specific: the methods of justifying naskh text are not the same as justifying nastaliq, for example. So that means that individual fonts may provide different methods, and expect different priorities. In my idea for ring-fenced post-linebreak OTL, lookup ordering could provide basic prioritisation: the layout engine would apply the first lookup, then the second, etc. and stop and step back when then resulting glyphs would exceed the measure.

The prioritisation complication is the reason why the JSTF table exists in OpenType. It too was defined very early in the history of OpenType, and like the jalt feature was sort of speculative. But it was at least defined by someone who understood the problem space and the kind of solution that would probably be needed, i.e. one in which individual fonts could contain information about what glyphs were available for justification and how to prioritise them, and for this to exist independently of GSUB. But no one implemented support for the JSTF table in applications, and to my knowledge @Simon Cozens is the only person who has seriously tried to implement it to determine if it could work or what else might be needed to make it work.