Glyph Issue

Hey,

I am a university student working on a devanagari typeface. I have been using font lab to create my letter forms. However I am facing a problem with just one glyph one the typeface is generated and is being in use.

The glyph moves out of place when clicked on. e.g. instead of abc it would be acb. And i dont know how to get rid of the issue.

I have attached a screen shot of what is going wrong. could someone please help me

Regards

Noha

AttachmentSize
Screen Shot 2012-12-04 at 12.50.06 PM.png204.56 KB
noha2312's picture

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

kentlew's picture

That looks like proper glyph-handling behavior for the short i in Devanagari, assuming what you’ve attempted to write in your screenshot is pāpīki. You’ll want to adjust your right sidebearing (and/or kerning) accordingly.

John Hudson's picture

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.

kentlew's picture

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? Not having attempted a Devanagari design (yet), I had always assumed that there would need to be language-specific OT features written to handle vowel positioning, etc. Has this burden been shifted to the layout engine? And if so, I assume it is responding purely to the Unicode codepoints in the text flow? Cool.

John Hudson's picture

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).

John Hudson's picture

PS. If you want a detailed example of Devanagari layout, take a look at the one I prepared as part of this essay for Microsoft some years ago. It also appears in my contribution to the Language Culture Type book.

http://www.microsoft.com/typography/Glyph%20Processing/overview.mspx

kentlew's picture

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 ;-).

John Hudson's picture

Your character input is correct, i.e. phonetic.

With regard to lookup input, the ikar variant width substitution is a contextual 'pres' feature substitution, which would normally be applied after 'pres' conjunct formation, which would in turn be applied after 'half' form substitution. So there would be a sequence of three lookups affecting this syllable. In VOLT syntax and using my naming conventions, these would be as follows:

1. d.half
dSa dHalant -> dS.half

2. d.pres.conjuncts
dS.half dTa -> dSTa

3. d.pres.ikarwide
dSignI -> dSignI.wide
| dSTa

Obviously in the last of these the context string is more likely to be a class of glyphs of similar width.

In the Adobe Devanagari fonts, we used a lot of ikar variants to get quite precise relationships between the tip of the ikar and the main stem of the following letter, as one finds in manuscripts. In some more recent designs, we've limited the number of variants, since some readers found the very long ikars in Adobe Devanagari distracting on the page.

kentlew's picture

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?

John Hudson's picture

It is possible to create Indic fonts with AFDKO 2.0+, I believe. What was missing previously was support for GPOS anchor attachments. My understanding is that the more recent AFDKO supports all the lookup types necessary.

I've been using VOLT for so long, though, and have so many FL-to-VOLT workflow tricks and scripts, that I don't see switching any time soon. Also, my most regular client requires VOLT sources as a deliverable.

The MS Indic font development specs are very helpful, and worth studying.

noha2312's picture

Hi guys!

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

Syndicate content Syndicate content