I'm filing this bug for ttfonts-ko, but it's equally applicable to ttfonts-ja,zh-CN and zh-TW. It may as well be regarded as belonging to ghostscript. They're dependent on each other but making them depend on each other is not a good idea, I think. Instead, what's to be done is to write 'post-install' script for ttfonts-xx (ghostscript) that checks whether ghostscript(ttfonts-xx) is installed and only installs what I'm going to describe below when ghostscript(ttfonts-xx) is installed. This way, there's no rpm dependency, but still what I'm gonna describe below is installed regardless of the order by which ttfonts-xx and ghostscript are installed. From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021008 Description of problem: Even though ttfonts-ja, ttfonts-ko, ttfonts-zh_TW and ttfonts-zh_CN are installed, they're not made available to ghostscript as CID-keyed fonts. Ghostscript 7.05 as shipped in RH 8.0 has everything necessary to deal with truetype fonts as type 2 CID keyed fonts. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Make a simple postscript file that refers to a truetype font as a CID-keyed font. For instance, the following PS file will do it. -------Cut----Here---------- %!PS-Adobe-3.0 /Baekmuk-Batang-UniKS-UTF8-H findfont 50 scalefont setfont 10 100 moveto <ED959CEAB880> show showpage %%EOF -----------Cut----------Here 2. Try to view it with 'gs' or 'gv' 3. Actual Results: Instead of Korean characters, Latin alphabets show up with the error message that gs can't find font 'Baekmuk-Batang-UniKS-UTF8-H' so that it's replaced by 'Courier'. Or, gs doesn't show anything with the error message '/undefinedresource in --findresource--' Expected Results: Two Korean characters should be printed with Baekmuk-Batang font. Additional info: It's very easy to fix because the end-result of gs-cjk project has been all incorporated into gs 7.05. As explained in /usr/share/ghostscript/7.05/lib/CIDFnmap, two things have to be done to make a TTF available as a CID-keyed font. One is to write a wrapper PS code and put it in /usr/share/ghostscript/Resource/CIDFont and the other is to list it in /usr/share/ghostscript/7.05/lib/CIDFnmap (or a file included by it.) The second step is already done (see /usr/share/ghostscript/7.05/lib/CIDFnmap.{Bae,Koc,ARP,ZHY). Therefore, only thing you have to do is to write wrappers for each of these TTFs and put them in where gs is looking for them ( /usr/share/ghostscript/Resource/CIDFont) I made 4 wrapper files for baekmuk batang/dotum/headline/gulim fonts one of which is shown below. (I used the identical name for Baekmuk Batang font below as used in CIDFnmap.Bae) -------Cut-----Here------------------- %!PS-Adobe-3.0 Resource-CIDFont %%BeginResource: CIDFont (BaekmukBatang-Regular) /BaekmukBatang-Regular (/usr/share/fonts/ko/TrueType/batang.ttf) .openttcidfont dup length dict begin {def} forall currentdict end /CIDFont defineresource pop %%EndResource %%EOF ----------Cut--------Here--------------------- These 'type 2 CID fonts' (TTFs wrapped as CID-keyed fonts) can be used by applications like Mozilla to print CJK documents by adding the following lines to Mozilla's unix.js file. ----------Cut--------Here----------------- # ps font mapping # # Japanese font print.postscript.nativefont.ja=Ryumin-Light-EUC-H print.postscript.nativecode.ja=euc-jp # # Korean font print.postscript.nativefont.ko=BaekmukBatang-Regular-KSC-EUC-H print.postscript.unicodefont.ko=BaekmukBatang-Regular-UniKS-UCS2-H print.postscript.nativecode.ko=euc-kr ..... and similar lines for zh-TW and zh-CN. -----------Cut--------Here---------------- Those without a postscript printer, PS will be filtered by ghostscript and there's any extra step to take. Those with a PS printer has to add a new printer which will filter postscript files with 'gs' (either using 'pswrite' device or one of PCL devices. the former is better).
I forgot to mention that the name of wrapper PS files have to be identical to the names of CID-keyed fonts. For example, the wrapper PS file shown in my bug report (and included again below) has to be named BaekmukBatang-Regular and be put in /usr/share/ghostscript/Resource directory. -------Cut-----Here------------------- %!PS-Adobe-3.0 Resource-CIDFont %%BeginResource: CIDFont (BaekmukBatang-Regular) /BaekmukBatang-Regular (/usr/share/fonts/ko/TrueType/batang.ttf) .openttcidfont dup length dict begin {def} forall currentdict end /CIDFont defineresource pop %%EndResource %%EOF ----------Cut--------Here---------------------
Related bug is bug 64269. BTW, I made a mistake in the PS program for testing included in my report. It should read as following: -------Cut----Here---------- %!PS-Adobe-3.0 /BaekmukBatang-Regular-UniKS-UTF8-H findfont 50 scalefont setfont 10 100 moveto <ED959CEAB880> show showpage %%EOF -----------Cut----------Here
Ooops. I should have tested this with GNU Ghostscript 7.05. ESP Ghostscript 7.05 automatically recognizes truetype fonts wrapped as CID-keyed fonts in various R-O, but GNU ghostscript does not. That is, for GNU gs 7.05, for each truetype font wrapped as CID-keyed fonts, (say, BaekmukBatang-Regular), there need to be BaekmukBatang-Regular-UniKS-UTF8-H, BaekmukBatang-Regular-KSC-EUC-H, and so forth in /usr/share/ghostscript/Resource/Font directory. These can be automatcailly generated with shell scripts(a[cjk][12].sh) in /usr/share/ghostscript/Resource directory. Running 'sh ak1.sh install BaekmukBatang-Regular' produces all wrapper scripts for BaekmukBatang-Regular. However, even with this done, GNU ghostscript 7.05 doesn't work with 'rangecheck' error message. I'm not sure what's wrong, but it seems like there's a bug with GNU ghostscript 7.05 in RH 8.0....
The easiest way to solve the problem I came across is to switch to ESP ghostscript 7.05 although there may be other ways around.
The problem I experienced (' Error: /rangecheck in --string--') when loading type 2 CID-font (TTF wrapped as a CID font) was reported at the following URL. http://sourceforge.net/tracker/?group_id=1897&atid=101897&func=detail&aid=611099 Apparently, it's fixed in September.
As gs-cjk people say, CIDFnmap is the better way than and will replace the resources under CIDFont directory. You can set alias with CIDFnmap.* files. This diff will show your sample of /BaekmukBatang-Regular-UniKS-UTF8-H correctly, for example. --- CIDFnmap.CJK.orig 2002-12-10 15:54:29.000000000 +0900 +++ CIDFnmap.CJK 2002-12-10 15:54:00.000000000 +0900 @@ -111,6 +111,7 @@ %/HYRGoThic-Medium /Baekmuk-Gulim ; % CIDFnmap.Bae %/HYRGoThic-Medium /RoundedGothic ; % CIDFnmap.Sol %/HYRGoThic-Medium /Gulim ; % CIDFnmap.Win +/Baekmuk-Batang-Regular /Baekmuk-Batang ; % CIDFnmap.Bae % % Convenient aliases for PS files on Traditional Chinese Acrobat Distiller
And our version of ghostscript can handles CJK postscript correctly, unless you are missing the font packages. so basically "/Baekmuk-Batang-UniKS-UTF8-H findfont" works. actually I can't reproduce your problem. perhaps we may have any problem, though. Second, if we have the *native* CID-keyed font, it may be better than the current way. but I think writing the wrapper PostScript is no benefit, because as I said, our ghostscript works for CJK without the CID-keyed font, and ghostscript still has the conversion cost from TrueType. it's a reason why ghostscript is slow for CJK printing.
Created attachment 89371 [details] ko-cid.ps - Korean correct postscript which our RHL8.0 gs fails to show I create an attached file to avoid the confusion.
I add the 4 aliases in CIDFnmap.Bae to satisfy the request in this bug report. --- CIDFnmap.Bae.orig 2003-01-15 16:58:24.000000000 +0900 +++ CIDFnmap.Bae 2003-01-15 17:02:55.000000000 +0900 @@ -29,3 +29,10 @@ /Baekmuk-Dotum (/usr/share/fonts/ko/TrueType/dotum.ttf) ; /Baekmuk-Gulim (/usr/share/fonts/ko/TrueType/gulim.ttf) ; /Baekmuk-Headline (/usr/share/fonts/ko/TrueType/hline.ttf) ; + +% Aliases + +/Baekmuk-Batang-Regular /Baekmuk-Batang ; +/Baekmuk-Dotum-Regular /Baekmuk-Dotum ; +/Baekmuk-Gulim-Regular /Baekmuk-Gulim ; +/Baekmuk-Headline-Regular /Baekmuk-Headline ;
Ghostscript issue filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81924
What does the applications uses -Regular? or is it described that -Regular or similar should be added after the font name? If we support -Regular suffix, we should support other style as well.
Thank you for looking at this and sorry for my late response. > As gs-cjk people say, CIDFnmap is the better way than and > will replace the resources under CIDFont directory. Somehow I missed this point and I filed this bug thinking (incorrectly) that the cause is missing PS wrapper files in Resource directory because I wasn't able to use baekmuk ttf (as CID keyed font with 'UTF8 encoding') in gs (the real cause was the bug of gs mentioned in http://sourceforge.net/tracker/?group_id=1897&atid=101897&func=detail&aid=611099 which is apparently fixed in a new gs package for RedHat) >but I think writing the wrapper PostScript is no benefit, Now that I know what went wrong, I fully agree with you. As for '-Regular' suffix, I was following the convention taken by Ken Lunde in CID keyed fonts published at ORE ftp site. It may be nice to have fonts with the suffix aliased to those without it (as is now done in bug 81924) although it's not required because as of now Baekmuk fonts come only in a single 'style' ('Regular'). Anyway, given all these, I think this bug can be closed. Thank you again.
Thank you for your report. Close the bug to RAWHIDE based on the completion of bug 81924.