Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!aplcen!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.text
Subject: Re: A C program for a Calendar in LaTeX.
Message-ID: <21011@mimsy.umd.edu>
Date: 29 Nov 89 22:19:38 GMT
References: <778@stat.fsu.edu> <12898@polya.Stanford.EDU> <5798@ubc-cs.UUCP> <20915@unix.cis.pitt.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52

>>... [a] way of mapping PostScript fonts into LaTeX. `h-bol' is
>>Helvetica Bold. `t-rom' is Times-Roman.

In article <20915@unix.cis.pitt.edu> 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),

It fell into a tar pit in the earthquake :-)

>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 (of dvips) is not portable to UNIX System
>V and DOS, since System V only buys file length of 14 characters and DOS 8. 

These systems are deficient.  I agree with Tom Rokicki in preferring the
long names.  As a compromise, my latest change was to accept both the
long names and the abbreviated versions, depending on the contents of the
TeXPSfonts.map file.  (The installer may omit the short names.)

>Another drawback of new 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.

This should be no harder than having TeX82 set up on your site, and
having all the *.tfm files handy.

Although my code does not have an option to invoke Metafont, I do intend
to create one, once I figure out how it should work.  It is, I think,
much more efficient than the alternative, which is to store every font
in every standard magnification for every sort of output device you
have.  It seems much more sensible to use the GF/PK files as a cache
mechanism, so that you only keep on-line the ones you normally use.
(Figure it this way: pk files for all fonts at 300 dpi = ~10 MB; then
the second set for the write-white 300 dpi devices is another 10 MB;
add the set for the 1000 dpi typesetter at, say, ~90 MB, and now we are
using a fair bit of space.)

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

This is not unique: Van Jacobson's dvi2ps does the same thing.  The
results are seriously ugly for most scale factors.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris


Brought to you by Super Global Mega Corp .com