[Desktop_printing] PPD settings vs IPP options

Alexander Larsson alexl at redhat.com
Thu Feb 9 07:08:06 PST 2006


On Thu, 2006-02-09 at 15:23 +0100, Johannes Meixner wrote: 
> Hello,
> 
> On Feb 9 14:00 Alexander Larsson wrote (shortened):
> > 1) Get the PPD file for the printer, use the PPD file to set up the UI
> > and defaults. When printing, embed the postscript snippets from the PPD
> > file based on the settings the user made. Send this to the cups/ipp
> > server.
> 
> No.
> 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.
> In particular the CUPS filter "pstops" will embed the PostScript
> snippets from the PPD according to the job options.

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

It would be perfectly possible for such code to either generate
ready-to-print data or printer-independent data. And since it seems like
the PPD data would allow a better printer dialog it seems that
generating ready-to-print data would be the preferable choice in this
case. 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?

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? Things like that seems hard to do with ipp options.

> By the way:
> 
> What about "Printer Specific Options" (from the PPD)
> versus CUPS "Standard Printer Options" in the print dialog?
> 
> I noticed that normal users are often confused by this
> because they don't have the background knowledge to
> distinguish between both kind of options.
> 
> The "Printer Specific Options" can be set for any kind
> of document type but the "Standard Printer Options"
> depend on the document type:
> 
> For example a normal user doesn't know when a document
> which looks like plain text is really plain (ASCII) text
> or PostScript because this depends on what the text editor
> or the mailer sends to the printing system.
> If it is PostScript, the "Text Options" cannot work
> because the CUPS filter texttops which implements
> the "Text Options" does not run if the document
> type is PostScript.

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 on unix. (On win32 we use the
windows GDI and printer drivers to generate output.) So, no filter
except possibly pstops will be run for these files.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a fiendish neurotic master criminal possessed of the uncanny powers of an 
insect. She's a bloodthirsty extravagent hooker prone to fits of savage, 
blood-crazed rage. They fight crime! 




More information about the Printing-summit mailing list