Bug 695989

(In reply to Peng Wu from comment #0)

> I tried to update ghostscript conf files to use Adobe Source Han Sans fonts
> as Chinese fonts on Fedora 21, but failed.
> 
> Here are the updated ghostscript conf files:

Firstly, attach files here, do not put URLs. URLs have a habit of expiring before anyone can get round to investigating the problem.

Secondly, you need to test with the current version of Ghostscript, which is 9.16.

Finally, the use of TrueType (or OpenType which is an extension of TrueType) fonts is not defined for a PostScript interperter. The correct way to use TrueType fonts in PostScript is to convert them into Type 42 fonts and embed them in the PostScript program.

Ghostscript's ability to use TrueType fonts from disk is an extension.


> https://pwu.fedorapeople.org/ghostscript-chinese/
> and examples files for tests:
> https://pwu.fedorapeople.org/ghostscript-chinese/examples/
> Font URL:
> https://github.com/adobe-fonts/source-han-sans/raw/release/SubsetOTF/
> SourceHanSansCN.zip
> 
> Steps to Reproduce:
> 
> 1. copy *.zh_CN files to /usr/share/ghostscript/conf.d/;

This isn't a standard location for Ghostscript files, if you are using a packaged version of Ghostscript you will probably need to reproduce the problem on a vanilla version of GS built from the source we supply. We don't support versions which have been altered by packagers.

(In reply to Ken Sharp from comment #1)
... you will probably need to reproduce the
> problem on a vanilla version of GS built from the source we supply.

I am able to reproduce the problem with vanilla 0f3691890027236e3c7b34317426b913f62288dc (recent-ish HEAD) from git.

create empty directory, save https://pwu.fedorapeople.org/ghostscript-chinese/cidfmap.zh_CN to cidmap, do some editing and adjust for font file location, etc, then do 

ghostpdl-3384-g0f36918/gs -I. pwu.fedorapeople.org/ghostscript-chinese/examples/chinese-zh_CN.ps

This fails with 

Loading a TT font from /usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Normal.otf to emulate a CID font GBZenKai-Medium ... Done.
Error: /invalidfont in /findfont
Operand stack:
   GBZenKai-Medium-UniGB-UTF8-H

Whereas copying fedora currently shipped cidmap (almost identical except for using Zenhei) this way, and 0f3691890027236e3c7b34317426b913f62288dc (recent-ish HEAD) from git can work with it:

Loading a TT font from /usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc to emulate a CID font GBZenKai-Medium ... Done.

So this is testing with vanilla 0f3691890027236e3c7b34317426b913f62288dc (recent-ish HEAD) from git but using two versions of custom cidmaps, one font works and the other does not.

0f3691890027236e3c7b34317426b913f62288dc is only 8 commits behind current git HEAD, but unfortunately 3 commits behind Chris' recent  9b6129c546bd924fb588219bc2d352ff44a79dd5 to 'Update freetype to 2.5.5 and tweak our makefile for it', so I am not sure if the latest freetype 2.5.5 would help; though the older freetype 2.5.3's ftview can view the otf file itself.

(In reply to Hin-Tak Leung from comment #2)

> So this is testing with vanilla 0f3691890027236e3c7b34317426b913f62288dc
> (recent-ish HEAD) from git but using two versions of custom cidmaps, one
> font works and the other does not.

Since you've done the work, why not attach the (minimum) files required to reproduce the problem.

I also don't understand this:

Whereas copying fedora currently shipped cidmap (almost identical except for using Zenhei) this way, and 0f3691890027236e3c7b34317426b913f62288dc (recent-ish HEAD) from git can work with it:

Loading a TT font from /usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc to emulate a CID font GBZenKai-Medium ... Done.

You say you 'except for using Zenhei', yet the back channel says GBZenKai.

Perhaps this would be clearer if you were to supply the files.

It's because it's an OTF/CFF font, and not a OTF/TTF font.

CIDFonts can't be substituted with a CFF font, and I'm not exactly sure whether it's even feasible to do so.

*** This bug has been marked as a duplicate of bug 690110 ***

(In reply to Ken Sharp from comment #4)
...
> Since you've done the work, why not attach the (minimum) files required to
> reproduce the problem.
...

The font files are a bit big, but the two versions of the cidfmap's as well as the test file, are small enough to be included inline:

cidfmap v1:
-------------
/BousungEG-Light-GB	<< /FileType /TrueType /Path (/usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc) /SubfontId 0 /CSI [(GB1) 4] >> ;
/GBZenKai-Medium	<< /FileType /TrueType /Path (/usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc) /SubfontId 0 /CSI [(GB1) 4] >> ;
/MSungGBK-Light		/BousungEG-Light-GB ;
/Adobe-GB1		/BousungEG-Light-GB ;
-------------

cidfmap v2:
-------------
/BousungEG-Light-GB	<< /FileType /TrueType /Path (/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Normal.otf) /SubfontId 0 /CSI [(GB1) 4] >> ;
/GBZenKai-Medium	<< /FileType /TrueType /Path (/usr/share/fonts/adobe-source-han-sans-cn/SourceHanSansCN-Normal.otf) /SubfontId 0 /CSI [(GB1) 4] >> ;
/MSungGBK-Light		/BousungEG-Light-GB ;
/Adobe-GB1		/BousungEG-Light-GB ;
-------------

and the test file itself:
-------------
/GBZenKai-Medium-UniGB-UTF8-H findfont 30 scalefont setfont 0 100 moveto (版权所有) show
-------------


> You say you 'except for using Zenhei', yet the back channel says GBZenKai.
...
"GBZenKai" is referenced in the test file, and also in the cidfmap config.

I am okay with Chris' resolving it as a dup of OTF/CFF issue; the above serves as additional test cases, if things ever get inproved, I guess.

Thanks very much for the comments! :)

(In reply to Peng Wu from comment #7)
> Thanks very much for the comments! :)

This is something I plan to investigate, but it is non-trivial - Truetype tables and CFF (Postscript) font key/values are totally separate and quite different and getting this to work will involve munging them together in some, yet to be defined manner.

It can also be problematic that some OTF/CFF fonts actually contain a CFF CIDFont (rather than a CFF font), which may well cause problems, too.