Kashida-like function for other connecting scripts? (tracking/full-justification of scripts)

Erin McLaughlin

Hi all,

I've been wondering... has anyone developed/seen a non-Arabic connecting-script typeface (Devanagari, Bengali, Latin scripts, etc...) that uses a kashida-like function to elongate the connecting space between letters?

For those who don't know what I'm referring to, here's an example of some Arabic text in which the tatweel glyph is added in between other glyphs in order to "stretch out" the word, rather than stretching the space in-between words.

I know that some Devanagari and Bengali typeface designers have included a tatweel-like glyph that represents a horizontal section of "headline"/shirorekha. I always assumed that these were intended for designers to insert manually, but has anyone written a feature to have these automatically insert and extend when someone tracks out a word? Is that even possible?

I have a feeling that @John Hudson knows the answer to this question, at least


Edit:
I guess, more succinctly, what I should be asking is... has anyone in the past few years been able to figure out a way to avoid this from happening? Or are we still years away from being able to track out connecting scripts?

Kent Lew

I don’t think you can manage glyph substitutions from within the font based on tracking values. Unless I’m mistaken, tracking adjustments are applied much further downstream in the processing and there’s no way for the font to know about them, much less do anything.

I suppose you could experiment with making default glyphs with much longer extensions on the headline (i.e., greater default overlap), and then possibly do contextual substitution for initial and final forms with “normal” extensions at word boundaries. In that way, some tracking tolerance would be somewhat built-in. (Wouldn’t help in the case of varying lengths of ि, however; and you might also have to anticipate glyphs preceding थ ध भ, et al.)

But, I seem to remember John reporting that such initial and final substitutions were unreliable for Indic scripts in some renderers, for reasons I don’t recall now.

Georg Seifert

One could put some code in a stylistic set feature that adds a 'kasheda' between each connecting letter. That could not respond to applied tracking but you could track by selecting the feature. 

There is one exception. Apples AAT can respond to line length and other higher level measurements. But that would only work in apps that use the Apple text system.

Nick Shinn

You could make the left part of the top stroke extra long by default, so that it would overlap for a range of tracking, but substitute a normal version for the beginning of words etc.; as a calt or rlig feature.

Stuart Sandler

Michael Doret has used a really slick script on our Metroscript and his Deliscript fonts that automagically make tales under the words typed. It would be possible to apply this to space characters that preceded or followed the words typed.

John Hudson

As Kent says, there's no way to activate GSUB based on tracking values. However, what you could do is contextually insert a zero-width but visible head line extender between every pair of connecting letters. This would be invisible most of the time, but if the text were tracked out then the extender glyph would cover the gap.

Things to watch out for:

The extender glyph could be no wider than the narrowest connecting letter, so this would be the limit of tracking.

Not all software may track in the same way, so you'd need to experiment to see whether the extender glyph tracks with the first glyph or the second glyph of a pair (I'm guessing it stays with the first).

This doesn't take good account of the situation with letters that break the head line, e.g. थ or ध.

Some rasterisers may display rendering glitches when outlines are overlapped in this way.

Simon Cozens

Wouldn't OT justification (at least in theory) get you this? I know Behdad was implementing this in Harfbuzz and apps which use it.

Kent Lew

Nick’s refinement of my idea of built-in overlapping, by just extending one side of the headline, not both, so as to minimize need the “normal” alternates, is a nice improvement.

John’s idea is interesting, and gets around the problems with contextually substituting normal forms at word boundaries. FWIW, in InDesign the tracking essentially increases the advance width of the selected glyph(s).

PabloImpallari

Snake Justification https://xkcd.com/1676/
LaTeX implementation: http://tex.stackexchange.com/questions/307795/how-to-create-nonbreaking-arbitrary-length-snakes-for-full-width-justification

Khaled Hosny

Kashida justification, as implemented in virtually all applications that support it, works by inserting kashida glyphs after OpenType layout with no re-layout, so there is no way the font can control it or even implement it for other scripts than the application thinks need kashidas.

OpenType JSTF table is supposed to improve this, but I don’t know any OpenType implementation that supports it, and it wouldn’t help here anyway since it applies to justification not tracking. Also note that I don’t think there are applications that use kashida for Arabic tracking since kashida can’t be inserted between any arbitrary pair of glyphs.

Erin McLaughlin

Thanks so much for all the input, guys! I have some experimenting and reading to do...

John Hudson

I think it is important to distinguish what Erin is talking about, which uses the term kashida, i.e. elongation, as an analogy, from 'kashida justification', which is a set of (incompatible) algorithms used by software to justify Arabic script text by inserting spacing extenders of the baseline stroke (so not really elongation as practiced by calligraphers and, as Khaled notes, currently beyond the control of the font).

What Erin wants to do is provide head line continuity in tracked Devanagari. This isn't analogous to 'kashida justification', because it doesn't involve an algorithm inserting elements in the text string. The method I suggested — with the caveats mentioned — would enable Devanagari justification that involved adjustments to spacing of clusters, rather than the usual method that is restricted to adjusting inter-word spaces.