Bug 690006

Summary:	CID font emulation misses Japanese glyphs
Product:	Ghostscript	Reporter:	leonardo <leonardo>
Component:	Graphics Library	Assignee:	Ken Sharp <ken.sharp>
Status:	RESOLVED INVALID
Severity:	normal	CC:	htl10
Priority:	P3
Version:	master
Hardware:	PC
OS:	Windows NT
Customer:		Word Size:	---

Description leonardo 2008-08-10 11:27:18 UTC

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

Comment 1 leonardo 2008-08-10 11:31:19 UTC

batang.ttc is taken from \Windows\Fonts of Windows Vista. It is attached to 
Bug 689893.

Comment 2 leonardo 2008-08-10 11:47:47 UTC

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.

Comment 3 Hin-Tak Leung 2008-08-28 07:27:41 UTC

But batang.ttc is a *Korean* font - it probably doesn't have all the Japanese
glyphs?

Comment 4 Ken Sharp 2009-07-20 01:52:11 UTC

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.