[Printing-architecture] FSG Printer Working Group meeting notes 03/26/03

[Printing-architecture] FSG Printer Working Group meeting notes 03/26/03

[Mark Hamzy]

Attendees:
Mark Hamzy
Charles Hemstreet
Norm Jacobs
Till Kamppeter
Ira McDonald
Glen Petrie
David Suffield

Meeting notes:

> * should printer drivers implement a required set of common job
properties (JP)?
>   Examples of keys would be: orientation, form, tray, media, duplex,
resolution.

Yes. We talked about two examples.

   resolution
      integerXinteger
   quality (level of effort in a print job)
      draft, normal, presentation, high, etc...

Future issues are:
   * should we allow structured JPs?  That is, a complex JP that binds two
or more
     simple JPs in it.  Ex:  form, tray, and media could be combined into
one JP.
     We could also have extra informational data in the JP value.  Ex:  the
form
     key could have data that describes if it is installed in the printer.
On a
     query return forms = "letter_installed, legal_notinstalled, ..." and
on a set
     only look at the first part.  This of course would require the driver
to
     hold/fail a job that does not have a form installed in the printer.

>   + Should we use
>        - one existing standard
>           PWG well known values
(http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
>        - two or more existing standards
>           PWG and/or JDF
>        - a new standard

One standard.

>   + is support of the FSG's Job Ticket (JT) standard a requirement?

Yes.  Supporting the key=values from the JT is a requirement.  This would
lead us to
consider the JT keys and values as the standard to use.  We need to make
sure that
all printer drivers have either a mapping from their old keys/values to the
new
JT keys/values or have their keys and values added to the JT standard.

In the future we may want to support JT better by allowing printing of a
job
with just the JT.

> * should all JPs be passed in one call or only one JP for each call
>   (requiring multiple calls to a driver)?

One worry is size of data if all are passed in at once.  One solution that
is
proposed is to query the driver for the number of key/values that can be
passed
in one call.
   PDC                         driver
   PDC queries the driver
   begin JP keys/values     ->
                               driver returns a number which can be the
following
                            <- all
                            <- 1
                            <- number
   PDC sends the key/values
   ...
   PDC notifies the end
   end JP keys/values       ->
                               driver returns success or failure
                            <- success
                            <- failure

In this approach, drivers that need all of the data at once will work and
driver that need only one at a time will work.

> * can there be default job properties or must every property be set?

We decided that default JPs are allowed.  For example, a print job
can be sent with "form=legal" as all of the JPs.

New issues that occurred during the meeting:
   * should there be API to set/query default job properties?

     Yes.

   * should there be multiple named storage areas with default job
properties?

     It should be optional that the default JP set can have a named
storage.

> * should we use a named pipe (or similar) to communicate to a driver or
>   can we use an API?
>
>   + If an API, should that API implement a pipe under the covers?

We decided to use an API.  That API can then use named pipes or some other
communications protocol under the covers.

Future issues are:
   * should we use a structured data message format?

      + should it be
         - XML
         - a simple human readable ASCII string encoding
         - binary
            ~ big-endian/little-endian
            ~ 8-bit clean

      + should it have a length in the structure?

         - 20-octet end-of-string marker instead of sizeof structure

> * should there be different pipes for each print job or should the driver
>   be required to multiplex between the jobs in one pipe?

We decided that supporting different jobs at the same time should be
optional.
   PDC                         driver
   PDC queries the driver
   accept another job       ->
                               driver returns success/failure
                            <- yes
                            <- no

Future issues are:
   - should this be a capability?

> * should there be application presentation information that can be
>   queried?  Some examples are:
>      printable page size
>      resolution
>      current color depth
>      font metrics

Yes.

Future issues are:
   - should there be a driver level of capabilities where an application
can ask
     for a device that supports a certain resolution and page size.  This
could be
     optional.

> * can there be different job properties for each page?
>
>   + Can this can be optional?

Yes.  If a device cannot handle switching job properties on a new page,
then
the driver should stop the print job and start another one.

> * should we allow for future extensibility to support optional components
of
>   a printer driver?

Yes.

>   + vector graphics
>
>     - should we use existing vector language? (SVG, PDF)
>
>     - can it be multiple languages?
>
>     - should we require simulation?
>       That is if a driver only accepts bitmaps, then create a raster
image
>       of the vector commands.  If a driver doesn't support rounded boxes
>       but does support arcs and lines, then break a round box into
>       multiple arc and line calls.
>
>   + device fonts

Unicode font metrics can be a large message.

>
> * should we have an interface to query the printer's job dialog?
>   This will allow for programmatic support of setting/querying the JPs.

Yes.  This should be part of the capabilities.

>      + grouping/structuring
>
>      + constraints
>
>      + type of data (boolean, int, float, string, password, etc)

> * should we require a standard install path?
>   /usr/lib/print/driver/drivername
>   /usr/share/print/font/drivername/

This question was asked because we need some method of detectability or
discoverability of installed drivers.  This can be as simple as an ini file
that is found at a certain location.  This file can contain:
   - what driver is installed
   - where it is located
   - how do I communicate with it

Future issues are:
   - should there be calls to the driver to notify when the driver is
      + installed
      + uninstalled
      + upgraded


Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Printing-architecture] FSG Printer Working Group meeting notes 03/26/03

