From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  6-JAN-1993 02:08:11.86
To:	INFO-VAX@kl.sri.com
CC:	
Subj:	re: Re: How to use a non-DEC postscript printer???

	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