Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes

[Lars Uebernickel <larsuebernickel@gmx.de>]

Thank you for your feedback! I've added some notes below.

Osamu MIHARA wrote:
> Here is the second (last) part of the quick translation of the last
> OPWP-J meeting minutes.
> 
> (4) CPD Specification Review
> ----------------------------
> Following documents (as of 6/19/2008) are reviewed.  Due to the limited
> time, we only review these 2 documents.  May needs to review in deep in
> July again.
> 
> OpenPrinting/CommonPrintingDialogRequirements
> <http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialogRequirements>
> 
> OpenPrinting/PPDExtensions
> <http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions>
> 
> 
> ==== Overall (Terminology) ====
>   In order to avoid confusion, keyword must/should/may should be in
> capital case (MUST/SHOULD/MAY)
> 
> ==== Requirements ====
> - Open Icon
>   Icon format should be defined (PNG or SVG are discussed in ML)
> 
> - Preview
>   We need to consider what kind of information should be shown in the
> preview window.

This is entirely up to the application. Most applications will send the 
full document, maybe in a low-quality version. The dialog API also 
supports sending partial documents, in the case that transmitting the 
full document would take to long.


> - Mutiple Print Dialogs
>   The document states one print dialog can be shown per one application
> (or process).  It is sometimes inconvenient for users.  Some members
> have opinion that one dialog for a opened document is preferable.

This makes sense, especially now that many applications are SDI (one 
window per document). I will change the specs accordingly.


> - Access method to PPD
>   The dialog should access PPD file via CUPS API.  It shouldn't handle
> th PPD directly to avoid access conflict, configuration problem, etc.

You are right, this is the way it should be done. The OpenPrinting 
specific keywords can be read with the ppdFindAttr/ppdFindNextAttr 
functions of the CUPS API.


> - Option Change Notification
>   Some members pointed out that applications/dialogs should be notified
> when PPD is updated or printer configuration is updated.
> 
> - Document Size
> 
>   What does the "Size" mean?  File size, or document dimension?
>   Which of dialog or application submit the document into the print
> queue?  Is it preferable that the dialog submit the data, because it
> does not require application to be largely modified.
> 
>   Anyway, the print data flow should be defined clearly.

This is the file size of the document, in bytes. If the dialog knows the 
size of the document, it can show a progress bar or similar to indicate 
the current state of transmitting the document.

> 
> - Option Hints
> 
>   May need concrete example.

Option hints add some semantics to an option. These are probably more 
useful for application specific options. If an application can give the 
dialog a hint on what an option value represents, the dialog can make 
the setting of the option more accessible to the user.

There are some examples on the requirements page you linked.

> - Option Saving
> 
>   Options saved by CPD and application may be different.
> 
>   It is difficult to save option settings for dialogs not depending on
> application or document data.
> 
>   Applications can save option settings with document data.
> 
>   It is really needed to save option settings INDEPENDENT from app?

The print dialog should always apply the options it saved *before* the 
application sets any options. This ensures settings by the application 
will not get lost.

The benefit of saving the options independent from the application is, 
that all applications get automatic option saving, even if they do not 
implement this by themselves.

> - General
> 
>   Shouldn't the changes in printer-specific setting need to notify to apps?

Yes, applications will be notified by all option settings.


>   With current idea, it takes too much time for a dialog shown up after
> clicking print button, because an app needs to generates PDF to do it.

No, the dialog can be shown before the preview or document data are ready.


>   Multilingual should be supported in CPD in early stage.  CPD should
> refer locale to switch format of units or dates.
> 
>   Need provide library file which is needed by apps.
> 
> ==== PPD Extensions ====
> - Quick Presets
>   The definition should be in formal matter such as BNF.
> 
>   Need more explanation for each items, in special a) in Quick Presets
> (no one can understand relationship of a) and b)).
> 
>   Need detail explanation for Lecacy case
> 
> - Option Tagging
>   Is it a MUST item?  What happens for a PPD without tagging?
> 
> - Icons for options and chises
>   Icons should be switched based on language settings.
> 
> 
> 
> (5) Others
> Opvp drivers cannot execute in SELinux environment.
>  - dlopen causes error
>  - driver vendors should provide policy, but it is difficult because the
> policy spec is not stable.
>  - SUSE Linux uses another mechanism (AppArmor) ... need confirmation.
>  - Continue investigation.
> 
> 
> // Osamu Mihara
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture