Which OpenType feature could I use instead of contextual alternates?

Bhikkhu Pesala

I added a contextual ligature feature to some of my fonts, which uses the Velthuis encoding system.

Some Buddhist scholars use this method for writing Pali as it requires no special fonts to be installed that supports the diacritics. If the contextual alternates feature is applied to Velthuis encoded text in my fonts, it switches to text with the correct diacritics. So, for example: 

Eva.m me sutta.m — eka.m samaya.m Bhagavaa karuusu viharati kammaasadhamma.m naama karuuna.m nigamo

would become:- 

Evaṃ me sutaṃ — ekaṃ samayaṃ Bhagavā kurūsu viharati kammāsadhammaṃ nāma kurūnaṃ nigamo

This is all well and good in PagePlus, where Contextual Ligatures can be disabled or enabled as required.

However, someone recently submitted a "bug report" presumably because they typed an abbreviation like A.D. and were surprised to see it change to AḌ.  I think some applications apply calt by default with no option to disable it!? 

Is there some other feature I could use instead of calt?

My fonts already have Standard Ligatures (liga), discretionary ligatures (dlig), historical ligatures (hlig), Stylistic Alternates (salt) to replace the now obsolete Initial Forms for Decorative Drop Capitals, and Character Variants (cv01) for quick access to symbols. 

Nick Shinn

Could this be remedied with a language tag in the <locl> feature?

Bhikkhu Pesala

Nick Shinn said:

Could this be remedied with a language tag in the <locl> feature?

I was surprised to find that there is a language tag for Pali. 

How would the application know that the language in use was Pāḷi?  

I tried, but PagePlus doesn't know anything about the locl tag, not even for Romanian, and there's no Pali language to select.

I tried adding a second dlig feature, but that is just treated like a single feature with both substitution tables. I don't really want discretionary ligatures like cky to be enabled just to type Velthuis encoded Paa.li text. 

John Hudson

How would the application know that the language in use was Pāḷi?  

The text language has to be tagged by the user, and may also be limited by software. I reckon if a user is sophisticated enough to know about language tagging, he or she is probably going to have access to Unicode fonts that support Pali diacritic characters, appropriate keyboards, etc.

I understand what you are trying to do, but it's never going to be a reliable mechanism to handle this at the glyph display level. I would be trying to encourage such scholars to work with character substitution macros, so they can type text using this kind of simplified input, and then have it converted to standard Unicode for the diacritics.

Over the years, I have worked with scholars of ancient Greek, Sanskrit, and other languages who have relied on non-Unicode input methods and fonts for many years. It's always been best to help them transition to Unicode, rather than trying to accommodate their non-standard encodings.

Bhikkhu Pesala

John Hudson said:

I would be trying to encourage such scholars to work with character substitution macros, so they can type text using this kind of simplified input, and then have it converted to standard Unicode for the diacritics.

I even made my own Windows keyboard to help such users. I am actually more concerned about the users who want to be able to disable this feature/bug than Buddhist scholars who are more likely to be computer-savvy and know how to use Unicode fonts.

I could simply remove it, of course, but then one has to run macros (limited by app) to convert Velthuis encoded text to Unicode and vice versa for those using apps that don't support Unicode. 

Thomas Phinney

If you see this as a specialist feature, then keep it well the heck away from 'calt' and any other features that are supposed to be on by default in OpenType savvy apps. (I am not saying all apps that support OT features have 'calt' on by default, just that they are nominally supposed to.)

I like 'dlig', but if you are using that for other things in the same font, it might be a bad choice.

Bhikkhu Pesala

Yes. I thought there might be a better choice than calt, but it seemed like the best choice at the time before I realised that some apps cannot turn it off. I only had PagePlus for testing until I tested Affinity Designer Beta, That's why I started the thread, to find out if there was another feature that I could use. Historical ligatures might do it, or it might be best to just remove the calt feature in future versions. 

Nick Shinn

Perhaps two versions of the font? That would be like having a separate “Expert” font for small caps rather than including them as a feature.

Bhikkhu Pesala

I already include a Web version in my font archives, so anyone could use that. No Petite Capitals, no Alternative Fractions, no Contextual Ligatures, and only a few symbols and dingbats. That's one of the workarounds I suggested to the person who reported the bug. 

Bhikkhu Pesala

I found a feature called Contextual Swash, (cswh), which is not enabled by default. That should be less disruptive to those who don't know about OpenType features. Those who do, can enable it in OpenType aware applications. 

Peter Constable

These aren't swashes.

It's not clear to me that "contextual" is really relevant either: you're not substituting (say) the default "m" with a different glyph when it's preceded or followed by certain glyph sequences; you're substituting ".m" in all contexts by a different glyph. These are ligature substitutions, but they're not ligatures in the most familiar sense. 

What about ss01?

Bhikkhu Pesala

Stylistic Set (ss01) also works well, and is a more logical choice. I tested it in LibreOffice and PagePlus, and both recognise it, so I shall go with that. 

It has the additional benefit of showing on the Context Toolbar OpenType features drop down in PagePlus, so it can be enabled/disabled very easily. 

Thank you for the suggestion. 

Bhikkhu Pesala

I have now updated my Garava font with the helpful suggestions made in this thread, and my other thread on kerning. No doubt there are still some things to improve, but I think it is better than before.