[Libaps-general] Common printer configuration storage

[Jeff B. <kl...@ma...>]

From: "Jeff Brown" <jef...@co...>
Subject: Common printer configuration storage
Date: Friday, February 18, 2000 5:29 pm

Hello everyone,

Since a significant part of the new APS involves installation and
configuration of printers, it makes sense for these things to become
externally visible to the system in some pre-defined standard way.  However
this is a non-trivial matter as APS must be made to communicate with MANY
different potential underlying transports.  Therefore APS may need to
provide information in many different forms to satisfy each...

... or it may not.  It may simply write out configuration information in
some standard form to a directory under /etc/.  That way all of the
information is available, not just the subset that may or may not be
understood by a given transport.  This also gives us a great place to store
any configuration elements that would be processed by APS internally (like
translations of various types, header page creation, accounting and logging,
etc...)

Assuming APS gets a common repository for printer configuration information,
then what?

Well... should APS be told to use that information exclusively, or should
the user be able to indicate that he/she wants APS to be "friendly" to some
other installed print system.  This brings about several possible
behaviours:
  1. APS uses its internal records exclusively and verifies/regenerates
configuration files for subordinate transports
  2. APS stores everything it knows in its internal records but allows the
user to choose one of the following:
     a. work blindly (do not verify external configuration files)
     b. check for inconsistencies, and import any differences
     c. check for inconsistencies, and report any differences
     d. as with 'c' but grant the user the option of importing differences,
ignoring them, or obliterating them.

As for why this is necessary, consider the case of the print filters.
For LPR, APS knows many things the transport does not, and could not ever
hope to know, namely, what KIND of printer is attached, and HOW to
communicate with it (what driver).  APS therefore needs to get in the middle
somehow and either intercept traffic before it enters the transport, or
after it exits but before it reaches the printer.  The most flexible option
is to intercept traffic just before it gets sent to the printer, and
thankfully, this is a simple task: you just set up a print filter.

Under LPR (and in most other cases), the transport receives data blindly...
eg. in some arbitrary format.  It does not may any attempt to format it for
the printer, nor should it, as its sole purpose is to pass what it receives
down the pipe.  For the user's benefit, however, APS has to get in there and
make sure that all it well and that you're not trying to do anything stupid
like print postscript to a non-postscript printer, or print a JPEG file
without first translating that into the a representation that the printer
can understand.  APS depends on filters inserted into the output stream to
perform all of the necessary translations on behalf of the user.  However
doing so requires knowledge of what kind of printer you have, what it
understands, what paper sizes it handles, how it should do colour
correction, dithering, downsampling or upsampling, and what drivers exist to
help us out.

Ideally, a filter should be provided with a single parameter: What printer
am I?  It should then look up in the APS database to find out anything else
it needs.  First it should pass the data through a common filter script used
by APS to convert the source data to a common representation (Postscript
seems like a good idea).  Then it should use another common APS script to
perform the other required transformations.  Finally it should take the
output and send it to the correct driver for printing... As this step may
vary from transport to transport, it is unwise for it to be accomplished by
a common APS script and should really be done on a per-transport basis.

Sorry... I have to run to catch a train!
Thoughts anyone?

Jeff Brown. (x5625)


From: "Brian Pirie" <br...@co...>
Subject: Re: Common printer configuration storage
Date: Tuesday, February 22, 2000 12:23 pm

Hi Jeff,

This issue is the programming work that I've been looking at recently. The
basic
mechanism is to create a per-printer configuration file, with per-user and
system-wide copies. This allows for individual user configuration of their
printing preferences without affecting other users, while also allowing the
sysadmin to do machine-wide configuration.

(I know that I haven't responded to each individual issues raised in your
posting, but I hope to talk about your ideas in more detail when I can give
this
the attention it deserves.)

Brian