[Printing-architecture] Coding the Common Printing Dialog and its interface

[Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Hi,

here I post some bits about the coordination of the coding of the Common 
Printing Dialog. They are results of our discussion on the OpenPrinting 
Meeting on the Linux Foundation Summit in Austin:

https://www.linux-foundation.org/en/OpenPrinting/LFSummitAustin2008
https://lists.linux-foundation.org/pipermail/printing-architecture/2008/001351.html
    (and follow-ups)

There are two students in the Google Summer of Code to implement the dialog:

Lars Uebernickel will code the interface between applications and the 
printing dialog, so that the dialog gets exchangeable, for example one 
can let the GNOME/GTK printing dialog appear when a KDE app is used on a 
GNOME desktop. This will also allow to plug the OpenUsability printing 
dialog.

Alexander Wauck will code the Common Printing Dialog itself as designed 
by OpenUsability.

These students will have Jonathan Riddell, developer of dual-UI (KDE and 
GNOME) apps, as principal mentor. Co-mentoring is done by me (printing 
infrastructure coordination) and Josef Spillner (expert on automated 
dialog generation, so more for the dialog itself).

See also http://code.google.com/soc/2008/linux/about.html

During the coding of the dialog projects we must create the following 
specs, and these must get finished before the Linux Foundation Japan 
Symposium in Tokyo on July 8. Peter Sikking (OpenUsability) and me will 
present the dialog and the specs there.

1. PPD extensions (and Foomatic extensions) for driver
    developers/printer manufacturers: Here we have to list special
    keywords and standard parameters added to the Adobe specs so that the
    driver designer can m ake use of all features of the dialog:

     - Tagging options to put them into categories like "Paper Saving",
       "Printout Quality", ... An option should be able to have more than
       one tag
     - Marking one option to be used for the quick selection buttons of
       the standard view of the OpenUsability dialog
     - CUPS custom options to allow advanced data types, like for user
       names, passwords, fax numbers, numerical parameters
     - CUPS multi-language extensions for multi-language PPDs
     - UU-encoded icons for options and choices, to allow easier
       understanding of options and also to allow manufacturers to inject
       some corporate identity into the dialog.

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).
     - 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.
     - Option setting lists can be exchanged as simple key-value pairs
       ("opt1=choiceA opt2=choiceC ...")
     - Print queue choice and window ID can be exchanged as simple ASCII
     - If ASCII text pieces are too big, exchange them gzipped

3. How the OpenUsability dialog itself has to look like and how it is
    operated.

     - See Peter Sikking's blog
       http://www.mmiworks.net/eng/publications/labels/openPrinting.html
     - Peter is working with a student on the specs.


For part 1 of the specs I will post suggestions soon.

Part 2 will be mainly determined by Lars and part 3 by Peter.

As Lars's modularization of the printing dialog is not restricted to the 
OpenUsability printing dialog part 2 needs perhaps some additional 
features (are the features shown above also enough for the standard KDE 
and GNOME print dialogs?)

To let the two projects not depend on each other too early but allow 
them to be coupled near the end of the Google Summer of Code, one can 
proceed as follows:

Alexander will start coding the dialog simply coupled to one reference 
application, so that one can demo it in Tokyo.

Lars will use the the standard KDE and/or GNOME dialogs as the Common 
Printing Dialog at first. He will define the DBUS communication and 
write glue code for the dialog side and the app side. The glue code on 
the app side can be patches to the printing libraries of the desktops, 
so that ideally existing apps stay using the current APIs and do not 
need to be modified. The whole thing can be even delivered as patches to 
the printing libraries of the desktops.

I hope this is a good start of information for all parties to get into 
this project.

Any suggestions for improvement are welcome.

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Marcelo Ricardo Leitner]

Hi there Till,

It's very nice to see kinda movement on this subject :)

There are some questions that didn't get clear to me:

1) You said application will send the pdf document to the dialog via
sockets. Having that said, is it really "sockets" or "pipes"? Note that
sockets normally references connections & stuff, possibility to be on
different machine, ..  while pipes doesn't.

2) After the document is transfered to the dialog, where will it be
stored? We can do it in memory or on temporary files. In memory sounds
killer for medium-large documents or small boxes, while storing in
temporary files kinda makes the previous step unnecessary.

Performance may strike here, considering preview updates which would
require the entire document to be re-transferred.

3) You said printer-specific options aren't going to be reported back
immediately to the application, but after the job is printed. How are we
going to know which one if printer-specific and which one is
application-specific?

Because there are some options that raise doubts, like duplex/book
printings on enhanced printers. For example, consider you are printing a
financial report from kmymoney. You don't have access to margin setups,
while the application could handle them a bit better for the duplex/book
printing. (due to the left/right margings becoming different)

Still, application could change something at the document if you decide
to print in B/W instead of colors, like for example making all text
plain black (so you won't get unreadable grays).

4) You said the application would be storing used values for future
re-usage. Is that the optimal? Considering every app would have to do
it, maybe it would be interesting to have the dialog storing it. We
could spawn the dialog informing a domain and when the dialog boots up,
it would fake events while restoring our saved setup, thus informing the
app about it transparently.

