[Omniprint-user] RE: [printing-driver] proposal of what features the communication to aprinter driver should support

[Mark H. <ha...@us...>]

Hi Glen,

> [glen] Isn't the question of "query the language" a question to the
driver
> about the input format the driver accepts?   So for PS, PCL, HG/GL this
are
> input languages that drivers accept; but, ESCP/2 is how the driver talks
to
> the printer not the "language" if accepts (except in pass through mode).
> In this context, wouldn't the possible range of "languages" be something
> like;
>
> Raw (I assume this means image data of some format)
> PS
> PCL
> HG/GL
> HTML
> XHTML-Print
> IPP

What I was talking about was the output language that the printer driver
uses.  But, yes, you do need both input and output languages.
I think that a driver cannot support input languages such as PS, PCL (which
has mulitple variants), and HP/GL without a helper program (such as
Ghostscript in the case of PS).
By the way, IPP is a protocol.

> [glen] I hope you reconsider the abort-page.   Example; some print
manager
> process has defined a 200 page job and began a session with the driver.
> The driver has accepted the job, printed 199 pages and start page 200.
> The toner (ink, whatever) is reported out (or the paper is out) via the
> status/monitoring I/O channel from the driver to the print manager
process.
> Does the print manager process abort the entire job and restart or does
it
> abort the current page; wait for the problem to be resolved; then resend
> page 200 to complete the job.

Actually, for out of ink or out of paper scenarios, you do not abort the
job at all.  The printer is usually offline in those cases.  How about
the ability to restart a job at a certain page?  I haven't come across
a printer command that aborts a page, but I don't see the problem in
providing both the ability to abort a job and abort a page.

> [glen] If the driver is managing the entire job - it received (or at
> least has means to access) all pages, then an API call for abort-page
> is not necessary since processing is done internally.

Well, every printer driver that I have seen is transitory.  At most, it
will have access to the current band or the current page.  Only if it
supports a high-end laserjet that has a disk drive could it see previous
pages.

> [glen]  I am not sure I understand the group's definition of a "print
> queue".    I think of a "print queue" as process that manages a set of
> similar "printer queues".   In other words, there can be any number of
> devices associated with a "print queue".  All of those devices have
> common capabilities.  In this example, the Epson Stylus Photo 780 and
> Canon S800 belong to the same "print queue" (each printer has their own
> "printer queue") while the Epson Stylus C80 would belong to a "print
> queue" consisting of 4-color inkjet printers.    The challenge is to
> define the classes of "print queues" - this may be doable by using the
> information from [printing-cap] sub-team effort.

Well, my definition of a print queue is a construct that allows multiple
print jobs to spool to one physical port (such as LPT1).  Since job
properties can be associated with a queue, you don't want different
drivers or devices on the same queue because they wont understand the
differences between the properties.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/