[printing-discuss] RE: [printing-driver] proposal of what features the communication toaprinter driver should support

[Glen Petrie]

> [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] Ops... got carried away...
> [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]   Isn't restarting a job at a certain page more overhead for the
print manager process than just stopping and sending the page in
error/question.  And actually, to the driver the "restart job at a certain
page" is just a new job (with less pages) since, based on the comment below,
the driver never sees the entire job.    So this approach is supported by
virtue of executing another job.
> [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]  This is my understanding also.

> [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.
[glen] I guess I don't normally consider the connection (physical port) as
the discriminator for printer selection based on job properties.   I must
have a different conceptual model of job-queues, print-queues,
printer-queues and where drivers fit in.   I will reexamine the notes from
the summit meeting.


Mark

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