Re: Japanese TeX: if you're really macho...

[turnbull@example.com (Stephen J. Turnbull)]

>>>>> "Andrew" == Andrew S Howell <andy@example.com> writes:

    Andrew> 	Wadalab-mincho-0-12.ps

    Andrew> from ftp.ipl.t.u-tokyo.ac.jp/Font/tools

Yes, this appeared within the last couple of months (despite the date
on the file; I know it wasn't there in August).  It's apparently a
somewhat cleaned up version of the code in the USAGE.ghostscript.*
files.  I still don't trust it; look at Peter Deutsch's code in
wftopfa.ps.  Peter admits that his code is very skeletal, but it's
much easier to understand than wftopfa.c and the USAGE.* files.  And
there are some comments in it....  Wadalab-mincho-0-12.ps is just not
well documented yet.

    Andrew> Anyway, you take that file, put in the font path ( gs --
    Andrew> version will tell you the font path ) and make entries in
    Andrew> the Fontmap like:

    Andrew> /Wadalab-mincho-0-8 (Wadalab-mincho-0-8.ps) ;

    Andrew> The individual files for /Wadalab-mincho-0-8 have entries
    Andrew> like

    Andrew> /Wadalab-mincho-0-8.r21 (jis-21.pfa) ;
etc
    Andrew> /Wadalab-mincho-0-8.r24 (min-0-8-24.pfa) ;
etc

This is ugly and error prone.  But it works....  One note:  I prefer
to have a common skeleton containing all of the necessary entries,
with the following form:

/Wadalab-FONT-SUIJUN-WEIGHT.r21 (symbol/jis-21.pfa) ;
...
/Wadalab-FONT-SUIJUN-WEIGHT.r24 (FONT-SUIJUN-WEIGHT/fontBase-24.pfa) ;
...

where I just leave fontBase to be whatever happened to come out of the 
Wadalab tarfile.

    Andrew> It finds (min-0-8-30.pfa) and loads the all the characters
    Andrew> in that file. It this sounds like it is a sloow process,
    Andrew> it is, but it does work. This same file (
    Andrew> Wadalab-mincho-0-12.ps ) works with jis-x208, but not with
    Andrew> 212, I think.

That's right.  The convention is "Foundry-Family-SuijunFlag-Weight".
SuijunFlag is 0 for JISX-0208, and 1 for JISX-0212.  So you'd need a
Wadalab-mincho-1-12.ps file, and the corresponding fonts.

A couple of hints on "slo-o-ow":
(1) When you send it to the printer, everything is in the background,
    so usually no biggee.
(2) Keep your gs process alive somehow (Ctrl-Z/fg or virtual consoles
    or a separate xterm for the command interpreter); once the font is
    loaded, it stays there, even through rescalings and the like.  The
    gs interpreter is not very friendly about searching paths (in
    particular, there's no notion of 'cd', although it's not hard to
    write some postscript code to give the equivalent).

    Andrew> The other option is to concatinate all the min-0-8-*.pfs
    Andrew> files into one and load them all at once. This works,
    Andrew> though I could not get one of the fonts to work, GS barfed
    Andrew> on it.

Again, beware of GS 4.0x, x < 3.

    Andrew> I could not get this to work for sjis. From my notes:

    Andrew> gs_kanji.ps and gs_ksb_e.ps are used by wftopfa.ps to
    Andrew> produce a a single font file that is then accessed like:

    Andrew> /Wadalab-SaiMincho (wmin0.ps) ;

    Andrew> Looks like gs_kanji should produce encodings for JIS and ??

I don't know; I didn't worry much about the encodings; as long as JIS
worked (my TeXs barf on EUC and SJIS for some reason).  Peter Deutsch
is not a Japanese encoding specialist.

I got that huge file approach to work, sort of.  But there were a
couple of oddities in the Wadalab encoding compared to the old
ASCII-JTeX, so I went back to the separate file method to track them
down.

One thing that is useful about the separate file method is that by
mucking with the dvipsk psfont.map file you should be able to arrange
that the fonts be prepended as header files (the facility is there, I
haven't tried it yet).  Then only the needed leaf fonts will get
included, my guess is that many documents will only need 15 or so of
the 77 leaf fonts.

Andrew asked what I would do if I had a lot of free time.  Well, there
are two projects I have in mind.  First, making a kanji font with Type
4 leaf fonts.  The idea is that the Charstrings (the actual glyph
definitions) would reside in a huge file, indexed through the Type 0
-> leaf font, but the leaf fonts would not actually contain any glyph
information.  Instead, they would randomly access the database to get
the information.

The second is that once that was done, it shouldn't be too much harder 
to write a program to generate a header containing only the glyphs
that were actually used.

Third, I wonder if Ghostscript could be patched to use Kpathsea....
Peter Deutsch has probably thought of this; if he did, he would have
rejected it because he has an unshakeable disagreement with rms over a 
few points in the GPL, and it just wouldn't be possible to integrate
Kpathsea (GPL) with Ghostscript without bringing the whole thing under 
the GPL.  But that doesn't stop *us* as long as we don't distribute
it.  Kpathsea would be much better than the current confusion in
Ghostscript path searching.

Steve

-- 
                           Stephen John Turnbull
University of Tsukuba                                        Yaseppochi-Gumi
Institute of Policy and Planning Sciences  http://turnbull.sk.tsukuba.ac.jp/
Tennodai 1-1-1, Tsukuba, 305 JAPAN                 turnbull@example.com
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096