Troubleshooting Inconsistent OpenType Features in InDesign

[A2D2]

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>

[Abhishek Rao]

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]

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.

[Mike Witherell]

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

[A2D2]

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

[Dirk Becker]

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]

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]

When Dirk asks you if it's a "document font" he's talking about a font file stored in a folder called Document Fonts, in the same folder as the InDesign INDD file. Having two fonts with the same name, with one installed in your Fonts folder on your computer and another in a Document Fonts folder, can cause a variety of problems. 

If that's not the case, then if you were to post an InDesign INDD file with a snippet of poorly behaving text, it might take us fewer posts to figure out exactly what is going on. I have a few suspicions, though. I can see that you're using CS6 with an InTools plugin... is it WorldTools? I've not used WorldTools in a very long time, so I can't recall whether or not it has an "OpenType Diacritic Positioning" preference. If you were using Creative Cloud, you could install a version of InDesign that has a complete set of RTL tools, and then you could find the preference in your Paragraph Style right here:

I also don't know for certain why Adobe Naskh has this issue but other fonts do not; I could go install that font and test it over here, but I couldn't install World Tools to really duplicate your working environment. But if you posted that left-hand INDD from your screen capture video, I'm sure that we could figure out which setting it was that it was causing the issue... unless it was World Tools itself that was causing the issue. 

Lastly, I don't know how much detail you really want to go into, here, but there are plenty of cases where the Adobe Paragraph Composer and the World-Ready Composer behave very differently, depending on how the font was put together. I don't expect advanced typographical features from fonts distributed with Linux (like Libertinus Sans?) to necessarily render properly outside of the environments where they were tested. Perhaps there are language-dependent OpenType features that aren't being employed correctly? I can' t help but notice that your Arabic text is marked as "English: UK." Maybe OT features that work just fine in e.g. LaTeX won't work in InDesign? I've certainly seen that play out, in the opposite direction. 

If none of the above speculation helps you figure this one out, I really do think that just posting that file will get you the fastest answer. Or we can continue taking shots-in-the-dark; surely one of us will hit eventually. 

[Dirk Becker]

Thanks for the clarification on the Document Fonts folder. Problems don't only arise with colliding copies of the presumedly same font, but also when font families use mixed types across multiple styles/fonts. InDesign would not use the font family + style combination to spill over into a family with the same name but different type, even if that supports the style. The described issue does not sound like that, though.

As Joel also mentioned, another thing to watch out is writing script and language. I've only come across this with few fonts - Arial Hebrew ten years ago which enabled slashed zero only for Hebrew, but such a restriction can be present in other fonts, there are only complicated ways to tell so we will usually miss that.

http://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html#4.b.ii

Use the applied language to control this from the InDesign document.

I think some composer may also implicitly activate more OT features under the hood dependent on the language (not sure, was it 'mkmk' ?) that could explain those "differences in diacritics". Haven't looked at this in years, and it takes hours if you have such a document.

Then we might have a look at the document history, e.g. the extended about dialog that you reach with multiple/all modifier keys down then choose the "About InDesign" menu action. It should list the original version used to create the document, if that is far in the past the basic paragraph styles may differ.

[A2D2]

Thank you for clarifying about the document fonts ... yes, I come across this when packaging an InDesign document.

Point taken about posting the file, I shall have to follow up with this although your speculations are certainly useful in terms of background info.

Yes, I am eschewing perpetual licensing by keeping CS6 alive by using the World Tools extension...although if I cannot get Adobe Naskh to behave then maybe my time is up! And yes, I can access the diacritic positioning preferences in the paragraph and character style settings (as you can see from 1:15 in my screen recording). Removing the OpenType positioning makes the situation even worse.

[A2D2]

Just writing quickly before preparing a document or a screen capture to share, I think I have managed to zoom in on the issue.

The problem with the diacritic positioning seems to REQUIRE the following conditions:

1. Adobe Naskh is used with ligatures
2. OpenType positioning is used for the diacritics
3. The line contains a footnote reference with more than 1 digit.

If these 3 conditions are fulfilled THEN a diacritic will be mispositioned somewhere on the line (even if the line only has one word) although there appears to be no pattern which diacritic will b e mispositioned or where.

Sound weird? I'll look forward to sending proof!

[A2D2]

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

[Joel Cherney · Accepted solution]

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. 

[A2D2]

Thank you for your support and your congratulations are quite a special compliment for me 🙂

On the In-Tools website there is a section where the functionality of the World Tools plug-in is compared to the full ME version, it says "The World Ready Composer in CS4 is pretty good. The one in CS5 is even better. But there might be bugs in the composer which the ME version addresses...." 

Sounds like CC has addressed some issues in the composer. But in 2017 @Joel Cherney you replied to a post about another issue I found in the composer (see here) and you found that a glyph combining issue could be recreated in CC 2017), I wonder if this is still the case in the latest verion of CC?

So, I have been under the impression that increased cloud and AI functionality in InDesign is not anything useful for me in designing long documents. But now I see ID finally started supporting endnotes in 2018 ... so perhaps I am only just 6 years behind the curve! Still, with 1 series of footnotes and 1 series of endnotes, this is just placing ID in par with a wordprocessor like MS Word (in this specific feature). How about multiple series of each? Or marginal notes? I digress!

Anyway, if anybody has any unused versions of CS6 language plugins (i.e. ScribeDOOR) I would be happy to see if I can recreate the same problem without WinTools 🙂 Other than that, looks like you are right, I may have to use CC after all these years.

Thank you again!

[A2D2]

Just to draw a close on this academic issue, I did test on a different system using CS6 and ScribeDOOR and I got the same issue. So, the issue appears to have been with the World-Ready Composer rather than the plugin and, as @Joel Cherney  says, "was resolved sometime between CS6 (8.0) and today (19.5)"