cidfmap: /MS-Mincho << /FileType /TrueType /Path (C:/WINDOWS/fonts/msmincho.ttc) /SubfontID 1 /CSI [(Japan1) 3] >> ; PostScript file mincho.ps: /MS-Mincho-RKSJ-H findfont 25 scalefont setfont 50 600 moveto (—ì•M Ghostscript) show showpage The above works with gswin32c mincho.ps AFPL Ghostscript BETA RELEASE 8.31 (2004-08-28) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading a TT font from c:/windows/fonts/msmincho.ttc to emulate a CID font MS-Mi ncho ... Done. It fails to find the MS-Mincho font with gswin32c -Ic:\windows\fonts mincho.ps AFPL Ghostscript BETA RELEASE 8.31 (2004-08-28) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file c:\windows\Resource/Font/MS-Mincho-RKSJ-H. Can't find (or can't open) font file MS-Mincho-RKSJ-H. Querying operating system for font files... Didn't find this font on the system! Substituting font Courier for MS-Mincho-RKSJ-H. Loading NimbusMonL-Regu font from C:\Program Files\gs\fonts/n022003l.pfb... 2280584 919777 1476808 180027 1 done. Adding -Ic:\windows\fonts was an attempt to avoid putting full paths into cidfmap.
Created attachment 981 [details] Example using MS-Mincho font
The -I switch specifies where to find Postscript library files and Postscript fonts. The file msmincho.ttc is not a Postscript font. Moreover, CID font resources are not fonts. So the behavior you ovbserve is fully correct. I agree that moving the absolute path from cidfmap to a configuration option would be useful for some cases. We'll discuss it in a support meeting. For now I change the status of this request to "enhancement".
Note that the cidfmap file still contains the full path to msmincho.ttc. The bug report is about the fact that simply adding another directory to the search path prevents the CJK fonts from being found. Without the -Ic:\windows\fonts it does work. Just adding -Ic:\windows\fonts to the command line prevents it working. Since msmincho is not a PostScript font, I would expect that adding -Ic:\windows\fonts would have no effect whatsoever. So perhaps this should be two bugs: 1. -Ic:\windows\fonts stops CJK fonts from being found. 2. Allow CJK fonts to be found on a search path, instead of just the first Resource directory (or whatever is currently happening).
Right now I don't know about (1), but I do know about (2). The (2) is not possible, becauase to convert a TT font into a CID font one needs an additional information, which currently comes from cidfmap : FontName, SubfontID, CIDSystemInfo. I have no idea how to generate an useful FontName automatically. Russell's idea to put a hewristic into the GS installer looks attarctive, because it allows the user to understand what's happen and fix|edit on necessity.
Igor, with (2) I was still expecting to put the substitution in cidfmap, I just wanted to do it with /Path (msmincho.ttc) not /Path (C:/WINDOWS/fonts/msmincho.ttc)
1. Regarding the -I option : The command : gswin32c.exe -IF:/AFPL/gs-hd/lib;D:\WINDOWS\Fonts -dBATCH mincho.ps succeds. The command : gswin32c.exe -ID:\WINDOWS\Fonts;F:/AFPL/gs-hd/lib mincho.ps fails with : [beg quote] AFPL Ghostscript BETA RELEASE 8.32 (2004-10-26) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file D:\WINDOWS\Resource/Font/MS-Mincho-RKSJ-H. Can't find (or can't open) font file MS-Mincho-RKSJ-H. Querying operating system for font files... Didn't find this font on the system! Substituting font Courier for MS-Mincho-RKSJ-H. Can't find (or can't open) font file n022003l.pfb. Can't find (or can't open) font file D:\WINDOWS\Resource/Font/NimbusMonL-Regu. Can't find (or can't open) font file NimbusMonL-Regu. Can't find (or can't open) font file D:\WINDOWS\Resource/Font/NimbusMonL-Regu. Can't find (or can't open) font file NimbusMonL-Regu. Didn't find this font on the system! Unable to substitute for font. Error: /invalidfont in findfont [end quote] This is a correct behavior, because : A. by default the resource directory path is derived from the first element of the -I list; B. There no CMap resources in there. C. MS-Mincho-RKSJ-H cannot decompose into CIDFontName-CMapName due to no CMap names due to B. D. It substitutes Courier to MS-Mincho-RKSJ-H. E. When finding Courier, it fails due to no Type 1 fonts in the -I list. 2. regarding to relative paths in cidfmap : I'll open a separate bug (with severity=enhancement) about that, because this one appears too cumbersome.
If the current behaviour is to be retained, could you please document that resources are only found in a directory derived from the first element of -I (if provided), or GS_LIB (if provided) or the default search path (assuming that this is the situation). A suitable place is probably Use.htm#PS_resources. If resources are only found based on the first directory in -I, is there any point in using the following? -Id:\gs\gs8.32\lib;d:\gs\gs8.32\Resource Will the path d:\gs\gs8.32\Resource ever be used? If not, why does ghostscript bother to add c:\gs\gs8.32\Resource to the default search path? I think a better method is to look for the resources in the first directory on the search path ending in Resource, (this is what I expected it to do), or if that is not found derive a resource directory from the first item on the search path. I've reopened this bug. I'd like it to be closed when the resource finding behaviour is documented.
Patches to HEAD : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004967.html http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004968.html Patches to GS_8_1X : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004969.html http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004970.html It improves the documentation as requested. A minor fix to lib/gs_res.ps is not strongly related to the claimed problem. The claimed problem about -I option is still considered to be invalid, and I hope the improved documentation clarifies that.
One more patch committed to doc/Use.htm rev. 1.118 and rev. 1.81.2.13
More related patches : HEAD : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004974.html GS_8_1X : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004975.html