[Printing-architecture] Re: [printing-driver] More Vector Driver questions and Job

Mon Apr 19 15:49:24 PDT 2004

Glen,

Great!  Job properties and capabilities now - the term usage isn't being
interchanged is it?

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.

      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).

      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?  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.

      4. Is anyone working on having a multipass renderer so that graphics
and text can be drawn on the same page?

      5. Is this APIEntry table on startjob for passing in 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