phil@RICE.EDU (William LeFebvre) (07/15/87)
>From: Southall.pa@xerox.com > There is, in principle at least, a way of making your own > PostScript versions of Computer Modern fonts. If you set > > tracingchoices:=1 ... > What you *don't* get with this approach is Adobe's proprietary 'font > magic', which looks after the preservation of character features when > their own character shape descriptions are digitized at low and medium > resolutions....The results of the Metafont-to-PostScript conversion > will be less satisfactory in text sizes than pixel files produced with > Metafont's own digitizing algorithm. From this I assert the following claim: what you don't get with PostScript is any versatility in digitizing your own fonts. You are stuck with the algorithms that Adobe uses. Worse than that, you cannot even get to all the algorithms that Adobe has, unless you know about the "magic". Am I right? Is it true that the only type of font description which can be given to a PostScript engine is a spline-based one? >From: prj@pm-prj.lcs.mit.edu > The lab I work in has just started converting to using PostScript > printers as our standard printers. We are now getting complaints from > our TeX users about how slow printing is for them now. Quotes range > from an average of 2 pages per minute up to a max of 5 pages per minute > (both on the "24 pages/minute" PS2400s). Since this must be a common > problem for other academic and research institutions.... 5 pages per minute? I get better performance out of our Imagen 2308: 8 pages per minute and it isn't a PostScript engine. From this I assert the following claim: PostScript engines are very slow. Perhaps someday in the distant future they might be running an acceptable speed---when we start using 68030 processors in them and when we start putting them on Ethernets (so that transmitting the very verbose document description won't slow us down as much). Abstractions are very nice from a theoretical standpoint. Certain abstractions are also very nice in practice. PostScript is a very nice abstraction. But when the abstraction severely impedes performance and versatility, I begin to question its practical value. By the way, I have never had the need or the sudden urge to print text in a spiral (or for that matter, at any orientation other than 0 and 90 degrees). William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
ambar@ATHENA.MIT.EDU (Jean Marie Diaz) (07/29/87)
In article <8707282014.AA19351@brillig.umd.edu> phil@RICE.EDU (William LeFebvre) writes: >5 pages per minute? I get better performance out of our Imagen 2308: >8 pages per minute and it isn't a PostScript engine. From this I >assert the following claim: PostScript engines are very slow. Perhaps >someday in the distant future they might be running an acceptable >speed---when we start using 68030 processors in them and when we start >putting them on Ethernets (so that transmitting the very verbose >document description won't slow us down as much). Our LPS-40 will crank out 40 pages per minutes, after a short pause (~30 seconds) to download the TeX fonts. That sounds sufficiently practical to me... Sure, an LPS-40 isn't cheap (yet), but it isn't the distant future, either, it's right here and now... AMBAR ARPA: ambar@bloom-beacon.mit.edu UUCP:(get smail!): {mit-eddie,husc6,garp,bu-cs}!bloom-beacon!ambar
roy@phri.UUCP (Roy Smith) (07/29/87)
In <8707282014.AA19351@brillig.umd.edu> phil@RICE.EDU (William LeFebvre) says: > Is it true that the only type of font description which can be given > to a PostScript engine is a spline-based one? Not at all (he says with perhaps more conviction than his experience justifies). I'm no PS guru but I've been playing with it for a couple of years and took some stabs at defining my own fonts. What I quickly learned, however, is that as bad as I am at writing PostScript programs, I'm even worse at designing fonts. :-) For example, the code at the end of this note defines a bitmap font called Matrix (which only has a single character in it, 'A') and prints some samples at various sizes. As far as I can tell, Matrix is a true font, just like Helvetica or Courier and you can do anything to it you could to any other font (scale it, make it pseudo-italic by slanting it, wrap it arount a spiral, etc). > 5 pages per minute? I get better performance out of our Imagen 2308: > 8 pages per minute and it isn't a PostScript engine. From this I > assert the following claim: PostScript engines are very slow. Well, yes and no. We've got several Apple LaserWriter and LaserWriter-Plus printers. Mostly we run troff output on them, using Adobe's TranScript package. Yes, it's slow, no more than about 3-4 ppm I guess. But, considering that a "bib | tbl | eqn | ptroff" pipeline on an 11/750 or a Sun-3 can't begin to approach that rate, I don't worry about it much. If you've got faster hardware (or software), it obviously becomes more important to have your printer keep up. I will admit, that for a given amount of money, if you don't need the fancy PS features, you will probably do better with a non-PS printer and pour the money you save on the controller into the print engine. We're just getting the bugs out of our first kbox (Kinetics' Ethernet/AppleTalk bridge box). This lets us send stuff at AT speed (200 or so kbps) instead of the 9.6 kbps we're used to. That won't do anything about the slow PS engine in the LW, but it will zap the transmission time problem. For some applications (printing 512 x 512 halftone images) which are almost 100% transmission time, we think we'll be able to go from about 5 minutes a page to about 4 pages per minute. > Perhaps someday in the distant future they might be running an acceptable > speed---when we start using 68030 processors in them and when we start > putting them on Ethernets (so that transmitting the very verbose > document description won't slow us down as much). DEC's LPS-40 is supposedly a 40 ppm PS printer. From what I've heard, that rating really does reflect how fast the PS processor can compose and print pages, not just the raw speed of the print engine. Then again, the LPS-40 has a uVax-II in it, with a pricetag of almost $60k. My guess is that with a 68020 class machine, and some simple hardware support for token parsing, name lookup, and coordinate transformations, you should be able to build a PS printer in that performance range to sell for maybe as little as half that. Agressive pricing and market competition would help, neither of which seems to be in effect now for the high-end machines like the LPS-40. There were some very interesting discussions on the INFO-POSTSCRIPT mailing list back around November 1985 on this very subject. > By the way, I have never had the need or the sudden urge to print text in a > spiral (or for that matter, at any orientation other than 0 and 90 degrees). I'll admit that I've never needed to print spiral text either, but we do take advantage of some of the fancy PS features every day. For example, if you do: /Helvetica findfont [13.3 0 0 10.3 0 0] makefont setfont you end up with a sort of HelveticaExpanded which almost exactly matches the typeface used on our pre-existing letterheads. No more feeding letterheads into LaserWriters for us; just put a ".LH" macro in front of your letter and get a letterhead generated as you go. And, yes, we do have the need to print text at all sorts of strange angles (labels for plasmid restriction maps), and while we don't take advantage of it yet, those maps would look even nicer if we wrapped text around the outside of an arc. /roy ----feed the following to a PostScript printer for Matrix demo---- %! /BuildCharDict 10 dict def /MatrixFont 7 dict def MatrixFont begin /FontType 3 def /FontMatrix [1 0 0 1 0 0] def /FontBBox [0 0 1 1] def /Encoding 256 array def /CharacterDefs 28 dict def 0 1 255 {Encoding exch /.notdef put} for CharacterDefs /.notdef { } put Encoding (A) 0 get /A put CharacterDefs /A { .65 1 scale % 0.65:1 aspect ratio 8 12 true [8 0 0 -12 0 12] {<00 3C 42 42 42 7E 42 42 42 42 00 00>} imagemask } put /BuildChar { BuildCharDict begin /char exch def /fontdict exch def fontdict /Encoding get char get /charname exch def fontdict /CharacterDefs get charname get /charproc exch def 0.65 0 0 0 8 12 setcachedevice gsave charproc grestore end } def end /Matrix MatrixFont definefont pop /inch {72 mul} def 2 inch 5 inch moveto /Matrix findfont 48 scalefont setfont (AAAAAAA) show 2 inch 4 inch moveto /Matrix findfont 24 scalefont setfont (AAAAAAA) show 2 inch 3.5 inch moveto /Matrix findfont 12 scalefont setfont (AAAAAAA) show 2 inch 3 inch moveto /Matrix findfont 7 scalefont setfont (AAAAAAA) show showpage ----end of Matrix demo---- -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
Zanarotti@MIT-MULTICS.ARPA (Stanley Zanarotti) (07/30/87)
>From: William LeFebvre <phil at RICE.EDU> >Subject: Why I think I dislike Postscript >From this I assert the following claim: what you don't get with >PostScript is any versatility in digitizing your own fonts. >...Am I right? Is it true that the only type of font >description which can be given to a PostScript engine is a spline-based >one? No, bitmap fonts can be downloaded using the Postscript program that dvi2ps uses. The theory is to define a font whose drawing procedure looks up the bitmap in a table, and places that bitmap on the page. The characters that the document uses can be downloaded into this table. >>From: prj@pm-prj.lcs.mit.edu >> The lab I work in has just started converting to using PostScript >> printers as our standard printers. We are now getting complaints from >> our TeX users about how slow printing is for them now. Quotes range >> from an average of 2 pages per minute up to a max of 5 pages per minute >> (both on the "24 pages/minute" PS2400s). Since this must be a common >> problem for other academic and research institutions.... > >5 pages per minute? I get better performance out of our Imagen 2308: >8 pages per minute and it isn't a PostScript engine. From this I >assert the following claim: PostScript engines are very slow. Perhaps >someday in the distant future they might be running an acceptable >speed---when we start using 68030 processors in them and when we start >putting them on Ethernets (so that transmitting the very verbose >document description won't slow us down as much). Since the printer in question is down the hall from my office, I can't resist replying to this. When I saw you were replying to Paul's message, I hoped you were going to give some advice, not try to use our problems as an excuse to say that Postscript is slow. The problem has not been tracked down to the printer itself. I would not rule out other factors, like the dvi2ps conversion being performed on the Microvax controlling it, from contributing to the poor performance. I'll note that the speed of the 24-ppm printer seems to be slower than our 8-ppm Postscript printer. Although they're both manufactured by QMS, it sounds like the 2400 has a poor implementation of Postscript. You shouldn't blame a language on a poor implementation. -stan