Skip to main content
A2D2
Inspiring
September 20, 2024
Answered

Troubleshooting Inconsistent OpenType Features in InDesign

  • September 20, 2024
  • 3 replies
  • 3551 views

Assuming that I am using a reputable typeface in InDesign (i.e. one packaged with the software or from a known foundry/developer) ... why would certain OpenType features not work?

 

For example, using Libertinus Sans, I find in one document the "OpenType All Small Caps" feature works and in another document it does not.

 

Similarly, with Adobe Naskh (an Arabic typeface) I find that sometime the diacritics and dots are poorly positioned but in another document with seemingly the same document, para and character settings I do not get the problem.

 

So, if I am finding certain OpenType features are not working for me...where should I look first?

 

If this question seems too broad then it is because I am finding it difficult to recreate the problem with specific settings or a specific font.

 

I am just asking where to continue looking in trouble shooting .... is it most likely a font problem or an InDesign problem or a mixture of the two? What could some of the most obvious causes be?

 

<Title renamed by MOD>

This topic has been closed for replies.
Correct answer Joel Cherney

I recreated the problem I have been talking about with Adobe Naskh in a fresh document. INDD and PDF attached.

 

The problem only occurs with certain ligatures and seems to require a full line (i.e. page 2 but NOT page 1).

 

I have highlighted in pink the instances in the document where the diacritics are thrown out.

 

Interestingly, the line on page 2 with note 12 does not have any problems.

 

I would be curious, and grateful, to hear whether anybody can recreate this problem in their own environments or even with other scripts and fonts!

 

(As an aside, a user reported a diacritic (dot / nikud ) positinging problem when using any Hebrew font in InDesign as part of a composite font; see here.)


Well, when I open up your INDD, and make any one change anywhere in the story (to force the story to recompose), all of the mark-positioning errors you've indicated with magenta immediately resolve themselves. This means that whatever bug you've found in the World-Ready Composer was resolved sometime between CS6 (8.0) and today (19.5).  This shouldn't be surprising; over the years, plenty of other complex-script layout problems in the World-Ready Composer have appeared, and (for the most part) have been resolved. 

 

If using Adobe Naskh is non-negotiable, then perhaps it's time to join the rest of us on CC. To be honest, I feel you ought to be congratulated for holding out as long as you have. 

3 replies

Legend
September 20, 2024

Are both documents using the same world-ready composer?

Are the fonts installed globally, or as Document Fonts which sometimes causes trouble?

Check in the Font Usage dialog aka "Find/Replace Font" >> More Info that both refer to the same font file.

A2D2
A2D2Author
Inspiring
September 23, 2024

I am not sure what the difference is between a globally installed font and a document font.

 

In the "Find/Replace Font" >> More Info dialogue, I see that some fonts have the path of the font displayed (e.g. "C:\Windows\Fonts\times.ttf") but other fonts do not give a path and it just says "System Font". Not sure what this means.

 

Actually, for the small caps issue I mentioned, I did find that the issue was because of the world-ready composer. So, with Libertinus Sans (v. 7.040) I found that the OpenType All Small Caps feature worked in World-Ready Composer but not with the normal paragraph and single-line composers (all apart from the letter "i"). I also tried with Minion Pro and Calibri but did not get this problematic behavior. So, admitting that this particular OpenType issue is a font issue then it begs the question as to why would a font for Western languages (Cyrillic, Latin, and Greek scripts) not work with the regular composers? What went wrong with the font design?

 

As for the other issue I mentioned, using Adobe Naskh for Arabic composition then I am still none the wiser. If I copy a problematic string of letters and paste with formatting into a clean document the problem dissappears. So I wonder why the font engine  is being "shaken" into behaving properly.

 

In the attached screen captue you can see the problematic document on the left and a new document on the right. I copy from left and paste with formatting into the new document. We can see that there are no style overrides at work. We can also see that the positioning of the "diacritics" is effected by the diacritic positioning options. Perhaps in this case the issue is due to with bugs in

 

Joel Cherney
Community Expert
Joel CherneyCommunity ExpertCorrect answer
Community Expert
September 25, 2024

I recreated the problem I have been talking about with Adobe Naskh in a fresh document. INDD and PDF attached.

 

The problem only occurs with certain ligatures and seems to require a full line (i.e. page 2 but NOT page 1).

 

I have highlighted in pink the instances in the document where the diacritics are thrown out.

 

Interestingly, the line on page 2 with note 12 does not have any problems.

 

I would be curious, and grateful, to hear whether anybody can recreate this problem in their own environments or even with other scripts and fonts!

 

(As an aside, a user reported a diacritic (dot / nikud ) positinging problem when using any Hebrew font in InDesign as part of a composite font; see here.)


Well, when I open up your INDD, and make any one change anywhere in the story (to force the story to recompose), all of the mark-positioning errors you've indicated with magenta immediately resolve themselves. This means that whatever bug you've found in the World-Ready Composer was resolved sometime between CS6 (8.0) and today (19.5).  This shouldn't be surprising; over the years, plenty of other complex-script layout problems in the World-Ready Composer have appeared, and (for the most part) have been resolved. 

 

If using Adobe Naskh is non-negotiable, then perhaps it's time to join the rest of us on CC. To be honest, I feel you ought to be congratulated for holding out as long as you have. 

Mike Witherell
Community Expert
Community Expert
September 20, 2024

Different OpenType fonts may have differing amounts of additional OpenType features designed into them.

Mike Witherell
A2D2
A2D2Author
Inspiring
September 23, 2024

Fair point, but I am talking about typefaces that definitely do have the OpenType features being accessed.

Abhishek Rao
Community Manager
Community Manager
September 20, 2024

Hello @A2D2,

 

Thank you for reaching out! I understand how frustrating it can be when OpenType features behave inconsistently.

To help troubleshoot, could you please share the exact version of InDesign you're using and the details of your operating system? Is this issue occurring in only one InDesign document, or are you noticing it across multiple documents? It would be really helpful if you could share a screen recording of your workflow showing the problem.

For immediate troubleshooting, I suggest checking if the text frame settings and character styles differ between documents, as these can sometimes affect OpenType features.

Additionally, please ensure that the fonts are fully activated and not corrupted.

For more details, you can refer to this article on troubleshooting font issues: [Troubleshoot font issues in Illustrator and InDesign](https://adobe.ly/3XNqPvw)

Let me know if this helps or if you need further assistance!

 

Thank you,  
Abhishek Rao

A2D2
A2D2Author
Inspiring
September 20, 2024

Thank you for the reply.

 

I am using Windows 11 (v. 23H2) and InDesign v.8.0

 

I will have to check further if the problems mentioned are document specific or not as sometimes I base one document on another or import styles.

 

I tried clearing the font cache but this did not help. The other items mentioned in the linked article did not seem relevant as I am not using a font managment plugin and ID is not crashing.