rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (08/29/88)
Laser printers are not slow. Adobe PostScript is no speed deamon, but neither can you blame it for 45-minute print times. If your application cannot get pages out at two minutes a page, there is something wrong with your application. There are four main reasons presented for the slow speed of laser printers: interpreter overhead, font downloading, graphics downloading, and the serial interface bottleneck. The interpreter is not super fast (c'mon, Adobe, bind is only half way! Give us a modern forth if you're going to stick us with forth.) But neither is it slow. If you are doing something with the interpreter, you had better have a good reason for it. Don't calculate in the print engine! Use short procedure names for the procedures you use a lot! bind/def when you can. Now, my engine is a QMS PS-810A, which is much faster than a stock LaserWriter, but even the LaserWriter isn't that slow. The PostScript engine is actually quite fast at rendering. I say, if the interpreter is your bottleneck, either you are plenty fast (a minute a page or less) or your application is abusing PostScript. I'll look at serial interface speeds next. If your printer is restricted to a serial interface, and that at 9600 baud, bitch loudly to your printer manufacturer; they've rooked you. The assholes have really rooked you. You want a parallel interface at least, or, if your computer is up to it, a SCSI or better interface. There is no reason to build a laser printer with just a serial interface, Apple notwithstanding; that one move alone has probably cost more man-hours in waiting for all the people using LaserWriters on parallel-capable machines than they could possibly have saved in engineering and parts costs. Shit, one reason the QMS PS-810A is so preferred is because of that parallel interface! And Adobe, give us a better binary tranmission standard than hex; try something like uuencode-format (with graves in place of spaces) with special characters maybe to indicate run encoding. The printer can eat that up as fast as hex, and you'll save a lot of time for everyone involved. Graphics is next. If your application includes some heavy graphics, you will be penalized, but in seconds, not minutes! The PostScript engine can draw many, many vectors per second, and it doesn't suck at halftones either. Maybe your software is spending all of its time scaling coordinates? That's what the damned PostScript engine is good for! I routinely draw graphics with hundreds of edges and labeled vertices; they print plenty fast. 640x400 grey-scale graphics take maybe a minute each. No 45-minute waits here! The most difficult issue is fonts. Resident fonts are almost free, except the first time you use them before they exist in the cache. (If you use enough fonts to overflow the cache, you probably need to reconsider your typography.) Non-resident soft fonts are a different story. But if you use these, you should download them once at the beginning of each day (or whenever you power-cycle the printer) and *bam* they are resident. Buy another megabyte of memory for your printer if you need to do so. At 50K a font, they will take a minute or so to download, but that's only done *once*. You've got too many soft fonts? Well, your software should be able to deal with that; it can query the printer to see if the font has already been downloaded, and if not, download it. Once. Simple enough. Maybe I'm spoiled. But if I had a software package that took ten minutes to print a single page, I'd return it. And buy something that works. -tom
brad@looking.UUCP (Brad Templeton) (08/29/88)
In article <3758@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >PostScript engine is actually quite fast at rendering. I say, if >the interpreter is your bottleneck, either you are plenty fast >(a minute a page or less) or your application is abusing PostScript. >..... >Maybe I'm spoiled. But if I had a software package that took >ten minutes to print a single page, I'd return it. And buy >something that works. >-tom I found this article quite funny. The software I have always used has always printed nicely formatted text at around 6 pages per minute. (In this case, that is the speed of the LaserJet.) While I would certainly toss anything that took several minutes to print a page, I would also do that with anything that took a minute. I find it incredible that people put up with this sort of thing. There's no reason you can't have nice typeset text as fast as the printer can output it. The only reason is badly written software that was never tested properly for speed. There's little excuse for that. I guess none of you are contemplating buying the Panasonic laser partner for the 11 pages per minute. You wouldn't have anything to do with it. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
julius@yugas.UUCP (Julius OKLAMCAK) (09/01/88)
In article <1988@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >In article <3758@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: > >>PostScript engine is actually quite fast at rendering. I say, if >>the interpreter is your bottleneck, either you are plenty fast >>(a minute a page or less) or your application is abusing PostScript. >>..... >>Maybe I'm spoiled. But if I had a software package that took >>ten minutes to print a single page, I'd return it. And buy >>something that works. >>-tom > >I found this article quite funny. The software I have always used >has always printed nicely formatted text at around 6 pages per minute. >(In this case, that is the speed of the LaserJet.) >While I would certainly toss anything that took several minutes to print >a page, I would also do that with anything that took a minute. I find >it incredible that people put up with this sort of thing. > >There's no reason you can't have nice typeset text as fast as the printer >can output it. The only reason is badly written software that was never >tested properly for speed. There's little excuse for that. > >I guess none of you are contemplating buying the Panasonic laser partner >for the 11 pages per minute. You wouldn't have anything to do with it. Benchmarking laser printer speeds and 'through-put' speeds is a kettle of fish. Worse than attempting to benchmark systems and processors. :-) I recently did some simplistic timings to start to get a handle on things. I created a document in Timeworks Desktop Publisher and printed it on three lasers and one ink jet. The results are interesting to say the least... :-) Atari SLM804 1.33 The results are in minutes.seconds. The NEC LC-890 5.54 LC-890 was running PostScript, the Roland Roland LP 1100 14.52 is the same as the Panasonic, all output HP DeskJet 20.44 was done via GDOS and appropriate drivers. So. What does this tell us? (Besides that the SLM804 is the fastest :-) First we need to take a look at how things work under the hood and at exactly what is going on. When TWDTP (Timeworks Desktop Publisher) prints, it opens up a virtual printer workstation, executes the necessary commands to 'draw' the page, and then gives a 'print the page' command. During this time, depending on the device driver used, several different things could be happening: The SLM804 driver simply allocates a bit-map the size of a page, draws to it, then sends it to the printer at approx. 3 mega-bits-per second. If the other drivers worked this way, then we see why the SLM804 is faster. The maximum speed that you can send data down a parallel port is 2000-3000 bytes a second. A full page bit-map is approximately 990,000 bytes - but that is still only about 5 minutes (it appears that there must be an inefficiency somewhere in here when it comes to output devices with HP LJ emulation :-) The GDOS PostScript driver simply translates VDI calls to PostScript code and sends it down the serial port. The major bottle-neck in printing and through-put speeds is getting the data, a representation of the data, to the printer fast enough. Ventura will generate over 150k of PostScript code for a semi-interesting page with two line art graphics and some text (do a print to disk on the VPSCOOP document to see what I mean). The laser then must interpret this PostScript program and render an image into, guess what, a 990,000 byte bit-image of a page. As a result of this, some (most!) laser printers are more powerful computers than the machines they are hooked up to. Printing a page of raw text, especially listings and letters, is a snap for a laser printer. It dosen't have to do any real work. Simply blit the font image data to the page buffer, or even do it on the fly (as some of these lasers with less than 1 meg do). Tricks can also be used to do some bit image graphics with a laser with around 512k of RAM. Some software, like Ventura, uses these and other tricks to get acceptable looking output and printing speeds on HP LaserJet's and compatibles. My next step in benchmarking lasers will be to create the same page that was originally done with TWDTP under Ventura, and possibly a few of the other packages that out there in the PeeCee/MessyDOS & Mac worlds, and time the printings. Julius Oklamcak CIS: 70007,1070 Atari (Canada) Corp. BIX: joklamcak (416) 479-1266 GEnie: J.OKLAMCAK "I don't know what he is talking about. Do you know what he is talking about?" - Rambling Man