Embedded font in PDF has wrong name

[starkshaw]

I generated some documents in XeLaTeX with the help of CTEX and xeCJK packages, under the latest version of macOS Sierra, and Super OTC version of Noto Serif CJK SC. Characters in documents looking correct, but in document properties of Adobe Acrobat Reader (Cmd+D), the embedded font appears as Noto Sans CJK JP.

I am not quite sure if that is a Super OTC issue, or Noto Serif CJK issue instead of Source Han Serif.

[kenlunde]

I think I know the reason, but first please let me know what specific Super OTC you are using, and which specific font (including weight) appears in the PDF document properties.

If you are using NotoCJK.ttc from the Source Han Super OTC repository, and if the font appears as NotoSansCJKjp-Thin, then the PDF creator is simply using the name.ID=6 (aka PostScript font name) of the first font that it encounters in the Super OTC. Another possibility, especially if the Thin weight in not the one that appears in the PDF document properties, is that it is using the PostScript name that is specified by the 'CFF ' table, which should be ignored when dealing with OTCs.

This smells like a PDF creator issue.

[starkshaw]

Hi Dr. Lunde @kenlunde Thanks for your reply. I used NotoSerifCJK.ttc from Google's Noto CJK page, md5: 1f42140f07b8eaa654d472793793245e, Version 1.000;PS 1;hotconv 16.6.53;makeotf.lib2.5.65590.

Here's the code import Noto CJK fonts in my XeLaTeX documents.

\setCJKmainfont[BoldFont=Noto Serif CJK SC Bold]{Noto Serif CJK SC Medium}
\setCJKsansfont[BoldFont=Noto Sans CJK SC Bold]{Noto Sans CJK SC Regular}

I used these 4 weights as shown above, the document properties in Adobe Acrobat Reader is correct about weight, but all in jp, as follow:

NotoSansCJKjp-Bold (Embedded Subset)
    Type: Type 1 (CID)
    Encoding: Identity-H

NotoSansCJKjp-Regular (Embedded Subset)
    Type: Type 1 (CID)
    Encoding: Identity-H

NotoSerifCJKjp-Bold (Embedded Subset)
    Type: Type 1 (CID)
    Encoding: Identity-H

NotoSerifCJKjp-Medium (Embedded Subset)
    Type: Type 1 (CID)
    Encoding: Identity-H

Interestingly, Noto Sans CJK appeared to have same issue here, considering both of them are Super OTC, this could be a reason. Also, from macOS's "Get Info", the full name of them are "Noto Sans CJK JP", and "Noto Serif CJK JP".

Like you said, if it was the issue with XeLaTeX PDF producer, what do you suggest to fix this issue? I may contact their developer team to fix this.

Thanks in advance.

[kenlunde]

Thank you for the additional details. The PDF producer is specifying the PostScript font name from the 'CFF ' table, not from the name.ID=6 string. For the Super OTCs, because the 'CFF ' tables are shared across all languages, one of them needs to serve as the default (the actual glyphs, in terms of what glyph is assigned to each GID, is 100% identical across all languages), and in the case of the Noto CJK fonts, it's the "jp" ones. InDesign, for example, uses the name.ID=6 string in the PDFs that it exports.

In any case, as long as the glyphs display as intended, this is somewhat of a non-issue. In any case, this is not a font issue, but rather a PDF producer issue.