Source Han Sans is corrupting other font glyphs in InDesign 5.5 ME

[JimmyLeonardson]

We have encountered a problem in Indesign 5.5 when using Source Han Sans JP (OTF Subset JP) in an artwork that prints descriptive text in several languages with different fonts for languages in the same text box.

The Japanese glyphs are shown correctly but other glyphs that are using different fonts on the same row are not rendered properly. They become tofu blocks.

https://www.dropbox.com/s/gdglxtvus5vflc6/Japanese_1.png?dl=0 https://www.dropbox.com/s/g14p1i1kcvwmojh/Japanese_2.png?dl=0

We are only using Source Han sans for Japanese, not for other languages. Noto Sans has the same problem. We have also tried to export an IDML document from Indesign CC and then open up in Indesign 5.5 but still the same problem. We are using other asian fonts with Indesign 5.5 without problem. It breaks only when using Source Han Sans.

This issue is fixed in Indesign CC, but we can't use CC in the Chinese market as per legal requirements so the only alternative we have is to find a workaround in Indesign 5.5.

Do you have any knowledge as to why this happens and any suggestions how we can move forward?

edit: We have to use Indesign 5.5 ME (Middle eastern) version because that's the one that our Chinese suppliers can use.

[hfhchan]

(As a last resort, you may consider converting the Japanese part to outlines and manually positioning it.

[kenlunde]

@hfhchan: InDesign doesn't have that capability.

Questions for @JimmyLeonardson: 1) How are you selecting the font for particular text strings? If you're not creating and applying character styles, then you're not doing it correctly. 2) Have you tried to use the language-specific OTFs? I cannot recall what the specific problem is in InDesign CS5.5, but if it's an assumption that CIDs equal GIDs for Adobe-Identity-0 ROS fonts, that would affect only the region-specific subset OTFs.

[JimmyLeonardson]

@kenlunde Thanks for the quick reply. Great suggestions!!

1) As I suspected, there are no character styles applied. Will try to do this and see if it works. 2) No, we will try to use the language specific OTFs.

I'll get back to you soon!

[kenlunde]

The fact that you're using the ME is another good data point, because the default composer may be the reason for this behavior. In addition to using character styles, you should be using paragraph styles as well. Be sure to apply the most appropriate composer for the primary text of the paragraph. If the Japanese composer is not available to select, you might be able to enable it via the Preferences. CS5.5 is several versions old, and I cannot remember the specifics for enabling the Japanese composer in the ME version of InDesign.

[JimmyLeonardson]

@kenlunde Thanks! I'll look into this too.

Adobe CC has a "World ready paragraph composer", this should be the most appropriate composer for a multi-language text block?

[kenlunde]

I thought that you aren't able to use InDesign CC.

Anyway, the World Ready composer is meant for complex scripts that require shaping, such as Arabic. I believe that it may be the default composer for the ME version of InDesign. The main thing that the Japanese composer gives you is appropriate line breaking and inter-glyph spacing for Japanese and other East Asian languages, though the defaults favor Japanese rules and conventions. In a pinch, the World Ready composer could be used, as long as the primary language of the paragraph is not Japanese or other East Asian language.

[JimmyLeonardson]

@kenlunde I have co-workers who can only use Indesign 5.5 ME that I'm helping. I'm currently getting to install it myself to troubleshoot.

I see. In this case the primary language is latin. But for other cases we'll have to use Japanese composer, ok got it!

[JimmyLeonardson]

@kenlunde The language-specific OTFs worked!

Using character, paragraph styles and setting composer still didn't fix the problem on the subsetted versions. I don't know why that is.

[kenlunde]

@JimmyLeonardson: Excellent. It sounds like the issue was my initial guess, specifically an assumption, which was subsequently removed, that GIDs equal CIDs in CID-keyed fonts that use the Adobe-Identity-0 ROS.

(Just between you and me, I find the region-specific subset OTFs very uninteresting, mainly because they are not Pan-CJK fonts. The whole point of Source Han Sans, and the Google-branded Noto Sans CJK, is to provide a high-quality Pan-CJK typeface design to the community.)

[JimmyLeonardson]

@kenlunde I'm very impressed that you could help me pinpoint the issue and come up with solutions within such short notice.

And the work you're doing for the community is priceless! Thank you!

[kenlunde]

My pleasure. I am always glad to help out when I can. 🍻

[JimmyLeonardson]

@kenlunde Hi Ken, just a quick question for you, do you think this issue will appear in Indesign CS6 as well? In that case we could check if our Chinese providers could upgrade to CS6.

Thanks!

[kenlunde]

@JimmyLeonardson I am afraid that CS6 would still have this issue. It seems to have been fixed in late 2014, which means that the fix likely showed up in the CC 2015 release, which would be equivalent to CS9 (CC = CS7, CC 2014 = CS8).

[JimmyLeonardson]

@kenlunde I see. We reproduced the issue in CS4 ME too. So this is not just an issue with the ME version.

Then I think we have enough reliable information where this issue happens and how to work around it. Thanks for clarifying!

[JimmyLeonardson]

@kenlunde This is interesting. I tried to replicate the issue on Indesign CS6 Version 8 (not ME) and the subset font worked there. I'm leaning toward that this is only an issue with the ME versions handling of CJK since both 5.5ME and 4ME had the same issue.

[kenlunde]

@JimmyLeonardson: I am somewhat handicapped by not knowing anyone who uses the ME version of InDesign for handling CJK text. You may be breaking some new ground here, in terms of testing. Unfortunately, what matters most to InDesign development is how the latest version behaves. With the exception of Acrobat, previous versions of our apps are not fixed if a subsequent version fixes the issue.

[JimmyLeonardson]

@kenlunde Thought that these findings might be of value to you. We seem to have bypassed the CIDs equals GIDs issue by converting the font to TTF (Truetype) and using straight Unicode for character access. The open type tables were left the same as the OTF version. Do you see any problems with us using the TTF format (for the subset versions)?

[kenlunde]

@JimmyLeonardson: I see no particular problem with using user-converted TTF versions of the fonts, which preserve the GIDs but effectively remove CIDs from the equation. However, please be advised that we have no plans to add TTF versions to the project.

[JimmyLeonardson]

@kenlunde Good! We understand, it is something we could maintain by ourselves if we choose that direction.

Thanks again!