home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20416 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  4.8 KB

  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: How to use a non-DEC postscript printer???
  5. Message-ID: <9301060244.AA01911@uu3.psi.com>
  6. Date: 6 Jan 93 01:44:26 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 79
  11.  
  12.  
  13.     In article <31DEC199209514502@author.gsfc.nasa.gov>,
  14.     rkoehler@author.gsfc.nasa.gov (Bob Koehler) writes:
  15.     >The CPS software inquires from the printer as to what kind of printer
  16.     >it is.  If its not recognized, it assumes DEC LN03R (Scriptprinter), 
  17.     >and utilizes vendor and model specific knowledge in communicating to
  18.     >the "LN03R". Of course, if its not an LN03R, that's likely not to
  19.     >work.  
  20.  
  21.     I always wondered how DEC managed to not support a standard Postscript
  22.     printer.  Thanks for the info. If they weren't trying to lock you into
  23.     their own printers, of course, they'd assume a standard Postscript
  24.     printer if they didn't recognize what they got back. Assuming an LN03R
  25.     is ludicrous, since that is one they WOULD recognize! I wonder what
  26.     marketting guru thought of that little ploy.
  27.  
  28. And just what do you think a standard Postscript printer IS?  Postscript is a
  29. standard with some rather large holes in it.  In particular, such things as
  30. page types and methods of specifying them, control over multiple paper feeds,
  31. setting of persistent parameters and what those persistent parameters are,
  32. the format and meaning of status messages returned by the printer, and so on,
  33. are NOT standardized - or at least they were not standardized in Version 1 of
  34. Postscript, for which all of this stuff was built.  (Take a look at the Post-
  35. script Language Reference - all of this stuff is in an appendix describing the
  36. Apple LaserWriter, and the book is quite explicit in saying that what that
  37. appendix describes applies ONLY to the LaserWriter.
  38.  
  39. >From the point of view of an "end user", who is only concerned with setting
  40. text and drawing pictures, Postscript is reasonably portable.  (Well, even
  41. that's too strong - in my experience, perhaps 30% of the Postscript files I
  42. pull of the net, which the providers insist print just fine on their printers,
  43. cannot be printed on a HP IIISi with Postscript, driven by Adobe's latest and
  44. greatest software for Suns, that I have access to.)  From the "system" point
  45. of view, Postscript is pretty non-portable; every printer is just a bit
  46. different.
  47.  
  48.     >DEC is comming out with a new software
  49.     >package which might expand into knowlegde of non-DEC printers,
  50.     >but I haven't seen any promises as to what will be supported.
  51.  
  52.     I just got a blurb on it from the Digital Reference Service, but I
  53.     threw it out after looking it over and not seeing my printer on the
  54.     list. Only a very few non-DEC printers are supported. One is the
  55.     LaserWriter series, which I believe requires custom setup. If any of
  56.     the others are relatively normal beasts, it might be that the new
  57.     software _could_ support them, but if it continues to check for
  58.     specific supported printers and assumes everything else is something
  59.     they know it isn't, then it won't work any better than the current
  60.     stuff. Cute, huh?
  61.  
  62. Unfortunately, there is no way of determining if a new printer you've never
  63. heard of provides the same interface as you've already written code to
  64. support.  Just what particular interface do you assume?  What do you do when
  65. random stuff you don't understand starts coming back from the printer?  Just
  66. what is it you are willing to accept a legal obligation to do with a printer
  67. you've never heard of?  Why would you want to accept ANY legal obligation if
  68. you are not in a position to test your software first?
  69.  
  70.     ...I've always thought it was stupid how DEC will go to great lengths
  71.     not to support something not on their list, when letting it work would
  72.     be easier (modem support for DSNlink springs immediately to mind).
  73.     Account control is the only possible motivation for this.
  74.  
  75. That certainly plays some role.  Supportability in the field is another.
  76. DEC's code has bugs just like everyone else's, but DEC has always been extra
  77. careful about delineating and documenting what it pledges will work, and what
  78. it considers unsupported.  Before making something "official", DEC wants to
  79. test it.
  80.  
  81. I'm not going to tell you that DEC is all sweetness and light, but I can speak
  82. from experience, a number of years back, in DEC's terminals group.  We were
  83. VERY careful to define just what it was we expected hardware and software to
  84. do.  In fact, when there were proposals to emulate various 3rd-party terminals
  85. on DEC terminals, something the marketing people at one point tried very hard
  86. to get, one of the strong TECHNICAL objections was that no complete spec of
  87. what those 3rd-party terminals did existed.  How could we determine if we'd
  88. built a correct emulation?
  89.                             -- Jerry
  90.  
  91.