NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/vmsnet/misc/1100

Internet Message Format | 1993-01-06 | 10.7 KB

Xref: sparky vmsnet.misc:1100 vmsnet.networks.desktop.pathworks:3937 comp.os.vms:20437
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!mccall!mccall!tp
Newsgroups: vmsnet.misc,vmsnet.networks.desktop.pathworks,comp.os.vms
Subject: re: Re: How to use a non-DEC postscript printer??
Message-ID: <[e-mail]>
From: [e-mail] (Terry Poot)
Date: Wed,  6 Jan 1993 07:35:52 CST
Reply-To: [e-mail] (Terry Poot)
References: <[e-mail]>
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-Host: mis1
Nntp-Posting-User: tp
Lines: 188


[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 <[e-mail]>, [e-mail] (Jerry Leichter)
writes:
>
>
>    In article <[e-mail]>,
>    [e-mail] (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 <[e-mail]>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
[phone], in KS [phone]           Manhattan, KS 66502, USA