5) "If ASCII text pieces are too big, exchange them gzipped"
Considering we may be transferring the whole document via socket/pipes,
this idea may not be really useful or am I missing something here?

Thanks,
Marcelo.

Till Kamppeter escreveu:
> Hi,
> 
> here I post some bits about the coordination of the coding of the Common 
> Printing Dialog. They are results of our discussion on the OpenPrinting 
> Meeting on the Linux Foundation Summit in Austin:
> 
> https://www.linux-foundation.org/en/OpenPrinting/LFSummitAustin2008
> https://lists.linux-foundation.org/pipermail/printing-architecture/2008/001351.html
>     (and follow-ups)
> 
> There are two students in the Google Summer of Code to implement the dialog:
> 
> Lars Uebernickel will code the interface between applications and the 
> printing dialog, so that the dialog gets exchangeable, for example one 
> can let the GNOME/GTK printing dialog appear when a KDE app is used on a 
> GNOME desktop. This will also allow to plug the OpenUsability printing 
> dialog.
> 
> Alexander Wauck will code the Common Printing Dialog itself as designed 
> by OpenUsability.
> 
> These students will have Jonathan Riddell, developer of dual-UI (KDE and 
> GNOME) apps, as principal mentor. Co-mentoring is done by me (printing 
> infrastructure coordination) and Josef Spillner (expert on automated 
> dialog generation, so more for the dialog itself).
> 
> See also http://code.google.com/soc/2008/linux/about.html
> 
> During the coding of the dialog projects we must create the following 
> specs, and these must get finished before the Linux Foundation Japan 
> Symposium in Tokyo on July 8. Peter Sikking (OpenUsability) and me will 
> present the dialog and the specs there.
> 
> 1. PPD extensions (and Foomatic extensions) for driver
>     developers/printer manufacturers: Here we have to list special
>     keywords and standard parameters added to the Adobe specs so that the
>     driver designer can m ake use of all features of the dialog:
> 
>      - Tagging options to put them into categories like "Paper Saving",
>        "Printout Quality", ... An option should be able to have more than
>        one tag
>      - Marking one option to be used for the quick selection buttons of
>        the standard view of the OpenUsability dialog
>      - CUPS custom options to allow advanced data types, like for user
>        names, passwords, fax numbers, numerical parameters
>      - CUPS multi-language extensions for multi-language PPDs
>      - UU-encoded icons for options and choices, to allow easier
>        understanding of options and also to allow manufacturers to inject
>        some corporate identity into the dialog.
> 
> 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).
>      - 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.
>      - Option setting lists can be exchanged as simple key-value pairs
>        ("opt1=choiceA opt2=choiceC ...")
>      - Print queue choice and window ID can be exchanged as simple ASCII
>      - If ASCII text pieces are too big, exchange them gzipped
> 
> 3. How the OpenUsability dialog itself has to look like and how it is
>     operated.
> 
>      - See Peter Sikking's blog
>        http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>      - Peter is working with a student on the specs.
> 
> 
> For part 1 of the specs I will post suggestions soon.
> 
> Part 2 will be mainly determined by Lars and part 3 by Peter.
> 
> As Lars's modularization of the printing dialog is not restricted to the 
> OpenUsability printing dialog part 2 needs perhaps some additional 
> features (are the features shown above also enough for the standard KDE 
> and GNOME print dialogs?)
> 
> To let the two projects not depend on each other too early but allow 
> them to be coupled near the end of the Google Summer of Code, one can 
> proceed as follows:
> 
> Alexander will start coding the dialog simply coupled to one reference 
> application, so that one can demo it in Tokyo.
> 
> Lars will use the the standard KDE and/or GNOME dialogs as the Common 
> Printing Dialog at first. He will define the DBUS communication and 
> write glue code for the dialog side and the app side. The glue code on 
> the app side can be patches to the printing libraries of the desktops, 
> so that ideally existing apps stay using the current APIs and do not 
> need to be modified. The whole thing can be even delivered as patches to 
> the printing libraries of the desktops.
> 
> I hope this is a good start of information for all parties to get into 
> this project.
> 
> Any suggestions for improvement are welcome.
> 
>     Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Marcelo Ricardo Leitner wrote:
> Hi there Till,
> 
> It's very nice to see kinda movement on this subject :)
> 
> There are some questions that didn't get clear to me:
> 
> 1) You said application will send the pdf document to the dialog via
> sockets. Having that said, is it really "sockets" or "pipes"? Note that
> sockets normally references connections & stuff, possibility to be on
> different machine, ..  while pipes doesn't.
>

Yes, can be also a pipe.

> 2) After the document is transfered to the dialog, where will it be
> stored? We can do it in memory or on temporary files. In memory sounds
> killer for medium-large documents or small boxes, while storing in
> temporary files kinda makes the previous step unnecessary.
> 

