Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!visix!amanda From: amanda@visix.com (Amanda Walker) Newsgroups: comp.sys.mac.comm Subject: Pass Through Printing (was Re: MacTerminal 3.0) Message-ID: Date: 31 Oct 90 16:44:18 GMT References: <24@uarthur.UUCP> <11039@goofy.Apple.COM> <1990Oct31.012421.12492@ux1.cso.uiuc.edu> Organization: Visix Software Inc., Reston, VA Lines: 71 Part of the problem here is that pass-through printing in a Mac terminal emulator is very hard to do right, and even fairly hard to do at all. So far I know of only two implementations for DEC terminal emulators--I did one (in TCP/Connect II), and Software Ventures did the other (in MicroPhone II 3.0). We took different approaches, each of which has problems. I am not arguing that it is an important capability, but I also don't think that Apple is necessarily being lax in not providing it yet. I'll try to explain what makes it so difficult to do. The problems stem from the fact that printers are not accessed the same way on a Macintosh the way that they are on a PC or a CRT terminal. On a terminal or PC, a printer is just another device you can send bytes to. For pass-through printing, then, all the emulator (or terminal) has to do is forward the incoming bytes to the printer, instead of interpreting them and updating the screen. No big deal, which is why many terminals have local printer ports on them--it's a cheap feature to add. On a Macintosh, a printer is just another place you can draw. Also, with the current printing architecture, the Print Manager really wants you to draw whole documents (or at least pages) at once. This is great for most Mac printing, but it poses a problem when you want to do pass-through. There are three basic approaches, each of which works for some applications and not others. The two easiest ones are, in a sense, cheating, IMHO :), but they do provide what many people want. 1. Forget the print manager. There are many applications, such as invoice printing, 911 call logging, and so on that only require a "dumb serial printer" which prints data in straight ASCII as it comes across the wire. The easiest way to support these applications is to echo the print data out the serial port, bypassing the print manager altogether. This gives you an almost perfect analogue of traditional pass-through printing, but it restricts you to serial, ASCII-oriented printers. No LaserWriters or AppleTalk ImageWriters, no ATM, no spooling. Within these constraints, though, it works great. 2. Spool the and print it all at once. This is a compromise. Many applications do local printing by putting the terminal into printer mode, sending a bunch of data, and then taking the terminal back out of printer mode. This can be supported fairly well by buffering the data until printer mode is turned off, and then opening a print sesssion and drawing pages. This way, you can use any Mac printer, but you are constrained to applications that print entire documents in a single burst. Once again, though, within its constraints, this method works great. These two methods are easy to implement, but each only address a piece of the overall problem. The general solution is the hardest: 3. Guess what the user wants and Do The Right Thing. This involves guessing when documents start and stop, and then printing them using method (2) above. This is a hard problem. To do it right, you need to do a bunch of heuristics involving timing, content analysis, and in some cases even special-case code to support particular applications. This is what Apple "should" do, but i certainly don't envy them the job. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- Me not responsible. Me just pawn in game of life.