Let's run this snippet with xelatex:

\setCJKmainfont{Source Han Serif SC}  % SimSun is OK

The document body is a single Chinese character, 见 (U+89C1). Using the font Source Han Serif SC, the generated PDF contains another character ⻅ (U+2EC5). Using SimSun, the generated PDF contains the original 见 (U+89C1).

Could anyone tell me who is to blame: fontspec, xeCJK, or Source Han Serif SC; and how to stick to the original character in all cases? Thanks.

  • if you add \showoutput which character does it show in the log? Oct 12, 2018 at 8:19
  • Thanks for the tip. The log shows 见 (U+89C1).
    – wdscxsj
    Oct 12, 2018 at 8:36
  • so I think that means xetex and harfbuzz think that is the character added, so I think it points to something in the font (I don't have the font to test) If you remove xecjk and just use \setmainfont you should be able to compare with lualatex, what happens there... Oct 12, 2018 at 8:45
  • can you check with fontforge or similar if the Han Serif SC font has a 89C1 glyph? Oct 12, 2018 at 8:47
  • 1
    Can you post that as an answer and self-accept it, thanks. Glad you sorted it out. Oct 13, 2018 at 7:44

1 Answer 1


It turns out that SourceHanSansSC-Regular.otf does contain 见 (U+89C1) but in an unusual way. The glyph is cid37659 which has 2 codepoints, U+2EC5 and U+89C1. XeLaTeX somehow chooses the lower value. Adding \XeTeXgenerateactualtext=1 fixes the issue for PDF viewers that support the "actual text" feature (Adobe Reader does; SumatraPDF doesn't).

The same issue was reported in https://github.com/CTeX-org/ctex-kit/issues/286 (partly in Chinese) and http://tug.org/pipermail/xetex/2017-June/027142.html. It seems that a patch has been submitted but not yet universally adopted (my environment: MiKTeX 2.9 with the latest update on Windows 10).

Many thanks to David Carlisle for the gentle guidance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .