I run test case of the bug 688058 with this cidfmap : % /Ryumin-Light /WadaGo-Bold ; /Ryumin-Light << /FileType /TrueType /Path (F:/AFPL/MLC2/PROB0003- 688058/batang.ttc) /SubfontID 0 /CSI [(Japan1) 1] >> ; and it paints 2 hollow boxes near the end of thye text. When I uncomment the 1st line and comment the 2nd, it paints right glyphs. Command line : ..\..\gs-hd\bin\gswin32c.exe -IF:\AFPL\gs-hd\lib;f:\afpl\fonts -r72 -dBATCH - d/DEBUG -dEPSFitPage vert.gs8.51.ps
batang.ttc is taken from \Windows\Fonts of Windows Vista. It is attached to Bug 689893.
Note the patch 4267 attached to the bug to be applied before working on this bug, rather the problem persists without it. At this moment the patch is not committed due to gs/src reorganization.
But batang.ttc is a *Korean* font - it probably doesn't have all the Japanese glyphs?
The missing glyphs are not present in the TrueType font. The missing glyphs have the character codes 0x482f and 0x4764 in the PostScript file. These map (using the 'H' CMap) to CIDs 0xd43 and 0xd1a respectively. The Japan1.Unicode CIDDecoding then maps these CIDs to the Unicode code points U+767A and U+58F2. A quick comparison of the glyphs at these code points with the glyphs resulting from using the WadaGo or MSMincho TrueType fonts confirms these are the expected glyphs, so there does not appear to be any problem with the mapping. See http://www.decodeunicode.org/en/u+58F2 and http://www.decodeunicode.org/en/u+767A Checking the 3.1 Unicode CMap from Batang (the first font in the Batang TrueType collection), these Unicode code points are not defined. This results in the /.notdef glyph being substituted for the missing glyphs when we build the CIDMap, which is why we see the normal hollow boxes which are the usual TrueType notdef glyph. So I agree with Hin-Tak, the problem is simply that the glyphs are not present (or at least not defined in the 3.1 CMap) in the Batang font.