That's true. In the data set sent by DBUS the temporary file name can be 
given and then the dialog simply accesses the fui

> Performance may strike here, considering preview updates which would
> require the entire document to be re-transferred.
> 

Before "Print" in the dialog is clicked one should perhaps only generate 
PDF from the one page currently visible in the preview and let the 
dialog request the other pages from the app when the user is navigating 
in the preview, and naturally when he clicks "Print".

> 3) You said printer-specific options aren't going to be reported back
> immediately to the application, but after the job is printed. How are we
> going to know which one if printer-specific and which one is
> application-specific?
> 

Printer-specific options come from the PPD (the dialog polls the PPD 
from CUPS), application-specific options are submitted by the 
application along with the job, and CUPS options the dialog knows 
already. So it is no problem for the dialog to distinguish the origins 
of the options.

> Because there are some options that raise doubts, like duplex/book
> printings on enhanced printers. For example, consider you are printing a
> financial report from kmymoney. You don't have access to margin setups,
> while the application could handle them a bit better for the duplex/book
> printing. (due to the left/right margings becoming different)
> 

If a printer-based duplex/book functionality is used, the margins are 
usually not changed, or the printer chnages them slightly when shrinking 
the pages to fit two on one sheet. When activating book printing or N-Up 
you will not need to request a changed document from the application.

In certain apps it makes sense to report some standard options, like 
Duplex, so that the app can switch to assymetric margins. Here an app 
could perhaps submit a list of options for which the dialog should send 
back the settings on each change.

> Still, application could change something at the document if you decide
> to print in B/W instead of colors, like for example making all text
> plain black (so you won't get unreadable grays).
> 

In this case the app would tell that it would re-generate the PDF on the 
ColorMode option.

> 4) You said the application would be storing used values for future
> re-usage. Is that the optimal? Considering every app would have to do
> it, maybe it would be interesting to have the dialog storing it. We
> could spawn the dialog informing a domain and when the dialog boots up,
> it would fake events while restoring our saved setup, thus informing the
> app about it transparently.
> 

Imaging you have a photo app from which you always print in color on an 
inkjet and a word processor from which you always print on a bw laser. 
Also option settings can depend very much on the document. So storing 
printer settings along with a document is not such a bad idea.

> 5) "If ASCII text pieces are too big, exchange them gzipped"
> Considering we may be transferring the whole document via socket/pipes,
> this idea may not be really useful or am I missing something here?

Option definitions and settings are transferred as plain text. If this 
data stream gets too long (should not be the case) one could transfer it 
gzipped.

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Marcelo Ricardo Leitner]

Till Kamppeter escreveu:
> Marcelo Ricardo Leitner wrote:
>> 2) After the document is transfered to the dialog, where will it be
>> stored? We can do it in memory or on temporary files. In memory sounds
>> killer for medium-large documents or small boxes, while storing in
>> temporary files kinda makes the previous step unnecessary.
>>
> 
> That's true. In the data set sent by DBUS the temporary file name can be
> given and then the dialog simply accesses the fui
> 
>> Performance may strike here, considering preview updates which would
>> require the entire document to be re-transferred.
>>
> 
> Before "Print" in the dialog is clicked one should perhaps only generate
> PDF from the one page currently visible in the preview and let the
> dialog request the other pages from the app when the user is navigating
> in the preview, and naturally when he clicks "Print".

Ok, I've no idea how each app converts its data to the print job, but is
that really possible? I mean, rendering page 3 on a browser wouldn't
require pages 1 and 2 be rendered first? Again, no idea here, but the
idea sounds interesting if possible.

>> 3) You said printer-specific options aren't going to be reported back
>> immediately to the application, but after the job is printed. How are we
>> going to know which one if printer-specific and which one is
>> application-specific?
>>
> 
> Printer-specific options come from the PPD (the dialog polls the PPD
> from CUPS), application-specific options are submitted by the
> application along with the job, and CUPS options the dialog knows
> already. So it is no problem for the dialog to distinguish the origins
> of the options.
> 
>> Because there are some options that raise doubts, like duplex/book
>> printings on enhanced printers. For example, consider you are printing a
>> financial report from kmymoney. You don't have access to margin setups,
>> while the application could handle them a bit better for the duplex/book
>> printing. (due to the left/right margings becoming different)
>>
> 
> If a printer-based duplex/book functionality is used, the margins are
> usually not changed, or the printer chnages them slightly when shrinking
> the pages to fit two on one sheet. When activating book printing or N-Up
> you will not need to request a changed document from the application.
> 
> In certain apps it makes sense to report some standard options, like
> Duplex, so that the app can switch to assymetric margins. Here an app
> could perhaps submit a list of options for which the dialog should send
> back the settings on each change.

Ok, you understood what I meant. So it should be possible for
applications be informed about other attributes changes, not only its ones.

