Re: RH - question was: canna + kinput2

[Mike Fabian <mfabian@example.com>]

"Stephen J. Turnbull" <turnbull@example.com> writes:

> >>>>> "Mike" == Mike Fabian <mfabian@example.com> writes:
> 
>     Mike> So you think the problem is not in Ghostscript, but in the
>     Mike> CID-keyed fonts?  Really? How did you fix it on you system?
> 
> As I recall I made about 3 separate symlinks in the Resource area.  I
> don't know whather they were all relevant; I suspect the main thing
> was the EUC-V CMap itself was missing.

I have the EUC-V CMap, it is stored in the right place and looks OK as
far as I can tell.

> However, this has since been fixed on Debian, so I don't have my
> setup any more.
> 
> Your wrapper files look nothing like mine:
> 
> /Ryumin-Light-EUC-V
> /EUC-V /CMap findresource
> [/WadaMin-Regular /CIDFont findresource]
> composefont pop
> 
> so I'm not really sure what might be going on.

I wrote the wrapper files myself following the examples in Ken Lunde's
CJKV Information processing book, I only changed the directory
structure.

> My file hierarchy is a lot simpler, too:
> 
> steve@example.com:~$ ls /usr/lib/ghostscript/
> 5.50vflib  6.01  CIDFont  CMap  Font  fonts
> 
> with the relevant ones (CIDFont, CMap, and Font) all being flat (no
> sudirectories).

Yes, my directory structure is more complicated:

    mfabian@example.com:/usr/share/ghostscript/fonts/CID$ find . -type d
    .
    ./Adobe-Korea1
    ./Adobe-Korea1/AFM
    ./Adobe-Korea1/CFM
    ./Adobe-Korea1/CIDFont
    ./Adobe-Korea1/CMap
    ./Adobe-CNS1
    ./Adobe-CNS1/AFM
    ./Adobe-CNS1/CFM
    ./Adobe-CNS1/CIDFont
    ./Adobe-CNS1/CMap
    ./Adobe-Japan1
    ./Adobe-Japan1/AFM
    ./Adobe-Japan1/CFM
    ./Adobe-Japan1/CIDFont
    ./Adobe-Japan1/CMap
    ./Adobe-Japan2
    ./Adobe-Japan2/AFM
    ./Adobe-Japan2/CFM
    ./Adobe-Japan2/CIDFont
    ./Adobe-Japan2/CMap
    ./Adobe-GB1
    ./Adobe-GB1/CMap
    ./Adobe-Identity
    ./Adobe-Identity/CMap

The reason for this directory structure is that the CID-keyed fonts
can also be used for XFree86-4.x, and the backend to render CID-keyed
fonts in XFree86-4.x wants this directory structure. See
http://www.xfree86.org/4.0.2/fonts2.html#5:

        "The CIDFont support in XFree86 requires a very rigid
         directory structure.
         [...]
         "

In Ghostscript I can use any directory structure I like, I only
have to adapt the *.gsf wrapper files to this directory structure.
So I did choose to have the same directory structure for both XFree86
and Ghostscript and make links from XFree86's CID-keyed font directory
to Ghostscript's fontdirectory:

    mfabian@example.com:/usr/share/ghostscript/fonts/CID$ ll /usr/X11R6/lib/X11/fonts/CID/
    合計 36
    lrwxrwxrwx    1 root     root           43 11月 28 19:42 Adobe-CNS1 -> /usr/share/ghostscript/fonts/CID/Adobe-CNS1/
    lrwxrwxrwx    1 root     root           42 11月 28 19:42 Adobe-GB1 -> /usr/share/ghostscript/fonts/CID/Adobe-GB1/
    lrwxrwxrwx    1 root     root           47 11月 28 19:42 Adobe-Identity -> /usr/share/ghostscript/fonts/CID/Adobe-Identity/
    lrwxrwxrwx    1 root     root           45 11月 28 19:42 Adobe-Japan1 -> /usr/share/ghostscript/fonts/CID/Adobe-Japan1/
    lrwxrwxrwx    1 root     root           45 11月 28 19:42 Adobe-Japan2 -> /usr/share/ghostscript/fonts/CID/Adobe-Japan2/
    lrwxrwxrwx    1 root     root           45 11月 28 19:42 Adobe-Korea1 -> /usr/share/ghostscript/fonts/CID/Adobe-Korea1/
    -rw-r--r--    1 root     root         2552  2月  8 01:34 encodings.dir
    -rw-r--r--    1 root     root        13299  2月  8 01:34 fonts.dir
    -rw-r--r--    1 root     root        14524  2月 20 10:47 fonts.scale

