summaryrefslogtreecommitdiff
path: root/info/digests/texline/no7/barb.tex
blob: 58e41681bf895aa3bf8ae8d7c882da882f9231b6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
\centerline{\bf PostScript and math}
\medskip\noindent
Various comments on this subject (mainly
appearing in \TeX{\sc hax}) have finally goaded me into putting in my
two cents' worth.  For a publisher of mathematics, there are two problems
with trying to generate \TeX\ output on a \PS\ typesetter --- fonts and
speed. 

 Leaving aside the fact that some people just like other fonts
better than Computer Modern, there is really no good alternative at present
to the Computer Modern math fonts.  And, in my opinion, even if they're
generated from outlines in the ``native'' \PS\ fashion, the CM math
shapes simply don't mix well with other styles.  It's got to be  possible
to make other alphabets (e.g.~Times Italic) behave well in math --- in fact,
it's been done at the American Math Society for some non-\PS\ Times fonts
--- but it's a {\it lot} of work!  And I didn't realize until the job was done,
and I was seeing competent math coming out of our typesetter in Times, the
extent of the subtlety in the Computer Modern math.  

With Computer Modern,
someone with a trained eye can spot math very quickly.  The spacing of the
italic is clearly different from that of the math, but also, the shapes
are different. (Take a closer look sometime.)  This means that in theorems,
traditionally set in italic (here I personally like Knuth's innovation of
slanted, but my opinion is not shared by my employer's editorial staff),
it's possible to distinguish math from text quite easily, even the single
letter a ({\it a} versus $a$).  
I know of no other fonts, anywhere, where this sort of distinction
has been made.  (But I'd welcome hearing about it if anyone else does.)
	
Regarding speed, most of the \PS\ rips (raster image
processors) are geared for low-resolution production, say 300\,dpi, the
resolution that requires 1\,Mbyte  of memory to hold a full bitmap of a US
letter-size page.   Even keeping up
with a relatively fast print engine like the 40\,ppm {\sc dec}\-server40 is child's
play compared to keeping up with the rated speed of a real typesetter,
with over 1000\,dpi resolution.  I would welcome
some statistics for typesetters performing ``real'' jobs --- using a large
selection of (native) fonts in several sizes.  Without outline fonts for
math, any math job statistics are probably meaningless, since the time
to download bitmaps is relatively much greater than to use outline fonts.

A promising development I've read about recently ({\it Seybold Report}, Dec 28)
is a new rip designed to handle Alphatype's Alphacomposer, which has a
resolution of $5300\times5300$\,dpi and runs at a maximum speed of 3 minutes/page.
That's a 280\,Mbyte bitmap requirement for $8\times10\,\hbox {in}$!  (The same article gives
benchmark results from Linotype  showing that its present rip can't even
keep up with a 1270\,dpi engine.)  The new rip is supposed to be ready for
demonstration sometime during the first quarter of 88; it was developed
by Medianet, not Alphatype, and the agreement is non-exclusive.  This
looks like it's worth watching.  Until this kind of speed is available
for \PS\ typesetters, they just won't be practical for technical
publishers, and 300\,dpi (even 600\,dpi) just isn't good enough for the
highest-quality typesetting that most major publishers are looking for.

\rightline{\sl Barbara Beeton}