>> Still, application could change something at the document if you decide
>> to print in B/W instead of colors, like for example making all text
>> plain black (so you won't get unreadable grays).
>>
> 
> In this case the app would tell that it would re-generate the PDF on the
> ColorMode option.

Yes, it would use the structure just discussed right above for that :)

>> 4) You said the application would be storing used values for future
>> re-usage. Is that the optimal? Considering every app would have to do
>> it, maybe it would be interesting to have the dialog storing it. We
>> could spawn the dialog informing a domain and when the dialog boots up,
>> it would fake events while restoring our saved setup, thus informing the
>> app about it transparently.
>>
> 
> Imaging you have a photo app from which you always print in color on an
> inkjet and a word processor from which you always print on a bw laser.
> Also option settings can depend very much on the document. So storing
> printer settings along with a document is not such a bad idea.

In this case, storing the configs along with the dialog would be enough,
as it would be cross-referenced against printer queue and application
being used.

You are right, perhaps the application would want to store it matching
against the document being printed. But that could be handled by the
dialog too, it would just be another field or even a matter of defining
a format for that domain name I talked about, "app[/doc hash]"..

Thanks,
Marcelo.

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Marcelo Ricardo Leitner wrote:
> Ok, I've no idea how each app converts its data to the print job, but is
> that really possible? I mean, rendering page 3 on a browser wouldn't
> require pages 1 and 2 be rendered first? Again, no idea here, but the
> idea sounds interesting if possible.
> 

Such applications will have to rerender the whole document, but many 
other do not, like OpenOffice.org, Scribus, photo management software, 
... This is no big problem, as wep pages are not so long and also not 
very complex to render, whereas a document in OOo can have several 
hundred pages, many fonts, vector-drawn pictures, ...

> 
> In this case, storing the configs along with the dialog would be enough,
> as it would be cross-referenced against printer queue and application
> being used.
> 
> You are right, perhaps the application would want to store it matching
> against the document being printed. But that could be handled by the
> dialog too, it would just be another field or even a matter of defining
> a format for that domain name I talked about, "app[/doc hash]"..

OpenOffice.org saves printing settings (selected print queue and option 
settings) in its documents. To not require OOo to change the feature 
with the introduction of the Common Printing Dialog we should support 
this in our interface between application and dialog.

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Lars Uebernickel]

Till Kamppeter wrote:
> Marcelo Ricardo Leitner wrote:
>> Ok, I've no idea how each app converts its data to the print job, but is
>> that really possible? I mean, rendering page 3 on a browser wouldn't
>> require pages 1 and 2 be rendered first? Again, no idea here, but the
>> idea sounds interesting if possible.
>>
> 
> Such applications will have to rerender the whole document, but many 
> other do not, like OpenOffice.org, Scribus, photo management software, 
> ... This is no big problem, as wep pages are not so long and also not 
> very complex to render, whereas a document in OOo can have several 
> hundred pages, many fonts, vector-drawn pictures, ...
> 
>>
>> In this case, storing the configs along with the dialog would be enough,
>> as it would be cross-referenced against printer queue and application
>> being used.
>>
>> You are right, perhaps the application would want to store it matching
>> against the document being printed. But that could be handled by the
>> dialog too, it would just be another field or even a matter of defining
>> a format for that domain name I talked about, "app[/doc hash]"..
> 
> OpenOffice.org saves printing settings (selected print queue and option 
> settings) in its documents. To not require OOo to change the feature 
> with the introduction of the Common Printing Dialog we should support 
> this in our interface between application and dialog.

I see two possibilities for this problem:

(1) Applications can enable/disable the saving of the printing options 
via the dialog API. This would mean that OpenOffice can keep its own per 
document settings and other applications can take advantage of the 
dialogs capabilities for that. But, they need to explicitly tell the 
dialog to do so.

(2) Options are always saved on a per application/document basis by the 
dialog. The saved options are applied _before_ any application settings 
take place. The application will not be notified. Afterwards, the 
application sets its own settings, effectively overwriting the saved 
ones. So OpenOffice's per document options would still work, and all 
other applications would gain the same feature transparently. It would 
also keep the API cleaner.

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Lars Uebernickel wrote:
> Till Kamppeter wrote:
>>> In this case, storing the configs along with the dialog would be enough,
>>> as it would be cross-referenced against printer queue and application
>>> being used.
>>>
>>> You are right, perhaps the application would want to store it matching
>>> against the document being printed. But that could be handled by the
>>> dialog too, it would just be another field or even a matter of defining
>>> a format for that domain name I talked about, "app[/doc hash]"..
>> OpenOffice.org saves printing settings (selected print queue and option 
>> settings) in its documents. To not require OOo to change the feature 
>> with the introduction of the Common Printing Dialog we should support 
>> this in our interface between application and dialog.
> 
> I see two possibilities for this problem:
> 
> (1) Applications can enable/disable the saving of the printing options 
> via the dialog API. This would mean that OpenOffice can keep its own per 
> document settings and other applications can take advantage of the 
> dialogs capabilities for that. But, they need to explicitly tell the 
> dialog to do so.
> 
> (2) Options are always saved on a per application/document basis by the 
> dialog. The saved options are applied _before_ any application settings 
> take place. The application will not be notified. Afterwards, the 
> application sets its own settings, effectively overwriting the saved 
> ones. So OpenOffice's per document options would still work, and all 
> other applications would gain the same feature transparently. It would 
> also keep the API cleaner.

