However I am facing a problem with just one glyph ,when the typeface is generated and is being in use. **

This is reordering applied by the Devanagari layout engine. The short i character is automatically reordered to the left side of the letter or conjunct to which it applies. This happens in a buffered state of the character string, and is independent of the font.

Kent: So, John, am I to understand that this happens at the level of the text processing engine and does not rely on any specific OT feature being written into the font?

Correct.

The layout engine is responsible for any standard reordering, such as the short i in Devanagari, Bengali and other northern scripts, and for splitting two-part vowels in southern scripts. The font is responsible for what happens with these glyphs after re-ordering. What this means is that the font GSUB and GPOS lookups need to presume reordering. So, for example, if you want to vary the width of the short i vowel sign dependent on the width of the letter or conjunct to which it applies, you make variant substutions based on the following (right side) context, even though the phonetic character input has the vowel after the letter/consonant. Between the character input and the glyph substitution, the Indic layout engine is performing reordering.

The reordering is based on standard Unicode rules, so when the layout engine sees the character code for the short i in the text, it knows that the glyph associated with that code in the font cmap table needs to be reordered.

I had always assumed that there would need to be language-specific OT features written to handle vowel positioning, etc.

It is a good idea to make a usage distinction between '(re)ordering' and 'positioning'. Positioning would be an instance of GPOS, typically an anchor attachment positioning of a combining mark, so would apply to e.g. the u vowel sign. Ordering is a buffered character level operation (buffered in this case meaning that the underlying Unicode character string is not affected, only the display).

What this means is that the font GSUB and GPOS lookups need to presume reordering. So, for example, if you want to vary the width of the short i vowel sign dependent on the width of the letter or conjunct to which it applies, you make variant substutions based on the following (right side) context, even though the phonetic character input has the vowel after the letter/consonant.

John — Let me make sure I’ve got this. If I wanted a longer-reaching i for a conjunct syllable like sti (स्ति) for example:

The input would be something like 0938 (sa) 094D (virama) 0924 (ta) 093F (i)

But I would want my contextual sub to be something like sub i' sa.half ta by i.longer (assuming, of course, that I’ve already provided a many-to-one substitution to implement the sa half form).

Is that about right?

It is a good idea to make a usage distinction between '(re)ordering' and 'positioning'.

Ah yes, thanks for that. And thanks for the link. I’ll take a closer look when I get a moment. Also, I’ll dig out my copy of LCT.

Although, since I don’t have such a project in hand and it’s more of an idle curiosity I’ll probably let it go for now. But rest assured, if I ever undertake a Devanagari font, I’ll be in touch (offline ;-).

Hmm. Sounds like if/when I ever get around to something this, I’ll have to bone up on a host of Indic-relevant OTL features, instead of thinking in a {liga}/{calt} paradigm. ;-)

Is VOLT still basically the only tool for writing these features?

Hi guys!

sorry for the extremely late reply thank you for the help =)