From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <481A0498.8030302@gmail.com> Date: Thu, 01 May 2008 19:57:44 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <481101A3.6030700@gmail.com> <4819F0F1.6050307@gmx.de> In-Reply-To: <4819F0F1.6050307@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Coding the Common Printing Dialog and its interface List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lars Uebernickel Cc: printing-architecture@lists.linux-foundation.org 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