Typophile

InDesign CS5, Adobe World-Ready composer, a & hamza (ʾ) problem

Ad Astm0 votes

Hello,
I wonder if anybody has come across this problem and could help me to understand it further. I noticed that when the hamza diacritic (U+02BE) follows 'a' and the two are italicised, the hamza either gets thrown off or disappears. This occurs for a number of fonts when using the Adobe World-Ready composer in InDesign CS6, Windows 10.
The problem occurs for a number of fonts, including system fonts like Calibri (Microsoft), Arial (Monotype_, and Times New Roman (Monotype).
It doesn't make a difference whether using either the paragraph or single-word version of the World-ready composer.
The following image should make it clearer. I have also attached a PDF so you can copy and paste the words to see for yourself. As you can see the problem does not occur for the ayn diacritic (U+02BF). I have not managed to find any other problematic combinations so far.
Interestingly, the problem doesn't occur on a couple of modified fonts I tested...so perhaps the issue is down to kerning tables being copied from font to font and Adobe world-ready composer not interacting very well with them?

PDF icon Hamza issue.pdf
Theunis de Jong0 votes

InDesign has some not well-described behavior with respect to nonspacing accents: if you insert a base glyph and an accent and the font contains a combined glyph for these, ID will use that glyph instead of the two separate ones. You can see that if you type "Tẚrīkh" with a single "ẚ" character [U+1E9A] and with separate glyphs for the \a and Hamza. To see what happens, also open the Glyphs panel.
In the first word, you cannot move the cursor 'between' the two characters; in the second, you can, but if you select the \a you will see that the character is not selected in the Glyphs panel (usually, a single selected character gets highlighted in this panel). If you select just the Hamza, the Glyphs panel will report you selected the combined character!

Looking at your samples, I'd guess that Libertine does not contain a combined 'ẚ' character, and so you get the separate nonspacing Hamza glyph over the \a – badly positioned, because the Hamza glyph's position is – necessarily – "generic"; it does not 'know' over what character it gets positioned.[1]

I cannot replicate the problem with italicized text, though. What exact version number of Calibri are you using? If this differs from mine (6.18, default for Windows 10), it might be an additional problem in the OpenType encoding. Also, check if the characters \a, Hamza, and U+1E9A (their combo) are available in both your regular and italic Calibri.

[1] Okay, I just downloaded Libertine O and checked. The off-center Hamza in the combined character is as-is, in the Regular font. But the Italic font contains an unwelcome surprise: the combined character 'ẚ' U+1E9A is missing its Hamza ! So that, at least, is not on InDesign to blaim.

Ad Astm0 votes

Hello Theunis de Jong. Thank you for your help. I am using the default Calibri 6.18 in Windows 10 also.

So, the problem is that Adobe world-ready composer is automatically switching the "a" + "U+02BE" combination to "U+1E9A". You are right, this does not occur if a typeface is being used which does not have "U+1E9A" e.g. Lucida Sans Unicode.

As you know, when we type "f" + "i" we get the "FB01" ligature (provided the ligature is available in the font and the feature is turned on) so I thought the problem may be fixed by turning off ligatures but this did not fix it.

I see that in Libux Libertine, U+1E9A is in fact just the base character "a" without the accent so it makes sense that when "a" + "U+02BE" is turned to "U+1E9A" the diacritic disappears.

Ad Astm0 votes

I just noticed that I wroite 'CS5' in the title. I was actually using CS6 as mentioned in the post. Not sure if that makes a difference though.

Captured from web.archive.org on 9 Jun 2017. view this capture