Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcsun!cernvax!pan!jw
From: jw@pan.UUCP (Jamie Watson)
Newsgroups: comp.sys.ibm.pc.rt
Subject: LaserJet print queue backend for AIX
Message-ID: <564@pan.UUCP>
Date: 4 Sep 89 20:34:04 GMT
Reply-To: jw@pan.UUCP (Jamie Watson)
Organization: Adasoft AG, Solothurn, Switzerland
Lines: 71


Following this article I am posting a print queue backend specifically
for the HP LaserJet printer.  The following are some notes I made while
writing and testing the program.

- I implemented this backend using an Oki Laserline-6 with a LaserJet+
  emulation cartridge for testing.  We do not have any genuine LaserJet
  printers, and I am not sure what differences there are between the
  Oki emulation and the real LaserJet.  I strongly suspect that things
  like which fonts are built-in are different; there may well be other,
  more significant differences.

- The command line "-debug" flag puts the LaserJet in display mode, and
  turns on lf/cr mapping and end of line wrap.  When things go wrong in
  the output, this makes it easy to see what is really being sent.

- After considerable struggling, I chose to put the AIX lp device driver
  in plot mode and leave it that way.  This disables all special functions
  in the driver.  There are a number of problems in trying to actually use
  the special functions of the AIX lp device driver, including:

  . In cooked mode, the device driver counts characters in escape
    sequences as part of an output line.  So the driver has to be
    in plot mode whenever escape or control sequences are sent.

  . Both the device driver and the LaserJet know how to do line
    wrap and trucation, page feeds when pages are full, and indent.
    Trying to keep the two of them in sync is a royal pain.

  . There are only two functions in the device driver which aren't
    in the LaserJet itself - tab expansion and lower to upper case
    mapping.  There are utilities to perform the former on Unix,
    and I am not interested in the latter.

- In implementing command line options, I have tried very hard to use the
  same options that the AIX "piobe" backend uses.  Obviously, this was not
  possible in every case.

- I have implemented every option the in the Oki interface manual which
  seems remotely useful.  This means that there are a lot of options in
  this program which are not likely to be used; well, I suppose it is
  better to have too many options than not to have the one you need.
  It also means that you can give bizarre combinations of options on the
  command line which will probably not produce the output expected.  Well,
  that's the way the LaserJet commands are...

- There are at least two obvious ways to handle the numerous escape
  sequences that need to be sent to the printer.  I chose to keep the
  sequence for each operation pretty much separate from all others.
  The alternative is to combine sequences which have the same opening
  characters.  My approach produces a program with *lots* of repetition
  in escape sequences.  The alternative produces a program with *lots*
  of conditional evaluation (?:) operations.  Given that the speed of
  the printer is certain to be the significant factor in the use of
  this program, the two approaches seem equal to me.

- The statusfile updating calls only set the percentage finished of the
  job.  I couldn't see a reasonable way to count pages output in an
  arbitrary file which might contain massive amounts of data for font
  downloading, and very little actual data for printing.

- I made mo attempt to implement job cost accounting, again because I
  couldn't see a rational way to do so.

- The font selection flag (-fid=num) seems totally bogus to me, because
  the program has to have an explicit, built-in, knowledge of every font
  that is to be made available this way.  However, the AIX piobe program
  has this flag, and it does provide considerable convenience in font
  selection for those fonts it knows about.

jw