From: aki@akix.UUCP (Aki Atoji)
Subject: RE: comp.periphs.printers 4697 [long]
Organization: CxS Technologies
Date: Fri, 16 Oct 1992 07:16:49 GMT
	<1992Oct8.174348.29650@microplex.com>
	<1992Oct13.150219.16302@nntpd.lkg.dec.com>

In article <1992Oct13.150219.16302@nntpd.lkg.dec.com> levine@regent.enet.dec.com (Rick LeVine) writes:

>>   PrintServer software is available today for the following platforms:
>>   VMS, ULTRIX, OSF/1, SunOs, and a source kit that will work on 
>>   any BSD system that has real BSD printing implemented.

This sounds great, but just how much is the source kit and the
binaries?
Lpd is well documented, source is readily available and is already in
place on most decent Unix workstatioins.  The user's view would
concern more on commonality of host and printer operation (i.e.  it's
the same from one machine to another), and at the same time, cost.

There is at least one networking printer comany (where I used to work
at, as a matter of fact) who has had non-lpd protocol integrated with
system default print/queueing mechanism on Unix and VMS for years.  It
was not a dual connection protocol, and with only single UDP port, but
it worked well for printing most things, even something with high data
volume like compressed bitmap generated by NewsPrint on the Sun.  The
speed was mostly limited by the raster manipulation speed in the
printer, not by the network nor the protocol.

The caveat is, it costs real money.  Such proprietary protocol (or
anything proprietary for that matter) in general is often viewed by
the selling company as a way to promote the sale of printers (and lock
users into one product line from one company), rather than promoting
the standard to become widely in use by wide variety of systems and
printers for the benefit of end users.  (which lpd has become).  I
would loved to have written printer driver for IBM PC's based on
packet driver for the above mentioned protocol and post it to Usenet,
or write drivers for GhostScript under CopyLeft.  Not that there are
as many of these printers as HPLJ's out there or anything, but alas, I
am bound by NDA, and the general public must go on suffering :)

So what is CPAP going to be in this regard?  Apparently, CPAP is not
going to be a closely guarded proprietary secret, but is it to become
a DEC printer-only thing, or is it to be promoted for free and open
cross-vendor (pr)inter-opertability?

            (Microchannel was a real hit, wasn't it?)

Frankly, if accounting, remote control/monitor and other things
lacking in lpd are an issue, why can't there be a printer control
protocol separate from lpd channel?  This would ensure backward
compatibility with lpd based system.  Also, why not provide a way to
mux this control/monitor protocol with print data stream onto a single
channel for other interfaces such as bi-directional parallel and
serial, if the printer can support it?  (May be CPAP does, I don't
know).  You do not have to have control protocol to print for backward
compatibility, but the user can use it if he/she wishes.

[and now for something completely different.  random thoughts late at
night.]

Why can't the protocol implementation be smart enough to negotiate
transfer method dependent on transfer speed (i.e. if the file is huge
ASCII, why not compress it before sending it down a 9600bps serial
line?  )
Or better yet, what about being able to distribute rasterization
amongst networked printers and host based rasterizers for heavy duty
graphics printing?  Each printer/host can rasterize a strip/page,
compress it, then send it to the destination printer which will simply
print it.  By the time the first page is ready, so are the next 20
pages.

Why not expect something fancy like that from something that costs as
much as a decent workstation?  

And why do people want to print so much anyways?

>>   We arent using a 68000, not by a longshot. We are using a
>>   114mhz S.O.C. (system-on-a-chip VAX 4000 cpu), which is running
>>   a military-specification realtime operating system (please,
>>   no VMS or ULTRIX jokes, ok?) that handles all of the competing
>>   needs of a network printer and applies most of the cpu horsepower
>>   to the top-priority task of imaging the page.

I do remember reading about this quite some time ago, but I do admit
to not being a VAX expert.
But as far as CPU speed goes, my experience suggests that most RISC in
similar configuration with similar clock speed will come out within
close enough range that the difference is obscured by firmware speed
variance.

  (Software types, sit up and take note: It's not the lack of 16MB
   of sub-nano second cache, and it's not the lack of 128-way super-
   duper-pipelined-interleaved-turbo-burst-synchornized-memory 
   that you want on a $500 hardware.  it's *YOUR* dang code)

  (or so I tell myself...)

But the classic CISC vs. RISC argument should stand true reagardless
for general workstations and for printers.  And I'm not about to start
yet another thread on the topic here....  Needless to say, most
workstations which provide best bang for the buck are based on....
Followup on this topic to alt.cpu-wars.  :)

>> ##Don't get me wrong.  DEC certainly has great networking printer
>> ##products that deserve close evaluation for those who are shopping for
>> ##high speed and high volume printing.

>>   Since you posted this publicly, I assume you dont mind if
>>   we quote you?   ;^)

I think you just did :)

For the record, in the 20 and 32ppm duplex networked printer arena,
DEC, QMS, Talaris (use the same engine, in fact) and a few others
all have very decent products.

If anyone is interested in buying such a beast, first see if they do
what *you* want it to do, (if all you want to do is to print gobs of
double sided ASCII accounting report, it doesn't really matter if it
did amazingly fast PostScript or CCITT, does it?)  and see if it does
it well enough for your needs.  Common sense stuff I would do myself
for that kind of money.
-- 
---------------------------------------------------------------------------
Aki Atoji              Unix, X, Networking and Embedded Realtime Consulting
           aki@akix.uucp                      crash!akix!aki@trout.nosc.mil
---------------------------------------------------------------------------