amanda@visix.com (Amanda Walker) (11/01/90)
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.
leonardr@svc.portal.com (Leonard Rosenthol) (11/01/90)
In article <ts351ddcfa@visix.com>, amanda@visix.com (Amanda Walker) writes: > [stuff removed from brevity] > > 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. > Boy is that an understatement if I ever heard one!! > 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. You actually forgot one - which is a variant of this, and what MicroPhone II does - and that is to use the Low Level Text Streaming interface of the Print Manager. This has the advantage that it works with printers such as Appletalk Imagewriters and Laserwriters, but doesn't work with other third party printers, like the DeskWriter, which don't support this interface. The other problem with using this is that Apple has tried REAL HARD to not keep this compatible with current stuff - and has guarenteed that in the future when the 'New Printing Architecture' arrives (post 7.0) this stuff will have gone bye-bye. > 2. Spool the document and print it all at once. This can also be modified to do such things as print every page (or at FF's), or don't print until MANUALLY told to, or whatever. We are investigating such spooling options for future MPII's in order to maintain compatibility with the future. HOWEVER, the biggest problem with doing this is that a file on disk (or in memory) is _NOT_ the same as a printer and that should the host send printer command codes or control sequences there is no good way to interpret these by your spooler. This means that you can solve SOME problems, but not all of them - and those hosts which like to do lots of printer manipulation will not work with this method. > 3. Guess what the user wants and Do The Right Thing. In my mind, the 'Right Thing' is for Apple to understand that if Communications and Connectivity are a concern for them, that giving developers the ability to 'stream text' just like a terminal should also be considered. -- Leonard Rosenthol Software Ventures Corp. MicroPhone II Development Team
rpcfod@uarthur.UUCP (Robert Patt-Corner) (11/02/90)
In article <ts351ddcfa@visix.com>, amanda@visix.com (Amanda Walker) writes: > > 1. Forget the print manager. > ... > > 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 is what Apple "should" do, but i certainly don't envy them the job. But the immediate issue isn't so much implementing a general purpose all flavors printing subsystem as implementing a specific and well-defined characteristic of a single (well OK, two) terminal emulator - the Digital VT320. Solution two should do a very nice job it seems to me ... the "PRINTER ON" and "PRINTER OFF" escape sequences define very precisely where the page to be printed begins and ends. Granted, there are other DIGITAL(tm?) print sequences that could be included (I think there's one for print the screen, print to a specific screen position, etc.), good old TURN ON, PRINT, TURN OFF covers the 98 per cent of cases I've seen. And that's worth doing. I appreciate the concerns for general print everything solutions, but meantime, what we've got is mark and print. It might be effective to avoid an over-engineered solution in favor of a more readily available but legal solution that makes most people happy most of the time. Naturally I don't think solution 1 -- breaking the rules -- should be done at all by anybody. I guess if I were wearing my developer's hat I might feel differently, but with my site manager hat on, this seems clear ............. On a clear day ... you can see the sky!
amanda@visix.com (Amanda Walker) (11/02/90)
In article <25@uarthur.UUCP> rpcfod@uarthur.UUCP (Robert Patt-Corner) writes: >But the immediate issue isn't so much implementing a general purpose all >flavors printing subsystem as implementing a specific and well-defined >characteristic of a single (well OK, two) terminal emulator - the Digital >VT320. Solution two should do a very nice job it seems to me ... the >"PRINTER ON" and "PRINTER OFF" escape sequences define very precisely >where the page to be printed begins and ends. Would that it were so simple. First, though, let's simplify it by dropping all of the line-by-line printing support, so that all we have is Printer Controller Mode. If an application sends an entire page (or document) in one invocation of printer controller mode, life is fine (this is, in fact, what my implementation does). However, there are a number of applications that toggle into and out of printer controller mode, thus giving the user such interesting effects as "one line per page," etc. It all depends on the application. Having been in the position of having had to talk to irate customers, I can assure you that telling them that their VAX software is ill-behaved is not going to make them any happier :). And of all vendors, Apple is liable to get the most flak for putting out something that is only partially functional. I mean, look at this whole discussion :)... -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- Good Morning is a contradiction in terms.
urlichs@smurf.sub.org (Matthias Urlichs) (11/02/90)
In comp.sys.mac.comm, article <ts351ddcfa@visix.com>,
amanda@visix.com (Amanda Walker) writes:
< 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.
< [...]
<
< On a terminal or PC, a printer is just another device you can send bytes to.
< On a Macintosh, a printer is just another place you can draw.
<
Guess what your VTxxx emulator does?
Right -- it translates bytes into pictures.
< 1. Forget the print manager.
< 2. Spool the and print it all at once.
< 3. Guess what the user wants and Do The Right Thing.
<
So? What you're already doing is emulate a VTxxx (or whatever) into a
grafport, which happens to be a window.
Would it be that much harder to emulate a FX80?
Emulating a LaserJet would probably be overkill, but while you're at it... ;-)
< This involves guessing when documents start and stop, and then printing
< them using method (2) above. This is a hard problem. [...]
Forgive me if I'm a bit naive here, but wouldn't a customizable timeout and a
menu command and/or alert "print current page now" be sufficient?
Or better still, you could probably make a "FX80" terminal which doesn't
accept keyboard input, but which defaults to printing each page as it's
finished.
(Don't forget the form feed button. Printers have those too, you know. ;-)
Then all you have to do is to make your terminal tool hand off the stuff
that's destined for the "printer" to just another terminal tool.
Anything wrong with this idea?
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/rpcfod@uarthur.UUCP (Robert Patt-Corner) (11/03/90)
In article <ttbfkxngsa@visix.com>, amanda@visix.com (Amanda Walker) writes: > Would that it were so simple. First, though, let's simplify it by dropping > all of the line-by-line printing support, so that all we have is Printer > Controller Mode. If an application sends an entire page (or document) > in one invocation of printer controller mode, life is fine (this is, in > fact, what my implementation does). However, there are a number of > applications that toggle into and out of printer controller mode, thus > giving the user such interesting effects as "one line per page," etc. > It all depends on the application. > > Having been in the position of having had to talk to irate customers, I > can assure you that telling them that their VAX software is ill-behaved > is not going to make them any happier :). And of all vendors, Apple is > liable to get the most flak for putting out something that is only partially > functional. I mean, look at this whole discussion :)... I understand what you're saying, I think. Some applications turn print controller on and off several times, without expecting a page termination. The spool print method would force page termination after each turn off. Is that it, or something else? In any event, I still would like to press my 98 per cent point, which is more of a design philosophy and marketing one than a technical one. When faced with a difficulty like this, most of us with our engineering hats on would prefer to hold off until something is perfect. I understand that, -- I catch myself doing it all the time. But in some cases -- and I think this is one of them -- a partial implementation will render a product mainly functional whereas an implementation on hold will render it mainly non-functional. Granted, the functional and nonfunctional designations are a matter of judgment -- presumably there's engineering/marketing folks out there helping to make informed judgments like that. The point I'm trying to make in this thread is that in this case, Apple's judgment to hold off for perfection was well-intentioned but mistaken. At this site, with about 6000 users, less than 20 per cent Mac's and a reasonable chance that Mac's may become standard if things go well, the absence of this feature could significantly sway the acceptance of the machine in a negative direction. It's been suggested to me offline that implementing the simplistic one page spew method of print controller is a mainly if not purely personal concern and that any solution must be more broadly based to be valid. Actually it's a more widely based concern -- cause for sad head-shaking among most of our technical staff and teeth gritting among nearly all users. I have trouble believing that this site is all that unique, but would be glad to hear evidence to the contrary. If you get broiled by 10 per cent for not implementing perfectly, and roasted by 90 per cent for not implementing, which is hotter? I'd like to respectfully attempt to convince Apple to implement a partial solution very rapidly, document the limits, and exchange the liability of a nonprinting product for the liability of a partially printing product with more to come later. Perhaps some market research could resolve the matter in an objective way.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (11/03/90)
>Would it be that much harder to emulate a FX80? >Anything wrong with this idea? Five come to my mind: 1) The program just got bigger. Bigger is buggier. 2) You now need a different driver ON THE MAC for every device you intend to attach to the "terminal". These drivers may be hard to come by (suppose you're driving a plotter, for example). 3) If you have a system that works via pass-through, why put more things in the way? If it ain't broke, don't fix it. 4) Users have an extra step to go through (finding, selecting, and installing the right driver) to use software that JUST WORKS with a real terminal. Very bad politics. 5) Speed, especially on 68000 macs. If the mac can only update a 24x80 72 dpi screen at 9600 baud with difficulty, imagine an 8.5x11 inch 150 dpi printer page. Not fun. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
amanda@visix.com (Amanda Walker) (11/03/90)
In article <-4x2g2.388@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Guess what your VTxxx emulator does? >Right -- it translates bytes into pictures. Right. So does the line printer emulator :). The actual emulation is not the problem... >Would it be that much harder to emulate a FX80? >Emulating a LaserJet would probably be overkill, but while you're at it... ;-) If printer grafports really were just like any other grafports, then this would in fact be the obvious way to do it. This is exactly what the imaging part of the printer emulation does, in fact. However, printer grafports do not necessarily like being open for indefinite periods of time. The print manager also tends to eat memory (especially for a high-resolution Quickdraw printer, for example). This is why all of the methods I listed (except for straight echoing to the serial port) save up the data and then print it in one shot. As I said, it's not the emulation of any particular printer that's hard; it's the strategy for deciding when and how to actually print the page images. >Forgive me if I'm a bit naive here, but wouldn't a customizable timeout and a >menu command and/or alert "print current page now" be sufficient? It would have to be extremely customizable, preferably on a per-application basis. Remember, the goal is to look as much like traditional local printing as possible--that means that always having to pick a menu entry or punch an alert button is a bad thing, as is getting differing output depending on how loaded your host is. Also, people who share a printer over AppleTalk probably don't want to find there printouts interleaved with each other. Once again, document boundaries are significant. The best apporoach I have thought of is to let the user set up what amounts to a simple pattern-based state machine which can decide when to do what. Providing example setups for common cases is probably a good idea, too, so that (for example) the user can pick "VAX running 20/20" and have things work "right." >Anything wrong with this idea? Nothing at all in principle. It's all of the little details that bog things down :). I started with the simple cases and then changed jobs. Apple is no doubt trying to cover more of the possibilities, and is thus taking longer. Note: I'm not trying to defend Apple's development schedule or priorities-- that's their problem. However, I did feel it was worth pointing out some of the not-so-obvious difficulties involved. It isn't quite as simple as it looks... -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- I pray for boredom, but it never comes.
wln@cunixb.cc.columbia.edu (William L Nussbaum) (11/09/90)
In article <ttearnwqqa@visix.com> amanda@visix.com (Amanda Walker) writes: >In article <-4x2g2.388@smurf.sub.org> urlichs@smurf.sub.org >(Matthias Urlichs) writes: >>Guess what your VTxxx emulator does? >>Right -- it translates bytes into pictures. > >Right. So does the line printer emulator :). The actual emulation is not >the problem... > >>Would it be that much harder to emulate a FX80? >>Emulating a LaserJet would probably be overkill, but while you're at it... ;-) > >If printer grafports really were just like any other grafports, then this >would in fact be the obvious way to do it. This is exactly what the >imaging part of the printer emulation does, in fact. However, printer >grafports do not necessarily like being open for indefinite periods of time. >The print manager also tends to eat memory (especially for a high-resolution >Quickdraw printer, for example). This is why all of the methods I listed >(except for straight echoing to the serial port) save up the data and then >print it in one shot. As I said, it's not the emulation of any particular >printer that's hard; it's the strategy for deciding when and how to actually >print the page images. ... Wouldn't it be possible to determine the information needed to prepare a grafport, and then build a PICT or offscreen grafport and subsequently copy that data into a printer grafport? I know it's a little convoluted, but that seems as if it would open and close the printer grafport relatively quickly? | William illiam Lee Nussbaum, Jr. | >> InterNet: wln@cunixb.cc.columbia.edu | >> CompuServe: 72401.3554 (@compuserve.com) | <attach usual non-representation disclaimer>