Support both possibilities in a switchable way. Let application 
developers choose between option saving/remembering per

- Document file (saved in document file)
- Document (saved in personal config directory of the dialog)
- Application (saved in personal config directory of the dialog)
- Globally per user (saved in ~/.cups/lpoptions)

Only in the first case option settings which are not 
application-specific have to be reported back to the application.

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Lars Uebernickel]

Till Kamppeter wrote:
> Lars Uebernickel wrote:
>> Till Kamppeter wrote:
>>>> In this case, storing the configs along with the dialog would be 
>>>> enough,
>>>> as it would be cross-referenced against printer queue and application
>>>> being used.
>>>>
>>>> You are right, perhaps the application would want to store it matching
>>>> against the document being printed. But that could be handled by the
>>>> dialog too, it would just be another field or even a matter of defining
>>>> a format for that domain name I talked about, "app[/doc hash]"..
>>> OpenOffice.org saves printing settings (selected print queue and 
>>> option settings) in its documents. To not require OOo to change the 
>>> feature with the introduction of the Common Printing Dialog we should 
>>> support this in our interface between application and dialog.
>>
>> I see two possibilities for this problem:
>>
>> (1) Applications can enable/disable the saving of the printing options 
>> via the dialog API. This would mean that OpenOffice can keep its own 
>> per document settings and other applications can take advantage of the 
>> dialogs capabilities for that. But, they need to explicitly tell the 
>> dialog to do so.
>>
>> (2) Options are always saved on a per application/document basis by 
>> the dialog. The saved options are applied _before_ any application 
>> settings take place. The application will not be notified. Afterwards, 
>> the application sets its own settings, effectively overwriting the 
>> saved ones. So OpenOffice's per document options would still work, and 
>> all other applications would gain the same feature transparently. It 
>> would also keep the API cleaner.
> 
> Support both possibilities in a switchable way. Let application 
> developers choose between option saving/remembering per
> 
> - Document file (saved in document file)
> - Document (saved in personal config directory of the dialog)
> - Application (saved in personal config directory of the dialog)
> - Globally per user (saved in ~/.cups/lpoptions)
> 
> Only in the first case option settings which are not 
> application-specific have to be reported back to the application.

What I was suggesting with (2), is that there is no need for 
applications to switch between those possibilities at all. Everything 
would be handled transparently.

The dialog would _always_ store all options for the documents and 
applications. Applications like OpenOffice, which save the options in 
the documents themselves, would just overwrite the stored settings, 
because their settings would be applied after the stored ones.

This way, we'd simplify the API, reducing the amount of work for 
application developers. Also, users could choose themselves whether they 
want options stored for applications/documents (IMHO, this shouldn't be 
decided by the applications anyway). They could even set standard 
options for specific applications or specific types of documents (eg. by 
mime type).

     Lars

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Lars Uebernickel wrote:
> Till Kamppeter wrote:
>> Lars Uebernickel wrote:
>>> Till Kamppeter wrote:
>>>>> In this case, storing the configs along with the dialog would be 
>>>>> enough,
>>>>> as it would be cross-referenced against printer queue and application
>>>>> being used.
>>>>>
>>>>> You are right, perhaps the application would want to store it matching
>>>>> against the document being printed. But that could be handled by the
>>>>> dialog too, it would just be another field or even a matter of defining
>>>>> a format for that domain name I talked about, "app[/doc hash]"..
>>>> OpenOffice.org saves printing settings (selected print queue and 
>>>> option settings) in its documents. To not require OOo to change the 
>>>> feature with the introduction of the Common Printing Dialog we should 
>>>> support this in our interface between application and dialog.
>>> I see two possibilities for this problem:
>>>
>>> (1) Applications can enable/disable the saving of the printing options 
>>> via the dialog API. This would mean that OpenOffice can keep its own 
>>> per document settings and other applications can take advantage of the 
>>> dialogs capabilities for that. But, they need to explicitly tell the 
>>> dialog to do so.
>>>
>>> (2) Options are always saved on a per application/document basis by 
>>> the dialog. The saved options are applied _before_ any application 
>>> settings take place. The application will not be notified. Afterwards, 
>>> the application sets its own settings, effectively overwriting the 
>>> saved ones. So OpenOffice's per document options would still work, and 
>>> all other applications would gain the same feature transparently. It 
>>> would also keep the API cleaner.
>> Support both possibilities in a switchable way. Let application 
>> developers choose between option saving/remembering per
>>
>> - Document file (saved in document file)
>> - Document (saved in personal config directory of the dialog)
>> - Application (saved in personal config directory of the dialog)
>> - Globally per user (saved in ~/.cups/lpoptions)
>>
>> Only in the first case option settings which are not 
>> application-specific have to be reported back to the application.
> 
> What I was suggesting with (2), is that there is no need for 
> applications to switch between those possibilities at all. Everything 
> would be handled transparently.
> 
> The dialog would _always_ store all options for the documents and 
> applications. Applications like OpenOffice, which save the options in 
> the documents themselves, would just overwrite the stored settings, 
> because their settings would be applied after the stored ones.
> 
> This way, we'd simplify the API, reducing the amount of work for 
> application developers. Also, users could choose themselves whether they 
> want options stored for applications/documents (IMHO, this shouldn't be 
> decided by the applications anyway). They could even set standard 
> options for specific applications or specific types of documents (eg. by 
> mime type).

