Noto sans CJK Japanese, making PDF via pdf printer driver, 2 bit character text are deleted.

[vaioassure]

Noto sans CJK Japanese,
Adobe acrobat DC, PDF creator, cube pdf, Promo pdf and a few Japan local pdf softwares(Free and commercial).
Windows7 32bit, 64 bit

making PDF via pdf printer driver, almost only 2 bit character text are deleted (a few character is kept)
Using other font, no delete.

1. Printer setting -> postscript option-> output option -> change "EPS"
   We can print only Page 1.
2. Printer setting -> postscript option-> output option -> change "Archive"
   Lost header information.

Changing from Noto sans to Han sans font (adobe), we have no-trouble
Adobe acrobat PDF maker have no-trouble with Noto sans CJK japanese.

Probably, Noto sans CJK Japanese do NOT support postscript print with postscript PDF printer driver.
Or Noto sans CJK Japanese have a bug for postscript PDF driver..

[kenlunde]

Because Noto Sans CJK and Source Han Sans differ only in their names, the lack of localized menu names may be the reason for this issue. Functionally, the fonts of both typeface families are 100% the same. I will ask our QE to look into this.

[jungshik]

Thanks, @kenlunde

Could 'GOOG' (vendor id) be the cause (if the lack of localized menu names are not)?

[kenlunde]

At this point, if the Source Han Sans fonts work correctly in the same environments, the chance of the lack of localized menu names in the 'name' being the cause is about 99%. Let's wait to give our QE a chance to look into this.

[vaioassure]

Hi @kenlunde

Thank you for your comment.

Yes, the Source Han Sans fonts work correctly in the same environments.
Windows 7 32bit and 64 bit too.

Hans and Noto have same typeface.Hans font file size is apploximately 5M.
However, Noto sans cjk font file is apploximately 17M.
Obviously, it is differentt format between Noto and Han sans.

regards

[kenlunde]

If the Source Han Sans fonts you are using are approximately 5MB, then you're using the region-specific (for Japan) subset fonts, which include only 17,850 glyphs and whose filenames begin with SourceHanSansJP-. If you want to use the equivalent Source Han Sans fonts, you need the ones that include all 65,535 glyphs, and whose filenames lack the "JP" identifier: SourceHanSans-

[kenlunde]

In addition, because you're using Windows, be sure that the fonts that you are using have the .otf filename extension (the ones that have the .ttc filename extension should not be able to be installed on Windows, but I figured that I should make sure).

[vaioassure]

Hi @kenlunde

For example,
Noto is NotoSansCJKjp-Regular_3.otf
Hans is SourceHanSansJP-Normal_1.otf

Noto and Hans are same Version number 1.004;hotconv 1.0.82;makeotf.lib2.5.63406

regards

[kenlunde]

Version 1.004 is the latest version for both families.

While I am not sure where the _3 and _1 are coming from (probably Windows), NotoSansCJKjp-Regular.otf is the language-specific OTF for Japanese that includes 65,535 glyphs (the equivalent Source Han Sans font is SourceHanSans-Regular.otf), and SourceHanSansJP-Normal.otf is the region-specific subset OTF for Japan that includes only 17,850 glyphs (the equivalent Noto Sans CJK font is NotoSansJP-DemiLight.otf).

I suggest that you try SourceHanSans-Regular.otf and NotoSansJP-DemiLight.otf to determine whether the former fails and the latter succeeds. If so, then the issue is related to the number of glyphs. If not, then it is most likely due to the lack of localized menu names in the 'name' table of the Noto Sans CJK fonts as I previously postulated.

[kenlunde]

First, I am surprised that it took over a year to discover this issue. Thank you for reporting this.

The short answer is that this is simply a 32K bug and (theoretically) should be easy to fix. This bug is being reported to the Acrobat team.

The long answer is that, based on the PDFs that our QE made, if a line includes at least one glyph whose GID (not CID) is over 32K (GID+32768, give or take one), that line is not in the output file. In Noto Sans CJK / Source Han Sans, the ordering of default (encoded) glyphs is according to Unicode, meaning that the 32K GID threshold is somewhere in the Radical 128 (耳) block within the URO, meaning that any character beyond that, meaning about half of the Radical 128 block through Radical 214, all pre-composed hangul, and Plane 2 (Extensions B through E) characters, will cause this issue. Other non-default or unencoded glyphs, such as those for combining jamo, Japanese kanji variants, and vertical forms, will also trigger this, because their GIDs are above the 32K threshold.

All of the region-specific subsets are under 32K, in terms of their GID ranges, and should not exhibit this issue.

[vaioassure]

Hi @kenlunde　san

Thank you for giving a lot of comments.

I'm the one of many customers. I don't understand technical comment.
I would like to fix this bug. Personally, I use Han sans font instead Noto san CJK.
However, 3M Japan, a company that I have worked, adopt Noto san CJK as a domestic limited official font.

regards

[kenlunde]

If 3M Japan is happy with the functionality of Source Han Sans but prefers to use the Google-branded Noto Sans CJK, which is completely okay, the easy solution is for them to use the NotoSansJP-{Thin,Light,DemiLight,Regular,Medium, Bold,Black}.otf fonts instead of the NotoSansCJKjp-{Thin,Light,DemiLight,Regular,Medium, Bold,Black}.otf ones, at least until this Acrobat issue is fixed. The problem is not with the fonts, and this is not the first 32K GID threshold bug that was exposed by these fonts.

(And, if I were a betting man, I would wager that these fonts will expose similar bugs in other applications or environments.)

[vaioassure]

OK thanks.

[kenlunde]

I recommend that this issue remain open until an Acrobat fix has been issued.

[kenlunde]

BTW, Adobe's testing indicates that this issue affects only Windows.

[jungshik]

@kenlunde is getting to the bottom of this issue in Acrobat.

[dougfelt]

I'll assign this to Ken, as he'll probably know first when a release of Acrobat fixes this.

[kenlunde]

@dougfelt: Good idea.

[kenlunde]

@vaioassure: Does this particular issue persist? Also, does it occur in Windows 10?

[kenlunde]

As an update, this has been determined to be an issue in the Windows printer driver, and Microsoft is aware of it.

At least in terms of producing PDFs, when using the standard "Print as Adobe PDF" menu item, the Windows printer driver is used, thus triggering this behavior. However, if one installs a commercial version of Acrobat, which supports PDF authoring, the newly-exposed "Save as Adobe PDF" menu item, which uses the Acrobat PDFMaker 15 library, doesn't exhibit this issue.

[kenlunde]

Microsoft just released an update that fixes this issue, which is in the form of an update to Windows 10 Anniversary Update (OS Build 14393.726). Microsoft does not plan to deploy this fix in earlier versions of its OS.

[kenlunde]

The Windows 10 Anniversary Update update can be found here.

[davelab6]

Closing as fixed upstream - thanks again to @kenlunde for his dedication to fix this :)