Bug 78788 - CJK truetype fonts should be made available to ghostsscript wrapped as CID-keyed fonts
Summary: CJK truetype fonts should be made available to ghostsscript wrapped as CID-ke...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ttfonts-ko
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Joo
QA Contact: Bill Huang
Depends On: 66701
TreeView+ depends on / blocked
Reported: 2002-11-29 23:58 UTC by Jungshik Shin
Modified: 2007-04-18 16:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2003-01-31 04:00:15 UTC

Attachments (Terms of Use)
ko-cid.ps - Korean correct postscript which our RHL8.0 gs fails to show (131 bytes, text/plain)
2003-01-15 08:03 UTC, Nakai
no flags Details

Description Jungshik Shin 2002-11-29 23:58:13 UTC
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:

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.
/Baekmuk-Batang-UniKS-UTF8-H findfont 50 scalefont setfont
10 100 moveto
<ED959CEAB880> show
2. Try to view it with 'gs' or 'gv' 

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

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 (
 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)

%!PS-Adobe-3.0 Resource-CIDFont
%%BeginResource: CIDFont (BaekmukBatang-Regular)
(/usr/share/fonts/ko/TrueType/batang.ttf) .openttcidfont
dup length dict begin {def} forall currentdict end
/CIDFont defineresource pop

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.
# ps font mapping
# Japanese font

# Korean font


..... and similar lines for zh-TW and zh-CN. 

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).

Comment 1 Jungshik Shin 2002-11-30 00:01:56 UTC
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
%!PS-Adobe-3.0 Resource-CIDFont
%%BeginResource: CIDFont (BaekmukBatang-Regular)
(/usr/share/fonts/ko/TrueType/batang.ttf) .openttcidfont
dup length dict begin {def} forall currentdict end
/CIDFont defineresource pop

Comment 2 Jungshik Shin 2002-11-30 00:43:27 UTC
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:

/BaekmukBatang-Regular-UniKS-UTF8-H findfont 50 scalefont setfont
10 100 moveto
<ED959CEAB880> show

Comment 3 Jungshik Shin 2002-11-30 02:03:38 UTC
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....

Comment 4 Jungshik Shin 2002-11-30 02:12:07 UTC
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. 

Comment 5 Jungshik Shin 2002-11-30 04:39:05 UTC
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


Apparently, it's fixed in September. 

Comment 6 Nakai 2002-12-12 09:25:58 UTC
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

Comment 7 Akira TAGOH 2002-12-13 08:41:19 UTC
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.

Comment 9 Nakai 2003-01-15 08:03:53 UTC
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.

Comment 10 Nakai 2003-01-15 08:23:55 UTC
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       ;

Comment 11 Nakai 2003-01-15 08:39:55 UTC
Ghostscript issue filed:

Comment 12 Akira TAGOH 2003-01-15 08:55:39 UTC
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.

Comment 13 Jungshik Shin 2003-01-25 10:03:32 UTC
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. 


Comment 14 Leon Ho 2003-01-31 04:00:15 UTC
Thank you for your report. Close the bug to RAWHIDE based on the completion of 
bug 81924. 

Note You need to log in before you can comment on or make changes to this bug.