Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!jarthur!dhosek
From: dhosek@jarthur.Claremont.EDU (D.A. Hosek)
Newsgroups: comp.text
Subject: Re: Chinese TeX
Message-ID: <3313@jarthur.Claremont.EDU>
Date: 30 Nov 89 00:17:36 GMT
References: <20926@unix.cis.pitt.edu>
Reply-To: dhosek@jarthur.UUCP (D.A. Hosek)
Organization: Pitzer College, Claremont, CA 91711
Lines: 45

In article <20926@unix.cis.pitt.edu> jbw@unix.cis.pittsburgh.edu (Jingbai  Wang) writes:

>I strongly suspect if MetaFont type of approach can sucessful solve Chinese
>formatting with TeX. According to mainland China GB standard (equivalent to
>ASCII in USA), there are 87x94 Chinese characters. If each set of metafont
>can carry 127 of them, you need more how many of them? and they all have to
>be defined by \font. I am afraid TeX (especially LaTeX) memory will be blown
>up. 

>JTeX used PK and TFM files which are not derived from Metafont, but they seem
>to have ways to reduce number of sets. By the way, JIS has 94x94 characters.

>I have completed a project of Chinese TeX, but it only supports PostScript
>for the timebeing. It has nothing to do with metafont. I have talked to your
>friend Nelson Beebe lately to have it installed in science.utah.edu for
>distribution. Of cource, if metafont is available, I will modify it to use
>metafont files indirectly. I don't want to see TeX/LaTeX memory and printer
>VM blown up.

Actually, Metafont can generate up to 65536 distinct character codes which
is sufficient for all existing character sets (although I've heard a
proposed 24bit Japanese set mentioned as a possibility for the future).

JTeX works by breaking down the JIS set into 256 character subfonts.
I believe that TeX retains the TFM organization of information in its
own font info tables, in which case a 256 character Kanji font would
probably take no more space than the info for a font like cmex10 (only
one height, width, and depth would be necessary). There is another
version of jTeX which uses 65536 character fonts as well.

The printer VM problem really isn't one because any decent DVI driver
only downloads those characters that are actually used, and if VM is
cleared after each page, it would be difficult to run out of VM.

The bigger problem is more the sheer tedium of writing and debugging
all the individual character programs. See my paper presented at the
TUG conference in August (to appear in the proceedings issue of TUGboat)
for details of one approach.

-dh
-- 
"Odi et amo, quare id faciam, fortasse requiris?
   nescio, sed fieri sentio et excrucior"          -Catullus
D.A. Hosek.                        UUCP: uunet!jarthur!dhosek
                               Internet: dhosek@hmcvax.claremont.edu


Brought to you by Super Global Mega Corp .com