[Printing-architecture] RE: [printing-driver] More Vector Driver
questions and Job
Petrie, Glen
glen.petrie at eitc.epson.com
Tue Apr 20 08:35:21 PDT 2004
[[ GWP ]] The two issues I addressed in the email were about multiple job
capability for the driver and having User settable printer capabilities. I
strongly support having multiple job capability and would the API to be
adapted to support this. As for User selectable printer capabilities I
wrote the email in response to this capability brought up in the driver
meeting. My support for this will be based on the feedback from these
emails. Actually, I currently see the printer capability as fixed (by the
PPD or UPDF or ???) and not having any User selection. If there are
differing printer capabilities shouldn't there be separate descriptors! But
I would like to hear other individual's opinions.
[[GWP]] Let me also state that I strongly believe any vector driver library
conforming to the specification required to be fully supported all of vector
driver API's. It is up to the individual vector driver library to "figure
out" how to execute each API call not do a selected few. Otherwise it
leaves the responsibility to a higher level process to determine how and
to-do part of the vector rendering. This places a requirement that there
be a higher level renderer process to support vector printing; why? This
seems to complicate the situation - it could mean a generic higher level
renderer would have to, in theory, support all of the vector driver API's!
Looks like when you combine the job properties function and the vector
work, the group is getting around to driver enablement and sets. This now
brings up a few questions:
1. So at what point is the driver going to be told about the
properties of the job/page? I see mention of "start job" vs openprinter
below but I am not clear on which is better and why. It would probably be
nice to set an initial state on the printer at the beginning and then just
send a modification on a per page basis if things change so I could see
job/page properties used in multiple places. Of course the current state
would need to be able to be queried so the information would have to update
a context for the device.
[[ GWP ]] To support multiple documents along with document and page
exceptions the driver could be told about "job/doc/page properties" at
various times in processing a job. (I am assuming the driver does not
decompose a job-ticket.) Job properties could be initially set at "start
job" via one call or through a set of individual calls. After startDoc and
before startpage overrides via one or more set-functions (doc/page
properties) may occur. This is why I am not in favor of changing the printer
capability inside of a job. But if changing printer capability and APIEntry
is necessary, then the setprintercapabilities could be called before
startjob and before startdoc - even before startpage if that was desired.
Each call to setprintercapabilities would return the APIEntry.
2. Does this mean the print driver will be able to hook out (replace
function pointers) whatever drawing commands it wants to as it does now in
Ghostscript and Win? (it seems implied by the PCL2 vs PCL5 reference
below).
[[ GWP ]] Yes, this is the request within the driver group.
3. Is this being worked from the vector/renderer side so that you can
replace functions and handle the vector commands directly in the driver
without requiring rendering to be done?
[[ GWP ]] Yes. If the vector driver cannot handle specific functions then
it will need an assist for a higher level module or a separate renderer.
You would probably want to have
all the drawing commands go through an intermediate layer so the proper
path can be taken based on the capabilities and job properties.
[[ GWP ]] I am sure I understand your comment completely. If you mean that
some process must "understand" the entire vector driver API then I concur.
See my comment at the above
4. Is anyone working on having a multipass renderer so that graphics
and text can be drawn on the same page?
[[ GWP ]] No that I am aware of.
5. Is this APIEntry table on startjob for passing in a table of
functions?
[[ GWP ]] It for passing "out" a table of functions.
I apologize for needing clarification since I have not been in on the later
phone calls.
Thanks,
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan at us.ibm.com
"Petrie, Glen"
<glen.petrie at eitc
.epson.com> To
Sent by: printing-japan at freestandards.org,
printing-driver-b printing-architecture at freestandards
ounces at base3.free .org,
standards.org printing-driver at freestandards.org
cc
"Petrie, Glen"
04/19/2004 03:12 <glen.petrie at eitc.epson.com>
PM Subject
[printing-driver] More Vector
Driver questions and Job
Please respond to
Discussion for
the driver API
subgroup
Hello,
The USdriver team discussed the possibility of having the driver supporting
multiple jobs; the idea was ok with the condition that the driver is only
required to support at most one job. However, it still means changes to
the current API. Supporting multiple jobs makes the overall driver API
more generic and provides for greater integration configurations. But
there are issues with the current design.
The API needs to have some changes starting from the very first Library
call; OpenPrinter. Currently, in the call the printer model is specified.
For a multiple job configuration this would have to be done at the "start
job" API. However, this can reduce the "dynamics" of the APIEntry feature
since the printer would not be know at library initialization; instead
would be know at "start job" API. One solution is to have a fixed set of
API that a driver must support; that should be straight forward. This way
at library initialization, certain critical functions must be supported.
Does this mean moving the return for "optional" APIEntry table to "start
job". Maybe Yes, Maybe No.
1.) First the driver "query device capability" and "query device info" API
would have to be callable before setting/starting a job. This means that
the "printer model" be added to their argument list. - That easy solved.
Now the capability is called after the library is initialized but before
calling "start job".
2.) The APIEntry changes based on the printer type and its capability. It
has been argued that User or other determining body may want to change the
basic printer capability. For example, the printer language; if the
printer supports PCL2 and PCL5 and this may be a settable option. This
"basic printer property" selection differs from selection from selection we
do in a job-ticket. It is giving the User selection over printer
capabilities. To support this kind of selection, we would need a new API
called "set printer capabilities". The driver, generically, remembers the
set printer capabilities and when start job is called with printer name it
will use the settings.
If both 1.) and 2.) are implemented then greater dynamics of the APIEntry
is possible.
I really don't think "start job" is the best place for the APIEntry's to be
returned; but for now it a starting point for discussion.
Rgds,
Glen W. Petrie
Epson Imaging Technology Center
150 River Oaks Parkway, Suite 200
San Jose, CA, 95134
Voice: 408.576.4131 Fax: 408.474.0511
_______________________________________________
printing-driver mailing list
printing-driver at mail.freestandards.org
http://mail.freestandards.org/mailman/listinfo/printing-driver
More information about the Printing-architecture
mailing list