[Printing-architecture] RE:Scenarios for using the various Open Print API

[Printing-architecture] RE:Scenarios for using the various Open Print API

[Claudia Alimpich]

Well, that last note that I sent sure looked bad! Let me try again.

Following is what I came up with for possible scenarios describing how to
use the APIs together. Please provide your comments and any additions. When
it is clean, I will post it to the PWG site.

Claudia Alimpich
alimpich@us.ibm.com
---------------------------------------------------------------------------

21Nov2002

     Using the Application, JTAPI, Capabilities API, PAPI, and Print
Service


Following are scenarios that describe how the various Open Print APIs can
be used (or not used) together:

      1) One of the following:
            a) The Application provides the user with choices that are
                  determined by the application itself.
            b) The Application uses the Capabilities API* to determine
                  the capabilities of the target device(s) and then
                  provides the user with choices.
            c) The Application uses a PPD file to determine the
                  capabilities of the target device.
            d) What other ways can device capabilities be
                  determined?
      2) The user makes selections from the choices.
      3) Optionally, one of the following:
            a) The Application uses the JTAPI to create a job ticket.
            b) The Application sets IPP attributes that describe how the
                  job is to be processed.
            c) Both a) and b).
      4) One of the following:
            a) The Application uses the PAPI to submit the data/content
                  file and the job ticket to the Print Service.
            b) The Application uses the PAPI to submit the data/content
                  file and the IPP  attributes to the Print Service.
            c) The Application uses the PAPI to submit the data/content
                  file, the job ticket, and the IPP attributes to the Print
                  Service.
            d) The Applicaiton saves the job ticket without submitting it
                  or the data/content file to the Print Service.

* Question: Is the Capabilities API part of PAPI or a separate API?

Re: [Printing-architecture] RE:Scenarios for using the various Open Print API

[Michael Sweet]

Claudia Alimpich wrote:
> ...
> * Question: Is the Capabilities API part of PAPI or a separate API?

I think it will be part of PAPI 1.1/2.0 (whatever we end up numbering
it...)

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

Re: [Printing-architecture] RE:Scenarios for using the various Open Print API

[Pete Zannucci]

SORRY - LONG APPEND


In Claudia's note below, she has hit on the gray area.
Do we need a capabilities API or not?

We need to define what "Capabilities" really is and
what is the crossover between capabilities and the
standard attributes that are currently defined in
protocols such as IPP and to be provided by the printer
(or subsystem).

The basic capabilities of a device will be provided back
through the papiPrinterQuery call which will enable printing.
The problem with these attribute/values is that the
information provided back will be non-hardware / rendering
specific.  We should get back the standard IPP information,
at minimum, which provides for things like:
      form
      tray information
      media
      finishing options, etc.

This information formulates the basics of capabilities.
These items will let you send a job and pick certain hardware
features/finishing options but do not provide possible
additional information on how the job can be laid out and
what are possible rendering options based on the hardware's
capabilities.

We need to come to a consensus on what additional types
of information an application might need to be able to
generate a job to it's satisfaction.  We have discussed
how to provide printable area and margin information.
That is a start.  Their may be other things that some apps.
would like to know about a device and that should be added
as a possible separate api (get all the pertinent info.
back from a device on what it supports) or could possibly
be added as an additional grouping of attributes.

There are two sides of adding additional attributes that
worry me.
      1. No protocol support for the attributes so
         current devices will not be able to handle or
         provide the information back on a query.
      2. Since there is no support there will need to be
         an intermediary such as a ppd or a driver when
         using such a device.

In reality most information is provided by the current
set of attributes except for some specific hardware and
rendering information.  We should be able to get that
information based on a current group of settings so that
an application can generate a page correctly.
This could be done with the current attribute mechanism
though we have to make sure that we offset any discrepancies
that a particular implementation (such as IPP or various
other backends) with system specific function to provide
the additional information to the application.



Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com


Claudia Alimpich/Boulder/IBM@IBMUS@freestandards.org on 11/21/2002 01:09:27
PM

Sent by:    printing-architecture-admin@freestandards.org


To:    "printing-architecture" <printing-architecture@freestandards.org>
cc:
Subject:    [Printing-architecture] RE:Scenarios for using the various Open
       Print API



Well, that last note that I sent sure looked bad! Let me try again.

Following is what I came up with for possible scenarios describing how to
use the APIs together. Please provide your comments and any additions. When
it is clean, I will post it to the PWG site.

Claudia Alimpich
alimpich@us.ibm.com
---------------------------------------------------------------------------

21Nov2002

     Using the Application, JTAPI, Capabilities API, PAPI, and Print
Service