>     Mike> Do you think the error is in the font itself or in the CMap?
> 
> The error you posted was a problem finding a resource in the .gsf.

The error message I posted was from Ghostscript 6.01. Ghostscript 5.50
doesn't work either, and the error message is different:

    mfabian@example.com:~$ gs otoko-vertical.ps
    GNU Ghostscript 5.50 (2000-2-13)
    Copyright (C) 1998 Aladdin Enterprises, Menlo Park, CA.  All rights reserved.
    This software comes with NO WARRANTY: see the file COPYING for details.
    Loading WadaMin-Bold-EUC-V font from /usr/share/ghostscript/fonts/WadaMin-Bold-EUC-V.gsf... GS<1>show
    Error: /typecheck in --show--
    Operand stack:
       WadaMin-Bold-EUC-V
    Execution stack:
       %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   3   3   %oparray_pop   --nostringval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1   3   %oparray_pop   --nostringval--   --nostringval--
    Dictionary stack:
       --dict:914/1241(G)--   --dict:0/20(G)--   --dict:50/200(L)--
    Current allocation mode is local
    Current file position is 5
    GS<1>quit

> I'm not sure exactly what because I don't understand the resource
> mechanism very well.  My guess is that somewhere along the line
> somebody either didn't put a necessary file in place (that's what
> happened to me) or used some code that assumes a specific directory
> layout that is not true on your system.

I think the files are all there, I checked carefully. The directory structure
is OK as well. Both EUC-H and EUC-V are there:

    mfabian@example.com:/usr/share/ghostscript/fonts/CID$ find . -name "EUC-*"
    ./Adobe-Japan1/CMap/EUC-H
    ./Adobe-Japan1/CMap/EUC-V

And the wrapper files for vertical and horizontal Fonts differ only
in "H" <-> "V":

    mfabian@example.com:/usr/share/ghostscript/fonts/CID$ diff ../WadaMin-Bold-EUC-H.gsf ../WadaMin-Bold-EUC-V.gsf
    1c1
    < /WadaMin-Bold-EUC-H
    ---
    > /WadaMin-Bold-EUC-V
    3c3
    < /EUC-H (CID/Adobe-Japan1/CMap/EUC-H)
    ---
    > /EUC-V (CID/Adobe-Japan1/CMap/EUC-V)
    mfabian@example.com:/usr/share/ghostscript/fonts/CID$

So I am really very puzzled why this doesn't work for vertical.

>     Mike> There are pretty good free TrueType fonts for Chinese (The
>     Mike> Arphic PL fonts) and for Korea as well (the Baekmuk
>     Mike> fonts). Why not for Japan?  Isn't that strange?
> 
> Korean doesn't surprise me; Hangul are much more regular than kanji.

The Korean TrueType fonts also contain the Hanja. I did test the Hanja
in these fonts only briefly with CJK-LaTeX, but it looks like they are
better than any free TrueType fonts currently available for Japanese.

> Chinese does, though.  I haven't actually looked at the Arphic fonts.
> Simplified glyphs would help somewhat, but they're still hanzi....

There are 4 Arphic PL fonts:

    bkai00mp.ttf Big5 Ming font
    bsmi00lp.ttf Big5 Kai font
    gbsn00lp.ttf GB Sung font
    gkai00mp.ttf GB Kai font

So two of these fonts contain the traditional Chinese characters.
Probably reasonably good Japanese TrueType fonts could be created from
bkai00mp.ttf and bsmi00lp.ttf. These fonts seem to contain almost
everything needed for Japanese, only very few additional glyphs would
have to be created.  Even the kana are included in these fonts.
Several characters seem to be in weird positions in the Arphic fonts
though. For example, when the following Arphic font is view in Unicode
encoding:

    xfd -fn "-arphic-ar pl mingti2l big5-medium-r-normal--0-0-0-0-c-0-iso10646-1"

the Kana start at 0xf700. In the Bitstream Cyberbit Unicode font,
the Kana start around 0x3000. 

And of course the style of these fonts looks rather different from
commonly used Japanese Mincho/Gothic fonts.

-- 
Mike Fabian   <mfabian@example.com>