World-Ready Composer, Non-spacing accent, Auto switch to combined character

[A2D2]

Hello,

I am experiencing a problem on two different computers with various fonts. Details of the scenario are as follows:

• Windows 10
• InDesign CS6
• using Adobe World-Ready composer (both single-line and paragraph)
• each computer uses a different complex script plugin

The problem is that when I type "a" and follow with "ʾ" (U+02BE; which is the hamza diacritic) there is an automatic switch to "ẚ" (U+1E9A; which is a combined character). The problem is I do not want the combined character but want the hamza to have its own width, as is normally the case.

I turned off ligatures but this had no effect.

The problem does not occur with the standard Adobe composers.

I have included a screenshot to show the desired (i.e. standard composer) and undesired (i.e. world-ready composer) behavior. Any help in dealing with this problem will be appreciated. I am not sure if this effects other characters. The desired presentation (e.g. lines 2 and 4 in the screenshot) is required in the transliteration of languages which use the Arabic script and is widely used in the academic fields of Middle East and Islamic studies, for example.

As a side note, the position of the diacritic on top of the base character is actually a mistake introduced in Unicode 3.0 and corrected in Unicode 5.1

Errata fixed in Unicode 5.1.0

It is a shame that the mistake has found its way into fonts and that the world-ready composer appears to force the mistake upon users.

[Zaid Al Hilali]

Very well explained issue. From the four numbered lines in your post it appears that your typing Latin words only, I wonder why would you need to use any of the two "World-ready composers"? World-ready composers are meant for Right-to-Left scripts.

ad-astm  wrote

each computer uses a different complex script plugin

What are these plug-ins, do you think they have any thing to do with your issue?

[A2D2]

Thank you.

Good point about the need for world-ready composer in Latin only texts. I tend to use the world-ready composer in my paragraph styles by default because I work with different scripts. In some paragraphs I may even combine scripts, for example (ًمثلا).

The plugins I am talking about was ScribeDOOR on one computer and a similar plugin by another company on the other. Because I got the same results on both computers I do not think the issue is to do with the plugins.

[Zaid Al Hilali]

Right, ScribeDoor was developed for users who don't have a Middle Eastern copy of let's say InDesign, so you type your Arabic text in ScribeDoor, copy text from there, then paste it into a non-Arabic supporting application.

I'm sure you know your workflow better, but if I were you, I wouldn't use the copy/paste method from ScribeDoor or any other utility if I have InDesign CS6 ME since I can type Arabic natively within InDesign. Any way this technique surely is not the culprit behind the accent issue you're facing.

By the way I tried to replicate the 02BE in Helvetica Neue or Adobe Garamond Pro, I'm using Glyphs panel in InDesign to locate it but can't see it there.

[A2D2]

No, that is not how ScribeDOOR works and I'm not sure it ever has. There is no copy or paste! I agree, that would be a tiring exercise.

U+02BE is not available in fonts with a limited range. Try Times New Roman, Arial, Calibri, Adobe Text, etc.

[Zaid Al Hilali]

I revisited Winsoft's website to refresh my memory about Scribedoor, interesting enough they incorporated few panels from their powerful Tasmeem plug-in within Scribedoor.

Does Scribedoor give you more features than the typical InDesign ME features then? I thought it is used for those who don't have ME copy of InDesign.

[A2D2]

Tasmeem is a programme which incorporates ScribeDOOR for the purposes of exploiting more features of Arabic typography e.g. kashida and alternatives.

I haven't used InDesign ME. I believe ScribeDOOR brings the same features but because it is a plugin rather than integrated it is for those who mainly use RTL scripts rather than just use them occasionally.

Anyway, any thoughts on my original problem will be appreciated. Have I discovered a bug? Will there be a patch?

[Joel Cherney]

. Have I discovered a bug? Will there be a patch?

Mmmmmaybe.

I tried recreating your issue over here (on a vanilla install of CC 2017 with no complex-script plugins), and I learned some things.

You're trying to use something that I only recognize from linguistics class: a "MODIFIER LETTER HALF RIGHT RING." Modifier letters are not supposed to be combining glyphs.  There is already a combining half right ring and a combining half left ring, for that purpose. So, I started inserting the aforementioned glyph in a variety of circumstances. Tell me, what fonts have you tried? I tried TNR and Arial first, and found that the half right ring modifier acted like a combining accent. Then I tried Lucida Sans Unicode, and the modifier letter did not combine. Then I tried it in Gentium, and... it combined. In Calibri, it did not combine. It's all over the map, to be honest, and I haven't tried cracking any of these fonts open to look.

So, I suspect that it is a mistake in your font. I also suspect it is a widespread error that lots of type designers make. Maybe they're relying on a compositional method that is not supported in InDesign, or maybe only some of them are? Hard to say.  What font are you using?

[Jongware]

Joel,

Part of the problem is ID's automatically selecting the combined glyph if available. Unless your Lucida Sans Unicode is newer than mine, it does not happen with that font because:

1. it does contain a glyph for 'a'. (Included here because I think it's best to cover all possible problems.)

2. it does contain a glyph for the Hamza (http://www.fileformat.info/info/unicode/char/02be/index.htm).

3. ... but it does NOT contain a glyph for these 2 combined (http://www.fileformat.info/info/unicode/char/1e9a/index.htm)

I don't think the OpenType coding is of any consequence here. My Lucida Sans UC doesn't contain ccmp or liga tables, and ID still auto-combines base and accent characters.

In my version of Calibri, on the other hand, it does work (v6.18 from Windows 10). Let's add yet another test: what does ID do with dead accents even if they are not in a font? It still locates the precomposed character! So it must be built-in behavior – OpenType features are, by design, unable to work with glyphs that are not present in the font.

("Magneto-Bold" is just a random OpenType font, not selected for any reason other than that it does not contain a separate accent glyph and it does contain a precomposed a-accent glyph. It also does not contain Any OpenType Table At All.)

[A2D2]

https://forums.adobe.com/people/%5BJongware%5D  wrote

Part of the problem is ID's automatically selecting the combined glyph if available. Unless your Lucida Sans Unicode is newer than mine, it does not happen with that font because:

Exactly!

The thing I am trying to figure out is why the InDesign world-ready composers automatically replace the two glyphs to the combined glyph if available. And more importantly, how this behaviour can be stopped.

The problem is compounded by the fact there is a mistake in the Unicode which has worked its way into the fonts. (See my link to the Unicode 5.1 errata in my original post above)

Presumably, there are other replacements happening of which I am unaware so this problem may be important for others also.

[A2D2]

Seeing as my problem has been replicated but nobody has any solutions what is the best way to bring this to the attention of Adobe developers given that the support pages refer to the forum?

[Steve Werner · Accepted solution]

Here is where to report features requests and bug reports:

Feature Requests/Bug Reports