Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!unix.cis.pitt.edu!jbw From: jbw@unix.cis.pitt.edu (Jingbai Wang) Newsgroups: comp.text Subject: LPS40, dvips, Chinese TeX, ln03dvi, etc Message-ID: <20926@unix.cis.pitt.edu> Date: 29 Nov 89 22:25:23 GMT Reply-To: jbw@unix.cis.pittsburgh.edu (Jingbai Wang) Organization: Univ. of Pittsburgh, Comp & Info Sys Lines: 176 I am sorry for putting multiple subjects in one article, but my system tends to reject my postings if I do more than one in half a day. Contents: 1. PrintServer40 Metafont problem fix 2. Chinese fonts and metafont and Chinese TeX 3. dvips and PostScript fonts 4. ln03dvi hacking experience (in a separate article) by JB Wang, jwang@pittvms.bitnet, jbw@unix.cis.pitt.edu 1. PrintServer40 Metafont problem fix ************************************* In article <885@shelby.Stanford.EDU> TeXhax@cs.washington.edu (TeXhax Digest) writes: |TeXhax Digest Monday, November 27, 1989 Volume 89 : Issue 105 ... |Date: Tue, 14 Nov 89 13:38:43 EDT |From: WAS@UACSC1.ALBANY.EDU |Subject: Printing TeX documents on a Digital PrintServer 40 |Keywords: TeX, Digital PrintServer | |The Computing Services Center at the University at Albany has a |Digital PrintServer 40 laser printer and the Math department has |an LN03R. Much of the TeX output from these printers is of poor |print quality. The problem stems from the fine strokes of many |of the characters in the CM typefaces. The fine strokes tend to |break up. We have no trouble with typefaces that are heavier in |weight such as the bold faces. I am told that output from an |Apple LaserWriter does not have this problem, although I have not |seen the output. | |Has anyone else experienced this problem? Does anyone have a solution? | |Bill Schwarz | It has come to our attention for quite a while that DEC LPS40, even though having huge VM, does treat bitmap fonts quite unfairly. For TeX MetaFonts (such as cmfont, amsfont) the solution is not that tough, just give a big parameter to the `black' in *.mf files, and regenerate *.*gf files, and convert them to *.*pk file with gftopk. I think that answers your question. I have hard time, however, to fix my Chinese fonts which are not MetaFonts. JB 2. Chinese fonts and metafont and Chinese TeX ********************************************* In article <885@shelby.Stanford.EDU> TeXhax@cs.washington.edu (TeXhax Digest) writes: |TeXhax Digest Monday, November 27, 1989 Volume 89 : Issue 105 ... |Date: Wed, 15 Nov 89 18:24:11 MST |>From: thomson@cs.utah.edu |Subject: Chinese MetaFont? |Keywords: METAFONT, Chinese | |I read in the TeXBook that a version of the MetaFont program was created |for Chinese character fonts. Is this version of MetaFont available? I'm |looking for freely available text processing capabilities for Chinese |character sets and TeX would be my first choice. I ftp'ed the |chinese.tar.Z file from cs.washington.edu. This gives some metafont files |that describe the necessary changes to the standard metafont needed in |order to work with the larger character tables. Unfortunately I can't |decipher the change instructions! | |Is there anyone out there who is using TeX/MF in such a capacity, or has |the necessary instructions for how to modify MF? We have the full sources |to TeX/MF here at Utah... I did notice that MF here is MF84 and not MF82; |were there major changes to many modules between '82 and '84? | |Please e-mail me as I don't read TeXhax regularly. Thanks in advance. | | -- Rich |Rich Thomson thomson@cs.utah.edu {bellcore,hplabs,uunet}!utah-cs!thomson 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. JB |From zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!rice!uw-beaver!Teknowledge.COM!polya!rokicki Wed Nov 29 16:48:59 EST 1989 |Article 5630 of comp.text: | |jbw@unix.cis.pitt.edu (Jingbai Wang) writes: |> The dvips40~42 available from labrea.standford.edu (which has been down |> for a while now, they are working on it), does not support Adobe fonts |> the same way, and you may have to modify the font definitions as |> \newfont{\hb}{Helvetica-Bold at 12pt} |> (etc...) |> \newfont{\trsix}{Times-Roman at 6pt} |> Unfortunately, this kind of scheme is not portable to UNIX System V |> and DOS, since System V only buys file length of 14 characters and DOS 8. | |Actually, dvips does indeed support the aliasing the other drivers do, so you |can indeed use h-bol instead of Helvetica-Bold if you are working on an |ancient relic of a machine. Simply place the alias following the PostScript |font name in psfonts.map. | I see that, actually the other day when somebody was asking a question on this board about porting dvips to System V including short names, I tried to give him this hint. But since I will get to dvips later, I chose to wait. |Sorry labrea has been down for so long; wish I could do something about it. |Get dvips421 when you do get it . . . | |> Another drawback of dvips is that it attempts to solve the missing PK font |> file problem by envoking Metafont, and I feel it to be inefficient and |> not generalizable. Since to generate Metafont, you need mf84 setup on your |> site, and you need all the *.mf file handy. In this aspect, my version of |> dvi2ps displays the unique advantage of doing best substitution and scaling |> the font to the exact size (as specified in TeX) by PostScript scaling. | |But until you've had the freedom to specify `scaled 7000' and watch everything |work beautifully, you haven't lived . . . | Not really. Do you really want to use a font which is 7000pt large. If you generate a MF of 7000pt, you will jam all your disk space and spend lots of I/O time. |My main beef is that so many people use the `find closest size' as a normal |style, yielding wildly varying results at different sites and with different |drivers. All over I see people saying `cmr10 at 18truept' or some such, and |getting widely-spaced small letters on one printer, slightly jagged |approximations on a second, blank spaces instead of characters on a third, That has been solved in w_dvi2ps |and no output at all on a fourth. It's very fast to create a single font, |and once you do, it's always there . . . | |Of course, having the automatic generation also solves the problem of font |storage, since instead of 8M of fonts, you need only (typically) 1M after |extended use . . . | |> JB Wang | |But I do plan to put in autoscaling for those who need it and don't want |to hassle with MF. The question is, when? | |-tom I may lay my hands on it whe I get time. I have intention to support it for Chinese TeX and System V. JB 4. ln03dvi hacking experience (details in a separate article) ************************************************************* After fighting through jungles of bugs, I have made ln03dvi (V1.2-**) work for VAX and non-VAX machines (including VMS and UNIX BSD and System V. Somebody had questions on that. He can contact me directly. JB Brought to you by Super Global Mega Corp .com