[Mike Sweet]

Mark Hamzy wrote:
> ...
> Yes. Supporting the key=values from the JT is a requirement. This
> would lead us to consider the JT keys and values as the standard to
> use. We need to make sure that all printer drivers have either a
> mapping from their old keys/values to the new JT keys/values or
 > have their keys and values added to the JT standard.

Better to define a standard mechanism for vendors to add their own
attributes, e.g. com.vendor.attr.

Also, I'm not clear if you are advocating using the subverted IPP
names (e.g. documentFormat instead of document-format?) instead?
If so, that will be a hard sell - we already have to map IPP
attributes to PPD options...

> ...
> One worry is size of data if all are passed in at once.  One
 > solution that is proposed is to query the driver for the number
 > of key/values that can be passed in one call.

I think it will be a lot better to just require drivers accept
data of arbitrary size; drivers can read/process attributes
incrementally on their own, and if a driver only supports a very
small buffer then some attributes may be lost (no way to send a
long attribute if the buffer is too small...)

 > ...
> New issues that occurred during the meeting:
>    * should there be API to set/query default job properties?
> 
>      Yes.

papiPrinterQuery() already supports this...

> ...
>    * should we use a structured data message format?
> 
>       + should it be
>          - XML
>          - a simple human readable ASCII string encoding
>          - binary
>             ~ big-endian/little-endian
>             ~ 8-bit clean
> 
>       + should it have a length in the structure?
> 
>          - 20-octet end-of-string marker instead of sizeof structure

PAPI defines a format for ASCII attributes; from the standpoint of
passing command-line arguments, etc., using this format would make
sense, and it maps cleanly to XML and/or IPP data streams.

> ...
>>* can there be different job properties for each page?
>>
>>  + Can this can be optional?
> 
> 
> Yes.  If a device cannot handle switching job properties on a new page,
> then
> the driver should stop the print job and start another one.

Note: this MUST be transparent to the print system and application,
so in the end per-page properties are not optional, and the driver
MUST support per-page properties by starting a new job.

> ...
> Unicode font metrics can be a large message.

It might be useful to include the range of interest, e.g. "give me
font metrics for chars 0 to 255".

> ...
>>* should we require a standard install path?
>>  /usr/lib/print/driver/drivername
>>  /usr/share/print/font/drivername/
> 
> 
> This question was asked because we need some method of detectability or
> discoverability of installed drivers.  This can be as simple as an ini file
> that is found at a certain location.  This file can contain:
>    - what driver is installed
>    - where it is located
>    - how do I communicate with it

As I mentioned before, a better interface would be to provide a
standard command that can be used to install one or more printer
drivers in a standard format; this command would then handle the
printing system specific installation stuff.

> Future issues are:
>    - should there be calls to the driver to notify when the driver is
>       + installed
>       + uninstalled
>       + upgraded

Aside from actual installation/removal/upgrade of the software
itself, there could also be an issue with initial device
configuration when the printer is connected and queue is setup
for the printing system (e.g. for CUPS to query the printer and
update the PPD file for installed options...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com