Thanks for your reply, but

actually, because we have to load special paper (letterhead or prepunch)
BACKWARD to make normally-sequenced (read un-windows-driver-cheated) page 2
end up on the reverse side of the paper (because the printer itself prints
duplex backward in order to meet throughput specs), configing the tray does
no good at all - it just lets a Windows job screw up by assuming it's
supposed to do its cheat.  (confusing, isn't it?!)

The way we really do it is:

1) load the paper backward.  from the operator's point of view, clearly
wrong.
2) from the e3k fregzample, specify duplex via environment file, let fly.
the combined backward paper and the printer's cheat produce joy.
3) from Windoze, request special paper, let the driver do its shuffle thing.
the printer, NOT knowing it has special paper, pauses to request it.  In
response, put the paper in the tray correctly, and tell the printer to use
that tray / papertype INSTEAD of the requested papertype, let the printer do
ITS cheat, and again we have joy.

all solved, eh?  nope: the next 'natural sequence' job, coming from the e3k
fregzample, goes onto the paper backward because the paper's loaded
correctly!  so we get around that by telling the printer that its trays hold
paper no one here would ever request!

The solution?  Use somebody else's printers that don't cheat to meet
throughput specs and require cheating by the driver.  Too late, we already
bought this one!  So now we need either

a) an e3k spooler that knows it's supposed to shuffle the pages for cheating
hp printers doing duplex, effectively an MPE PCL6 driver for a 9000 (yes
it's an hp printer), and a PCL5e driver for 5skMX and 8100, and a whole new
set of programs designed to not know where the output's headed.

b) don't know if it's possible, but maybe we could write a smart environment
file which would cause the printer to do the Windoze driver cheat.

It all really boils down to "to get proper output from the printer, you have
to know the printer before you create its data stream".  Windows handles
that reasonably well via drivers.  Other OSes such as UX & MPE don't do so
well - the data stream's built with some, but not nearly enough, knowledge
of its destination.  Moving an mpe spoofle from one printer to another's a
piece of cake, but it's already too late to rearrange the data.


Again Thanks much for your reply, but

1) the original question was "where do I (John Pitman) find docs re the
escape sequences used to specify a papertype?", asked because specifying
trays is fraught with problems.  My now-very-long response to that was
briefly "hp doesn't want you to find them - you'll discover that the
hardware doesn't work right.  instead they want you to use the Windows
driver, hoping they'll get away without the 'broken!' label on the box".

2) The response _I_ seek is to...
>> <snip>
>> *correct me please someone?  As I understand it, the reason hp appears on
>> virtually all early, and a very good percentage of recent laser printers
>> is not that hp 'invent'ed them, but rather that hp had PCL, a reasonably
>> mature and adaptable language for communicating with Canon's new laser
engine.
>> How the contracts betwixt hp & Canon actually worked, I dunno, but hp won
the
>> big prize, industry 'standard'.  Other than PCL, hp's contribution to the
>> laser printer world is marketing (and of course claimed 100% hp-laserjet
> > compatibility;-)
> >
> > Tracy Pierce

Since I see by your email address that you're Inside HP, you probably
a) know the real skinny on all this and are thus the perfect respondent, and
b) don't dare address it publicly (got a mortgage?).

Hoping b) is wrong,

Tracy (pretty longwinded on this subject!) Pierce

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *