[Printing-architecture] Coding the Common Printing Dialog and its interface
Till Kamppeter
till.kamppeter at gmail.com
Thu May 1 10:57:44 PDT 2008
Lars Uebernickel wrote:
>> 2. Interface between application and dialog. On the OpenPrinting Meeting
>> on the LF Summit in Austin we have discussed what the application has
>> to communicate with the printing dialog. It looks more or less like
>> this:
>>
>> - User clicks "Print": Application generates PDF from the document
>> and sends it to the dialog, along with the list of
>> application-specific options (all choices, ranges, icons, ...) and
>> their settings, application-specific constraints for the printer
>> or CUPS options, printer option settings and queue selection which
>> were saved with the document, window ID of the application (to
>> inform app when dialog gets killed).
>
> What kinds of constraints for the options do you have in mind? And how
> could these be communicated to the dialog?
>
For example if you have a tax form application, which prints nothing
else than A4-sized tax forms. This one could restrict "PageSize" to A4-only.
>
>> - Dialog loads list of print queues from CUPS, options for the
>> currently selected queue, and shows the PDF in the preview and the
>> quick selection buttons of the current printer. The dialog reports
>> its window ID back to the app.
>> - If user changes application-specific options, new settings are
>> reported back to the app immediately and app sends new, updated
>> PDF.
>> - If user changes printer-specific options, CUPS options, or the
>> print queue, nothing is reported back to the app. The preview
>> gets updated.
>> - If user clicks "Print" in the dialog, the PDF as it is currently
>> is sent off into the print queue, along with a list of the
>> settings for the CUPS options and the printer-specific options.
>> The choice of the queue, the CUPS option settings and the settings
>> of the printer-specific options are reported back to the
>> application, so that the application can save them with the
>> document to be used on the next printout.
>>
>> Suggested data formats and wire protocols:
>>
>> - Use DBUS for exchanging data between the app process and the
>> dialog process.
>> - Everything except the PDF data stream goes through the DBUS, for
>> the PDF data stream we use sockets.
>> - The application specific options and constraints with all choices,
>> tags, icons, can be submitted in PPD format, using the PPD
>> extensions of spec 1.
>
> Not all application developers know about PPDs. To save them the hassle
> of reading the (really long) spec and the CUPS and OpenPrinting
> extensions, I propose to provide a simpler API for adding application
> specific options to the dialog. This would fit nicely into the dialog's
> DBUS API.
>
> If necessary, we can additionally allow the PPD format.
>
OK, then we should suggest a simple format to describe printing options
here. How do KDE apps (like digikam or konqueror) inject app-specific
options into the printing dialog?
Till
More information about the Printing-architecture
mailing list