I still think that defining a programmatic way to query the
language level is feasible. The driver developers could come up
with a structure that describes how the language is formatted. But
you are right in that it would be difficult and perhaps error
prone.
We need to define what a language is, first. For PCL (at least the
LaserJet version) and PostScript, it's reasonably well defined, and
generally useful. Probably even for ESCP, although there's the matter
of 9-pin and 24-pin printers. I'm just not sure what good "ESCP/2
Raster" would do as a printer language; it's useless for actually
generating output unless the precise printer model is known.
[glen] Isn=92t the question of =93query the language=94 a question to the=
driver
about the input format the driver accepts? So for PS, PCL, HG/GL this a=
re
input languages that drivers accept; but, ESCP/2 is how the driver talks =
to
the printer not the =93language=94 if accepts (except in pass through mod=
e).
In this context, wouldn=92t the possible range of =93languages=94 be some=
thing
like;
Raw (I assume this means image data of some format)
PS
PCL
HG/GL
HTML
XHTML-Print
IPP
. . . . . .
------------------------------------------------------------------------
> It seems like a weird concept to me. With on-the-fly output
> generation, this can be done with most inkjets, but it still feels
> very strange to me. With laser printers, this doesn't make a whole lot
> of sense at all, and even I have difficulty envisioning a situation
> where this would be useful. In any event, aborting a page is
> something I think we should defer.
Yes. I agree. It was a weird concept for me as well. Which is why
I chose to go with the abort job path.
[glen] I hope you reconsider the abort-page. Example; some print manage=
r
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 proces=
s.
Does the print manager process abort the entire job and restart or does i=
t
abort the current page; wait for the problem to be resolved; then resend
page 200 to complete the job.
[glen] If the driver is managing the entire job =96 it received (or at le=
ast
has means to access) all pages, then an API call for abort-page is not
necessary since processing is done internally.
------------------------------------------------------------------------
But even if we're not talking about a raw file (and I seriously hope
we're not; those things are just too big!), I think we should take a
higher level look at what constitutes a "similar print queue" from the
user's perspective. Suppose I have three printers:
Epson Stylus Photo 780
Canon S800
Epson Stylus C80
Suppose the 780 is down, but there are some (non-raw) files queued for
it. Which printer should they be diverted to? It isn't clear. Most
likely I would want to divert it to the S800 (which is a very high
quality, 6-color photo printer), not to the C80. The reasoning -- and
this cannot be captured by knowing anything about the familial
resemblance -- is that the C80 is a fast 4-color printer, so if I'm
printing to the 780 I'm probably printing a smaller graphic with more
demanding quality requirements.
[glen] I am not sure I understand the group=92s definition of a =93print=
queue=94
. I think of a =93print queue=94 as process that manages a set of simi=
lar
=93printer queues=94. In other words, there can be any number of device=
s
associated with a =93print queue=94. All of those devices have common
capabilities. In this example, the Epson Stylus Photo 780 and Canon S800
belong to the same =93print queue=94 (each printer has their own =93print=
er
queue=94) while the Epson Stylus C80 would belong to a =93print queue=94
consisting of 4-color inkjet printers. The challenge is to define the
classes of =93print queues=94 =96 this may be doable by using the informa=
tion from
[printing-cap] sub-team effort.
Rgds,
Glen W. Petrie
Manager, Software Printing Solutions
Epson Imaging Technology Center
150 River Oaks Parkway, Suite 200
San Jose, CA, 95134
Voice: 408.576.4131 Fax: 408.474.0511
|