Following are scenarios that describe how the various Open Print APIs can
be used (or not used) together:

      1) One of the following:
            a) The Application provides the user with choices that are
                  determined by the application itself.
            b) The Application uses the Capabilities API* to determine
                  the capabilities of the target device(s) and then
                  provides the user with choices.
            c) The Application uses a PPD file to determine the
                  capabilities of the target device.
            d) What other ways can device capabilities be
                  determined?
      2) The user makes selections from the choices.
      3) Optionally, one of the following:
            a) The Application uses the JTAPI to create a job ticket.
            b) The Application sets IPP attributes that describe how the
                  job is to be processed.
            c) Both a) and b).
      4) One of the following:
            a) The Application uses the PAPI to submit the data/content
                  file and the job ticket to the Print Service.
            b) The Application uses the PAPI to submit the data/content
                  file and the IPP  attributes to the Print Service.
            c) The Application uses the PAPI to submit the data/content
                  file, the job ticket, and the IPP attributes to the Print
                  Service.
            d) The Applicaiton saves the job ticket without submitting it
                  or the data/content file to the Print Service.

* Question: Is the Capabilities API part of PAPI or a separate API?







_______________________________________________
Printing-architecture mailing list
Printing-architecture@freestandards.org
 http://freestandards.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] RE:Scenarios for using the various Open Print API

[Michael Sweet]

Pete Zannucci wrote:
> ...
> We need to come to a consensus on what additional types
> of information an application might need to be able to
> generate a job to it's satisfaction.  We have discussed
> how to provide printable area and margin information.
> That is a start.  Their may be other things that some apps.
> would like to know about a device and that should be added
> as a possible separate api (get all the pertinent info.
> back from a device on what it supports) or could possibly
> be added as an additional grouping of attributes.

I'm not sure if the current PWG color attributes cover this,
but providing the native colorspace as well as any profile
information for the printer/driver might be useful.  Right
now all IPP provides is a "color-supported" boolean attribute,
but knowing if the destination device/driver supports true
CMYK/N-color rendering (typically used in a production
workflow with apps like Photoshop, etc.) could be useful.

> There are two sides of adding additional attributes that
> worry me.
>       1. No protocol support for the attributes so
>          current devices will not be able to handle or
>          provide the information back on a query.

Assuming that PAPI is providing the information, it can
supplement the attributes as needed.

>       2. Since there is no support there will need to be
>          an intermediary such as a ppd or a driver when
>          using such a device.

I would say that this will be the case for the forseable
future, and unless printer manufacturers suddenly have a
cheap chipset they can put in their low-end devices, such
support will only ever be available in high-end devices.

In any case, PAPI can handle the low-level details and
provide the app with a common, consistent interface, right?

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

[Printing-architecture] RE:Scenarios for using the various Open Print API

[Claudia Alimpich]

Following is the updated Scenarios that I first put on the forum 21Nov2002.
Tom Hastings provided feedback and additions which I incorporated. There is
still some discussion about Capabilities and what the Application should
call to get device capablilities information. Please review the scenarios
and provide your comments and feedback. I also put this on the pwg site at:

ftp://ftp.pwg.org/pub/pwg/fsg/architecture/LinuxScenarios_16Jan2003.txt

Claudia Alimpich
IBM Printing Systems Division
alimpich@us.ibm.com
-----------------------------------------

16Jan2003

  Using the Application, JTAPI, Capabilities API, PAPI, and Print Service


Following are scenarios that describe how the various Open Print APIs can
be used (or not used) together:

      1) One of the following:
            a) The Application reads a job ticket file, as directed by
                  the user, by using the JTAPI.
            b) The Application reads a default job ticket file, as
                  configured by the administrator, by using the JTAPI.

      2) One of the following:
            a) The Application provides the user with choices that are
                  determined by the application itself.
            b) The Application uses the Capabilities API* to determine
                  the capabilities of the target device(s) and then
                  provides the user with choices.
            c) The Application uses a PPD, GPD, UPDP, or other device
                  description file to determine the capabilities of
                  the target device.
            d) The Application queries the Device using SNMP.
            e) What other ways can device capabilities be
                  determined?

      3) The user makes selections from the choices presented by the
            Application.
            a) The choices presented are limited/constrained by the
                  user's selection of other/related choices.

      4) One of the following:
            a) The Application uses the JTAPI to create a job ticket.
            b) The Application sets IPP attributes that describe how the
                  job is to be processed.
            c) Both a) and b).

      5) Optionally, one of the following:
            a) The Application uses some of the user's selections to
                  generate the data/content file.
            b) The Application uses the Graphics API to generate the
                  data/content file.
            c) The Application uses some of the user's selections to
                  select from among alternate formats of data/content
                  files that have previously been generated and made
                  available.

      6) One of the following:
            a) The Application uses the PAPI to submit the data/content
                  file and the job ticket to the Print Service.
            b) The Application uses the PAPI to submit the data/content
                  file and the IPP  attributes to the Print Service.
            c) The Application uses the PAPI to submit the data/content
                  file, the job ticket, and the IPP attributes to the Print
                  Service.
            d) The Applicaiton saves the job ticket without submitting it
                  or the data/content file to the Print Service.

* Question: Is the Capabilities API part of PAPI or a separate API?
      See Pete Zannucci's 03Dec2002 and Michael Sweet's 21Nov2002 and
      03Dec2003 appends to the architecture mailing list.