[HarfBuzz] 'calt' in Indic shaper

[John Hudson]

On 07/08/13 3:45 AM, Jonathan Kew wrote:

> A somewhat analogous case might be discretionary features in Arabic,
> where (according to http://support.microsoft.com/kb/2786400 - I didn't
> test this explicitly) the behavior in Win7 was recently changed to NOT
> apply "discretionary ligatures and contextual alternates" by default.
> ("Discretionary ligatures" there clearly refers to 'dlig'; I wonder
> whether "contextual alternates" means 'calt', or whether perhaps it
> really refers to 'cswh'?)

If it applies to 'calt', then that introduces a discrepancy between 
Arabic layout and the recommended implementation for that feature in the 
registry: "This feature should be active by default." I think it would 
be preferable to have this feature behave the same way for all scripts: 
on by default and possible to turn off. Having it on for some scripts 
and off for others would be confusing.

> The Indic 'calt' discrepancy we ran into that triggered this question
> appears to actually be the features-across-cluster-boundaries issue. In
> uniscribe, 'calt' does not apply across cluster boundaries; in harfbuzz,
> it does. This leads to many unexpected differences: e.g. in Gujarati,
> the "pseudo-ligation" of <U+0A9C,U+0AAF>, and in Devanagari, the
> insertion of a top-bar-extender glyph after many clusters with both an
> above-vowel and an anusvara, e.g. in <U+092C,U+0948,U+0902,U+0915>. This
> often gives an inferior appearance; the font designer must, I assume,
> have intended this insertion for specific problem cases -within- a
> cluster, to avoid overcrowding the above marks, but not -between- clusters.

I was worried that such fonts might exist. Can you provide some examples?

> So as things stand, disabling 'calt' in harfbuzz significantly improves
> our results for Devanagari with Nirmala; however, in Gujarati, while it
> fixes the discrepancy for <U+0A9C,U+0AAF>, it introduces new problems
> such as <U+0A97,U+0ACD,U+0AA8> where uniscribe -is- applying 'calt'
> within the cluster to choose an alternate form of the NA glyph.

As I wrote in my analysis of the Indic layout problems, typography 
involves relationships of glyphs, not of character processing clusters. 
Once clusters are shaped, they are in relationships with adjacent 
clusters, and there *has* to be a mechanism to affect those 
relationships, even for the sake of legibility in some cases (see my 
Gurmukhi examples). I really don't see a way around this

> Agreed - and we're certainly prepared to deviate from uniscribe where it
> is clear that its behavior is broken, inadequate or otherwise
> problematic. But OTOH where the specs are underdefined, or where it's
> more a question of picking among alternative models - such as whether a
> given "discretionary" feature is opt-in or opt-out - there's a great
> deal to be said for consistency, and in most cases it should probably
> trump our own preferences, so that font developers can target a single
> pattern of behavior.

Agreed, but I think a single pattern of behaviour should involve the 
typographic features -- as distinct from the specific script shaping 
features -- behaving the same way for all scripts.

> In the case of Indic 'calt', applying the feature globally by default is
> problematic because the 'calt' lookups in Nirmala appear to have been
> designed on the assumption that they will -not- take effect across
> cluster boundaries. But disabling it globally is also problematic; the
> only way we can get Nirmala to render as (apparently) intended will be
> if we restrict the 'calt' feature to apply only -within- clusters.

I built the Nirmala UI fonts, and I can assure you that I did *not* make 
the 'calt' lookups with the presumption that they will not apply across 
cluster boundaries. Indeed, the head line insertion lookups in the 
Devanagari involve explicit contexts that only exist across cluster 
boundaries, and only exist after shaping and reordering has taken place. 
These are designed to avoid collisions between shapes above the head 
line, as in the documented Gurmukhi examples in my document.

Again, cross-cluster relationships exist at the glyph level, and hence 
it is essential that font developers be able to address these. 
Otherwise, we can't do Indic typography.


JH


-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

Getting Spiekermann to not like Helvetica is like training
a cat to stay out of water. But I'm impressed that people
know who to ask when they want to ask someone to not like
Helvetica. That's progress. -- David Berlow