OK, you're right, let's do it this way. As long as OOo developers will 
not complain ...

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Till Kamppeter wrote:
> 3. How the OpenUsability dialog itself has to look like and how it is
>    operated.
> 
>     - See Peter Sikking's blog
>       http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>     - Peter is working with a student on the specs.
> 

Peter has started to write down the specs here:

http://wiki.openusability.org/printing/index.php/Specification

    Till

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

One comment so far: in the "dialog specification" section, it only mentions
the three columns in the middle part of the dialog.  Then, in the "Dialog
Zones Specification" section, it adds a zone that spans columns 2 and 3.
That has very different consequences for the implementation than simply
having three columns.  It looks like the level 3 dialog always has that
zone, so perhaps the first specification should mention it?

Alex

On Wed, Apr 30, 2008 at 1:33 PM, Till Kamppeter <till.kamppeter@gmail.com>
wrote:

> Till Kamppeter wrote:
>
>> 3. How the OpenUsability dialog itself has to look like and how it is
>>   operated.
>>
>>    - See Peter Sikking's blog
>>      http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>>    - Peter is working with a student on the specs.
>>
>>
> Peter has started to write down the specs here:
>
> http://wiki.openusability.org/printing/index.php/Specification
>
>   Till
>
>

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Peter, can you help Alex here?

Peter, can you also subscribe to the printing-architecture mailing list, 
as here the discussion about the implementation of the Common Printing 
Dialog will happen. Subscription via

https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

    Till

Alex Wauck wrote:
> One comment so far: in the "dialog specification" section, it only 
> mentions the three columns in the middle part of the dialog.  Then, in 
> the "Dialog Zones Specification" section, it adds a zone that spans 
> columns 2 and 3.  That has very different consequences for the 
> implementation than simply having three columns.  It looks like the 
> level 3 dialog always has that zone, so perhaps the first specification 
> should mention it?
> 
> Alex
> 
> On Wed, Apr 30, 2008 at 1:33 PM, Till Kamppeter 
> <till.kamppeter@gmail.com <mailto:till.kamppeter@gmail.com>> wrote:
> 
>     Till Kamppeter wrote:
> 
>         3. How the OpenUsability dialog itself has to look like and how
>         it is
>           operated.
> 
>            - See Peter Sikking's blog
>            
>          http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>            - Peter is working with a student on the specs.
> 
> 
>     Peter has started to write down the specs here:
> 
>     http://wiki.openusability.org/printing/index.php/Specification
> 
>       Till
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

