[Desktop_printing] PPD settings vs IPP options

[Johannes Meixner]

Hello,

On Feb 9 16:08 Alexander Larsson wrote (shortened):
> On Thu, 2006-02-09 at 15:23 +0100, Johannes Meixner wrote: 
> > A normal application should create printer independent
> > PostScript and specify all options as print job parameters
> > and let the CUPS filter system do the actual processing.
> 
> Define "normal application". In this case this is library code that will
> first display a dialog that lets you select printer and settings for the
> printer, and then it generates the postscript for the output from a set
> of device-independent rendering calls the application makes (i.e. the
> app calls cairo). 

When this library code is called by normal applications,
it can be considered as part of a normal application.

I gave two examples of special applications which usually
produce ready-to-print data.

You don't need to care much about special applications which
need to produce ready-to-print data because all what there can be
selected is the queue and it is questionable if even this makes
sense because why let the user select from different printers
when the data is already made for one particular printer model?


> So, maybe we should just ignore the IPP options and print -raw. 
> Of course, this might be problematic if the actual printer isn't a
> postscript printer but something that cups has to rasterize before
> printing. Will that work if you send such postscript with -raw?

Either 100% printer-independent generic data and let
the CUPS filtering system produce the printer specific data
or 100% ready-to-print printer specific data which must be
submitted with "-o raw" and then no CUPS filtering is done.


> By the way, what sort of features are available in printer-independent
> postscript? For instance, can you do different paper sizes/orientation
> for each page?

As far as I know the CUPS filtering (at least in CUPS 1.1)
does not support printer-specific settings per page.

If you need it, you could
either produce 100% ready-to-print data for any possible printer
model (which is actually impossible because you would have to
re-implement most of the CUPS filtering)
or you could split the job into several subsequent jobs so that
you can set different printer-specific settings for the pages
in each job but then the pages of several splitted jobs may be
printed in mixed-up order :-(


> > By the way:
> > 
> > What about "Printer Specific Options" (from the PPD)
> > versus CUPS "Standard Printer Options" in the print dialog?
...
> This doesn't really apply in this case. I'm not printing an existing
> file in some file format, I'm generating printer data in whatever form
> it wants, which is typically postscript

Don't get confused by the command line example.
I wrote it to make clear what I have in mind:
Print local data in whatever form on a remote CUPS system.

As your library does it (I assume your library can print to remote
queues) and as your library displays a dialog, it applies - except
your library produces always printer-independent PostScript - then
you know the CUPS MIME type in advance and then you can show the
right "Standard Printer Options" in the dialog.

If you are generating data in whatever form, how can you know
the CUPS MIME type in advance to show the right "Standard
Printer Options" in the dialog?

Often one can guess the CUPS MIME type but what I have in mind is
if it is possible to get the exact CUPS MIME type in advance.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/