PDFMaker mixing up a font's GID and CID, causing garbled output
I would like to report an issue on Adobe Acrobat DC. I don't own any Adobe Acrobat DC application license (my apology), so I am unable to verify it myself. The issue is reported from a user of an open source typeface I authored, and from my investigation I believe this is related to the Adobe Acrobat application, or specifically, the PDFMaker. So I would like to bring this to your attention.
The typeface I work with is called Chiron Hei HK (https://github.com/chiron-fonts/chiron-hei-hk). It is derived from Source Han Sans, an open source typeface from your company. The font is built using "Adobe Font Development Kit for OpenType" (AFDKO, https://github.com/adobe-type-tools/afdko/), the same one Source Han Sans was built with.
Recently, I received an issue report about gibberish PDF characters caused by Adobe Acrobat DC when the user exported an MS Word document typesetted in my typeface to a PDF file (https://github.com/chiron-fonts/chiron-hei-hk/issues/7) on Windows. After some back and forth about the details, the user clarified that the PDF file is fine it is created using the "Print" function with the "Adobe PDF" device selected (i.e. using the Adobe PDF printer), but is problematic when using the "Export to PDF" feature in MS Word, which I believe is provided by Adobe's PDFMaker.
The actual problem is that some of the characters of the resultant PDF look garbled or weird. From the attached screenshot you can see that the text
"測試Testing " (note that there is a space at the end)
in MS Word becomes
"測試疮疹****磹疓" (* denotes a to-fu)
in the PDF.
I believe this is related to the CID-keyed nature of the font. Like Source Han Sans, my font is a OpenType/CFF CID-keyed font. But unlike Source Han Sans, the CID of my font is not contiguous. As stated by your former Type Architect, this should not be a problem ("One particular attribute of CIDs is that they need not be contiguous", quote https://ccjktype.fonts.adobe.com/2012/04/cid-vs-gid.html). But if an application assumes so, this can cause a problem.
Now, here is an excerpt of the Glyph ID and CID dump of my font using AFDKO's tx tool:
### Format: glyph[GID] {CID,iFD,LanguageGroup}
glyph[20448] {27219,0,0} # CJK Character "疓" (U+7593)
glyph[20475] {27262,0,0} # CJK Character "疮" (U+75AE)
glyph[21320] {28708,0,0} # CJK Character "磹" (U+78F9)
glyph[27219] {40003,3,0} # The "space" glyph (U+0020)
glyph[27262] {40046,3,0} # LGC Letter "T" (U+0054)
glyph[28708] {41492,3,0} # LGC Letter "g" (U+0067)
Comparing the above data with the text "測試Testing " with the one on PDF "測試疮疹****磹疓", I discovered the following:
The letter "T" is correctly shown in MS Word. In PDF it becomes a "疮". From the above lookup table, the CID of "疮" is 27262, which is different from that of "T" which is 40046, but is exactly the same as the GID of the letter "T".
Similarly, "g" is of GID 28708, but the PDF file embeds a glyph with CID 28708, so it becomes "磹". " " (the space) is of GID 27219, but the application embeds CID 27219 (疓) to the PDF file.
So, from the the above observation, I think it is pretty safe to assume that there is a problem with Adobe Acrobat DC, or probably the PDFMaker application, which involves confusing the GID and CID of a font. I would appreciate if you could look into this.
Finally, while I am unable to verify the issue with Adobe Acrobat DC, I have verified that this issue doesn't occur in other non-Adobe exporting tools, including the "save as PDF" function in Chrome and Firefox, the "export to PDF" function in Libre Writer, and the "print to PDF" function is certain freeware PDF utility, like PrimoPDF.
Thank you for your attention!