[Printing-architecture] Print scenario

[Printing-architecture] Print scenario

[Mark Hamzy]

The following is a scenario for an application that wants to print.
These are the steps that I think the application will perform.  What areas
in this scenario do we need to work on/standardize?

 1 enumerate print queues
      * Use Foomatic for this?

 2 display job dialog

 3 receive job properties in standardized format
      * rely on PPD file format for this?

 4 query page presentation parameters
      - size of page
      - margin information
      - resolution
      - color/monochrome
      - fonts
      * parse PPD file for this information?

 5 generate print job
      - postscript/PDF
      - html
      - plain text
      - bitmap file (png, jpg, etc)
      - SVG file
      * linux applications generate postscript files

 6 submit print job with job properties.  The queue processor will run some
      transformation.  Ex: use Ghostscript to convert postscript to printer
output.
      * CUPS will accept postscript

 7 track print job / display status
     - real-time display?

 8 receive end of job notification

Mark

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

Re: [Printing-architecture] Print scenario

[Michael Sweet]

Mark Hamzy wrote:
> 
> 
> 
> The following is a scenario for an application that wants to print.
> These are the steps that I think the application will perform.  What areas
> in this scenario do we need to work on/standardize?
> 
>  1 enumerate print queues
>       * Use Foomatic for this?

PAPI!

>  2 display job dialog

PAPI!

>  3 receive job properties in standardized format
>       * rely on PPD file format for this?

PPD is one source of the information, however we have already
discussed adding a format-neutral mapping of capabilities to
attributes in PAPI so that an application can use PAPI to
tailor the output to a printer, choose job options, etc.

>  4 query page presentation parameters
>       - size of page
>       - margin information
>       - resolution
>       - color/monochrome
>       - fonts
>       * parse PPD file for this information?

See above.

>  5 generate print job
>       - postscript/PDF
>       - html
>       - plain text
>       - bitmap file (png, jpg, etc)
>       - SVG file
>       * linux applications generate postscript files

HTML is not suited to printing due to its use of externally
referenced data like images.  XHTML-Print is the PWG equivalent
and supports in-line images, among other things.

The document-format-supported attribute from PAPI can and should
be used by an app to confirm that the printer/printing system can
print the file.

>  6 submit print job with job properties.  The queue processor will run some
>       transformation.  Ex: use Ghostscript to convert postscript to printer
> output.
>       * CUPS will accept postscript

CUPS will accept anything in your above list except SVG.

>  7 track print job / display status
>      - real-time display?
 >
>  8 receive end of job notification

These last two are optional IMHO - job notification is a separate
issue, and while some apps might choose to provide this, it is
more logically something that should be provided in a separate
application/monitor that runs as part of the user's window
environment.  Adding job monitoring to every app will just add
bloat in the form of increased memory usage, increased bandwidth
usage between client and server, and increased CPU usage on both
client and server.

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