Skip to main content
A2D2
Inspiring
April 17, 2017
Answered

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

  • April 17, 2017
  • 2 replies
  • 3817 views

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.

This topic has been closed for replies.
Correct answer Steve Werner

Here is where to report features requests and bug reports:

Feature Requests/Bug Reports

2 replies

A2D2
A2D2Author
Inspiring
May 2, 2017

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
Community Expert
Steve WernerCommunity ExpertCorrect answer
Community Expert
May 2, 2017

Here is where to report features requests and bug reports:

Feature Requests/Bug Reports

Zaid Al Hilali
Community Expert
Community Expert
April 17, 2017

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
A2D2Author
Inspiring
April 17, 2017

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.

Jongware
Community Expert
Community Expert
April 20, 2017

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


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