Another comment:
Forcing the columns to be a particular height is not particularly easy in Qt
(I don't know how difficult it is in GTK+), and it leads to unexpected
behavior when resizing the dialog.  Specifically, some resize operations are
not possible, and the user may not like that.  Is it really necessary to
force column height?  Perhaps that part of the spec should be relaxed to a
preferred or minimum height instead of a required height.  I got it to work
in Qt by subclassing QGridLayout, but it's a bit of a hack, and a real
solution would likely be much more difficult.

Alex

On Wed, Apr 30, 2008 at 3:12 PM, Alex Wauck <alex.wauck@gmail.com> wrote:

> One comment so far: in the "dialog specification" section, it only mentions
> the three columns in the middle part of the dialog.  Then, in the "Dialog
> Zones Specification" section, it adds a zone that spans columns 2 and 3.
> That has very different consequences for the implementation than simply
> having three columns.  It looks like the level 3 dialog always has that
> zone, so perhaps the first specification should mention it?
>
> Alex
>
>
> On Wed, Apr 30, 2008 at 1:33 PM, Till Kamppeter <till.kamppeter@gmail.com>
> wrote:
>
>> Till Kamppeter wrote:
>>
>>> 3. How the OpenUsability dialog itself has to look like and how it is
>>>   operated.
>>>
>>>    - See Peter Sikking's blog
>>>      http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>>>    - Peter is working with a student on the specs.
>>>
>>>
>> Peter has started to write down the specs here:
>>
>> http://wiki.openusability.org/printing/index.php/Specification
>>
>>   Till
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2701 bytes --]

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Peter, what is the importance of your column height restrictions? Or is 
it only an aspect ratio restriction (see Alex' problems below)?

Josef, you as expert on automatic dialog creation, can you help Alex 
here? AFAIR there was only a restriction on the aspect ratio of the 
columns and not on the absolute height.

    Till

P. S.: Josef can you also subscribe to printing-architecture, as this is 
the central discussion place for the implementation of the Common 
Printing Dialog. Subscription via

https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Alex Wauck wrote:
> Another comment:
> Forcing the columns to be a particular height is not particularly easy 
> in Qt (I don't know how difficult it is in GTK+), and it leads to 
> unexpected behavior when resizing the dialog.  Specifically, some resize 
> operations are not possible, and the user may not like that.  Is it 
> really necessary to force column height?  Perhaps that part of the spec 
> should be relaxed to a preferred or minimum height instead of a required 
> height.  I got it to work in Qt by subclassing QGridLayout, but it's a 
> bit of a hack, and a real solution would likely be much more difficult.
> 
> Alex
> 
> On Wed, Apr 30, 2008 at 3:12 PM, Alex Wauck <alex.wauck@gmail.com 
> <mailto:alex.wauck@gmail.com>> wrote:
> 
>     One comment so far: in the "dialog specification" section, it only
>     mentions the three columns in the middle part of the dialog.  Then,
>     in the "Dialog Zones Specification" section, it adds a zone that
>     spans columns 2 and 3.  That has very different consequences for the
>     implementation than simply having three columns.  It looks like the
>     level 3 dialog always has that zone, so perhaps the first
>     specification should mention it?
> 
>     Alex
> 
> 
>     On Wed, Apr 30, 2008 at 1:33 PM, Till Kamppeter
>     <till.kamppeter@gmail.com <mailto:till.kamppeter@gmail.com>> wrote:
> 
>         Till Kamppeter wrote:
> 
>             3. How the OpenUsability dialog itself has to look like and
>             how it is
>               operated.
> 
>                - See Peter Sikking's blog
>                
>              http://www.mmiworks.net/eng/publications/labels/openPrinting.html
>                - Peter is working with a student on the specs.
> 
> 
>         Peter has started to write down the specs here:
> 
>         http://wiki.openusability.org/printing/index.php/Specification
> 
>           Till
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Olaf Meeuwissen]

Till Kamppeter <till.kamppeter@gmail.com> writes:

> Peter, what is the importance of your column height restrictions? Or is 
> it only an aspect ratio restriction (see Alex' problems below)?

As mentioned earlier in feedback on the CPD, absolute dimensions are
no good when you need to consider i18n and/or assistive technologies.
Given the various languages you will need to cater to, string lengths
will vary, considerably.  For certain scripts, small font sizes just
don't work.  For Japanese, for example, anything less than 12pt is
next to unreadable.  Even 12pt is only hardly bearable.

> Josef, you as expert on automatic dialog creation, can you help Alex 
> here? AFAIR there was only a restriction on the aspect ratio of the 
> columns and not on the absolute height.

Fixed aspect ratios may be okay, but, again, given the variation in
string lengths, I doubt it.  What may be two characters in Japanese
(corresponding to four Latin characters, space wise and using a fixed
width font) may very well be 20 characters in German.  That is to say,
when considering strings, the horizontal and vertical dimensions vary
independently so trying to maintain a fixed aspect ratio is at best
cumbersome.

Also note, that word wrapping may not work as you are used to in CJK
locales.

Hope this helps,

> [snip]
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

Clarification:
It is an aspect ratio restriction.  If it was a simple height restriction,
it would be easy.  Fixed aspect ratio is still a pain in the butt in Qt, and
it has certain usability/user experience implications.  Plus, I'm not sure
what the advantage is.  The ratio between the widths of the columns is
useful and not a problem, but I would like to at least see a clear reason
for making all columns the same height as the width of the second column.

Alex

On Thu, May 1, 2008 at 6:48 PM, Olaf Meeuwissen <olaf.meeuwissen@avasys.jp>
wrote:

> Till Kamppeter <till.kamppeter@gmail.com> writes:
>
> > Peter, what is the importance of your column height restrictions? Or is
> > it only an aspect ratio restriction (see Alex' problems below)?
>
> As mentioned earlier in feedback on the CPD, absolute dimensions are
> no good when you need to consider i18n and/or assistive technologies.
> Given the various languages you will need to cater to, string lengths
> will vary, considerably.  For certain scripts, small font sizes just
> don't work.  For Japanese, for example, anything less than 12pt is
> next to unreadable.  Even 12pt is only hardly bearable.
>
> > Josef, you as expert on automatic dialog creation, can you help Alex
> > here? AFAIR there was only a restriction on the aspect ratio of the
> > columns and not on the absolute height.
>
> Fixed aspect ratios may be okay, but, again, given the variation in
> string lengths, I doubt it.  What may be two characters in Japanese
> (corresponding to four Latin characters, space wise and using a fixed
> width font) may very well be 20 characters in German.  That is to say,
> when considering strings, the horizontal and vertical dimensions vary
> independently so trying to maintain a fixed aspect ratio is at best
> cumbersome.
>
> Also note, that word wrapping may not work as you are used to in CJK
> locales.
>
> Hope this helps,
>
> > [snip]
> --
> Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
> FSF Associate Member #1962           sign up at http://member.fsf.org/
>

[-- Attachment #2: Type: text/html, Size: 2723 bytes --]

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Olaf Meeuwissen]

"Alex Wauck" <alex.wauck@gmail.com> writes:

> Clarification:
> It is an aspect ratio restriction.  If it was a simple height restriction,
> it would be easy.  Fixed aspect ratio is still a pain in the butt in Qt, and
> it has certain usability/user experience implications.  Plus, I'm not sure
> what the advantage is.  The ratio between the widths of the columns is
> useful and not a problem, but I would like to at least see a clear reason
> for making all columns the same height as the width of the second column.

Given my comments about i18n string issues, the only workable solution
I can think of when you really *have* to use a fixed aspect ratio (or
fixed dimensions for that matter) would be a widget with (on-demand)
scroll bars.

That said, scrolling horizontally is a seriously bad user experience.

Hope this helps,
> Alex
>
> On Thu, May 1, 2008 at 6:48 PM, Olaf Meeuwissen <olaf.meeuwissen@avasys.jp>
> wrote:
>
>> Till Kamppeter <till.kamppeter@gmail.com> writes:
>>
>> > Peter, what is the importance of your column height restrictions? Or is
>> > it only an aspect ratio restriction (see Alex' problems below)?
>>
>> As mentioned earlier in feedback on the CPD, absolute dimensions are
>> no good when you need to consider i18n and/or assistive technologies.
>> Given the various languages you will need to cater to, string lengths
>> will vary, considerably.  For certain scripts, small font sizes just
>> don't work.  For Japanese, for example, anything less than 12pt is
>> next to unreadable.  Even 12pt is only hardly bearable.
>>
>> > Josef, you as expert on automatic dialog creation, can you help Alex
>> > here? AFAIR there was only a restriction on the aspect ratio of the
>> > columns and not on the absolute height.
>>
>> Fixed aspect ratios may be okay, but, again, given the variation in
>> string lengths, I doubt it.  What may be two characters in Japanese
>> (corresponding to four Latin characters, space wise and using a fixed
>> width font) may very well be 20 characters in German.  That is to say,
>> when considering strings, the horizontal and vertical dimensions vary
>> independently so trying to maintain a fixed aspect ratio is at best
>> cumbersome.
>>
>> Also note, that word wrapping may not work as you are used to in CJK
>> locales.
>>
>> Hope this helps,
>>
>> > [snip]
>> --
>> Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
>> FSF Associate Member #1962           sign up at http://member.fsf.org/
>>

-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[peter sikking]

Hi all,

I joined the fun here too.

First of all welcome Alex and Lars. I am looking forward to working
with you both on the dialog. you can find me on the openusability
irc channel for a quick question.

Keep in mind that the spec on the wiki is ‘under construction.’
I do not mind showing you how this grows step by step, if you do not
mind looking at incomplete or plain wrong stuff for a week or two.

being on a helter-skelter schedule, I will keep it short here.

Yes I have been dealing with internationalisation of software for the  
last
14 years. See for instance that we are dealing with r-to-l languages  
from
now on.

Note that a preview shall (learned that one in '98) be shown under
all circumstances in the print dialog. It shall be accurate within the
small (just big enough) size I gave it. It is central to solving
dozens of usability issues.

About the dialog layout: most questions look to be caused by bugs in
the spec. It is a dialog, so there is no user resizing. column spanning
will be normal (big things like booklet making will probably need all
that space).

The state of the dialog shall be persisted for each
user/printer (model)/app combination on pressing the Print button.
per document looks to be excessive if not undesirable from usability  
pov.

Oh yeah, we need to put the manufacturer logo somewhere. The top
corner opposite the printer pop-up will be available for that.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Josef Spillner]

Hello,

Am Donnerstag 01 Mai 2008 18:58:13 schrieb Till Kamppeter:
> Josef, you as expert on automatic dialog creation, can you help Alex
> here? AFAIR there was only a restriction on the aspect ratio of the
> columns and not on the absolute height.

Sorry for replying late. I've just come back from FISL and other activities in 
South America, and used some time to persuade SoC students who were not 
accepted to still work on their project.

Soon I'll get back to Alex about the UI issues.

> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

I'm already subscribed to that list :-)

Josef

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Lars Uebernickel]

> 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?


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

>     - Option setting lists can be exchanged as simple key-value pairs
>       ("opt1=choiceA opt2=choiceC ...")
>     - Print queue choice and window ID can be exchanged as simple ASCII
>     - If ASCII text pieces are too big, exchange them gzipped
> 

Re: [Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

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