From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 6-JAN-1993 12:11:17.47 To: info-vax@kl.sri.com CC: Subj: re: Re: How to use a non-DEC postscript printer?? [I wrote the indented part that is single quoted, Jerry wrote the non-indented part that is single quoted. Jerry's reply only went to comp.os.vms because he's on the info-vax mailing list, so I'm quoting his entire article (with my comments inserted) for the benefit of the people in the other groups this was posted to. --tp ] In article <9301060244.AA01911@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes: > > > In article <31DEC199209514502@author.gsfc.nasa.gov>, > rkoehler@author.gsfc.nasa.gov (Bob Koehler) writes: > >The CPS software inquires from the printer as to what kind of printer > >it is. If its not recognized, it assumes DEC LN03R (Scriptprinter), > >and utilizes vendor and model specific knowledge in communicating to > >the "LN03R". Of course, if its not an LN03R, that's likely not to > >work. > > I always wondered how DEC managed to not support a standard Postscript > printer. Thanks for the info. If they weren't trying to lock you into > their own printers, of course, they'd assume a standard Postscript > printer if they didn't recognize what they got back. Assuming an LN03R > is ludicrous, since that is one they WOULD recognize! I wonder what > marketting guru thought of that little ploy. > >And just what do you think a standard Postscript printer IS? OK, I should have said "generic" instead of standard". >Postscript is a >standard with some rather large holes in it. In particular, such things as >page types and methods of specifying them, control over multiple paper feeds, >setting of persistent parameters and what those persistent parameters are, There is no reason the controlling software has to know these things. It should offer base level functionality for a generic printer. In such a case, it would believe the queue characteristics as to the page size for laying out ascii text, and would offer no control of paper trays or fancy options such as duplex, stapling, etc., except by having a mechanism to allow embedded postscript to be passed through to let the user do it. It should leave persistent parameters alone completely. Scriptserver manages to do these things rather well, so I can't believe DEC couldn't. They support a large list of printers, and I believe most of them on the list are simply those that run standard Adobe interpreters. You build a test suite, run it on the printer, and if it works, it's supported. Or (he says, in a flash of inspiration :-]) one could look these up in a Postscript Printer Description (PPD) file, which defines how to do all these things you are worried about and thus provides full functionality! It even gives you the PS code to use to query the printer to find out what you need to know, and the code to activate the various features. Thus, DEC could support any printer with 2 caveats: the user must provide a PPD file if it isn't included in the set DEC would ship, and only capabilities described in the PPD file are supported. Furthermore, that support wouldn't have to be hard-coded and system specific. I guess a further caveat would be that it support a standard serial (or other specific) interface. But again, ScriptServer manages to do quite well without PPD files (though it doesn't offer some features it could if it did use them). >the format and meaning of status messages returned by the printer, and so on, Assume the format returned by Adobe interpreters. If they've changed the format over time, support them all. For that matter, unless it is doing a query, simply return anything coming back from the printer as an error. I think the only one ScriptServer actually understands is the flushing to end of job error, and you could get away without that one. If the printer sends a different message, you just end up sending the rest of the file needlessly. Of course, you could allow the system manager to define the flush message text. Or, once again, you could use PPD files, which do define the error messages. >are NOT standardized - or at least they were not standardized in Version 1 of >Postscript, for which all of this stuff was built. They are not standard, but they are common. Adobe's approach to printer support is to make common features the same on all printers. Which features are available may vary from printer to printer, but if the feature is available, it is generally accessed in the same way. PPD files are standardized, and Adobe maintains an archive of them for lots of printers. They are available on the net via a mail server, and I think Adobe or the developer's association will make the available on floppy as well. >(Take a look at the Post- >script Language Reference - all of this stuff is in an appendix describing the >Apple LaserWriter, and the book is quite explicit in saying that what that >appendix describes applies ONLY to the LaserWriter. But most printers with similar features are compatible. I seem to recall it specifically mentions the few things that are only applicable to the LW, but I'm not certain. >From the point of view of an "end user", who is only concerned with setting >text and drawing pictures, Postscript is reasonably portable. (Well, even >that's too strong - in my experience, perhaps 30% of the Postscript files I >pull of the net, which the providers insist print just fine on their printers, >cannot be printed on a HP IIISi with Postscript, driven by Adobe's latest and >greatest software for Suns, that I have access to.) And usually, this has one of 3 causes: 1) the file is defined for a page size (e.g. a european size) that your printer doesn't support, 2) the file needs a font you don't have, or 3) the file is produced by some PC or MAC application that assumes a standard prologue file, but doesn't put it in the postscript file because it assumes it has been permanently downloaded to the printer, or because it assumes that the application itself will be used to print the file, and it will send the prologue to the printer at that time. #1 is a problem that I don't know a lot about, although I've been able from time to time to simply edit the postscript and change the page size to get it to work (and if the margins didn't make it fit, put in a scale command to get the image to the right size). #2 is pretty much make or break for a carefully laid out document, since each font has different metrics. If you don't have the font, doing an adequate substitution would be difficult. #3 is a user error. The user has produced a platform specific file. If he's going to release it to the net, he should ensure all required prolog files are in the file. That includes apple's laserprep, or whatever. (ScriptServer comes with a small number of these standard prologs, and you can use these as form queue setup files so you can define a queue to print things that need laserprep, or whatever.) >From the "system" point >of view, Postscript is pretty non-portable; every printer is just a bit >different. Not for basic functionality. For accessing things like papertrays, etc, sure. Just leave that to the user to do in his Postscript or by embedding PS in his ascii file. Why is it considered "bad" to support a printer with less than total functionality? >Unfortunately, there is no way of determining if a new printer you've never >heard of provides the same interface as you've already written code to >support. Just what particular interface do you assume? Bi-directional serial (RS-232). >What do you do when >random stuff you don't understand starts coming back from the printer? Print it for the user. >Just >what is it you are willing to accept a legal obligation to do with a printer >you've never heard of? Most DEC software disclaims any legal obligation to do anything. Simply describe the generic printer and say any printer matching those characteristics is supported. The rest aren't. >Why would you want to accept ANY legal obligation if >you are not in a position to test your software first? So test them. Write a generic printer support module, build a test suite, and run 'em through. I believe ScriptServer supports over 3 dozen printers. > ...I've always thought it was stupid how DEC will go to great lengths > not to support something not on their list, when letting it work would > be easier (modem support for DSNlink springs immediately to mind). > Account control is the only possible motivation for this. > >That certainly plays some role. Supportability in the field is another. >DEC's code has bugs just like everyone else's, but DEC has always been extra >careful about delineating and documenting what it pledges will work, and what >it considers unsupported. Before making something "official", DEC wants to >test it. Fine. But they go out of their way to ensure that something that is not officially supported will not work. ScriptServer will support any reasonable PS printer, not just those on a list. DEC ensures that it will not support any printer but those on its list. Similarly, most modem communications software will support any modem with an AT command interface, whereas DEC ensures that DSNlink only works with a specific one. This is product lock-in, pure and simple. >I'm not going to tell you that DEC is all sweetness and light, but I can speak >from experience, a number of years back, in DEC's terminals group. We were >VERY careful to define just what it was we expected hardware and software to >do. In fact, when there were proposals to emulate various 3rd-party terminals >on DEC terminals, something the marketing people at one point tried very hard >to get, one of the strong TECHNICAL objections was that no complete spec of >what those 3rd-party terminals did existed. How could we determine if we'd >built a correct emulation? The PPD file for a printer, plus the PPD spec, provides a complete spec for the behavior of any printer for which a PPD file exists. Further more, the PPD file is machine parseable. Thus your analogy doesn't hold. Complete specs exist for most Postscript printers. But aside from that, most of them are very similar in the most important ways anyway. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA