home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!ucbvax!lrw.com!leichter
- From: leichter@lrw.com (Jerry Leichter)
- Newsgroups: comp.os.vms
- Subject: re: Re: How to use a non-DEC postscript printer???
- Message-ID: <9301060244.AA01911@uu3.psi.com>
- Date: 6 Jan 93 01:44:26 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Distribution: world
- Organization: The Internet
- Lines: 79
-
-
- 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? 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,
- the format and meaning of status messages returned by the printer, and so on,
- are NOT standardized - or at least they were not standardized in Version 1 of
- Postscript, for which all of this stuff was built. (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.
-
- >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.) From the "system" point
- of view, Postscript is pretty non-portable; every printer is just a bit
- different.
-
- >DEC is comming out with a new software
- >package which might expand into knowlegde of non-DEC printers,
- >but I haven't seen any promises as to what will be supported.
-
- I just got a blurb on it from the Digital Reference Service, but I
- threw it out after looking it over and not seeing my printer on the
- list. Only a very few non-DEC printers are supported. One is the
- LaserWriter series, which I believe requires custom setup. If any of
- the others are relatively normal beasts, it might be that the new
- software _could_ support them, but if it continues to check for
- specific supported printers and assumes everything else is something
- they know it isn't, then it won't work any better than the current
- stuff. Cute, huh?
-
- 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? What do you do when
- random stuff you don't understand starts coming back from the printer? Just
- what is it you are willing to accept a legal obligation to do with a printer
- you've never heard of? Why would you want to accept ANY legal obligation if
- you are not in a position to test your software first?
-
- ...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.
-
- 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?
- -- Jerry
-
-