* Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
2008-06-23 8:47 ` Osamu MIHARA
@ 2008-06-23 9:38 ` Lars Uebernickel
2008-06-23 21:50 ` Till Kamppeter
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Lars Uebernickel @ 2008-06-23 9:38 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
2008-06-23 8:47 ` Osamu MIHARA
2008-06-23 9:38 ` Lars Uebernickel
@ 2008-06-23 21:50 ` Till Kamppeter
2008-06-23 21:50 ` Till Kamppeter
2008-06-25 21:39 ` Till Kamppeter
3 siblings, 0 replies; 7+ messages in thread
From: Till Kamppeter @ 2008-06-23 21:50 UTC (permalink / raw)
To: Osamu MIHARA; +Cc: printing-architecture, printing-japan
Thank you for the second part of the translation. I will improve my PPD
extension specs soon.
Till
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.
>
> - 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.
>
> - 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.
>
> - 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.
>
>
> - Option Hints
>
> May need concrete example.
>
> - 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?
>
> - General
>
> Shouldn't the changes in printer-specific setting need to notify to apps?
>
> 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.
>
> 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-japan mailing list
> Printing-japan@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-japan
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
2008-06-23 8:47 ` Osamu MIHARA
2008-06-23 9:38 ` Lars Uebernickel
2008-06-23 21:50 ` Till Kamppeter
@ 2008-06-23 21:50 ` Till Kamppeter
2008-06-25 21:39 ` Till Kamppeter
3 siblings, 0 replies; 7+ messages in thread
From: Till Kamppeter @ 2008-06-23 21:50 UTC (permalink / raw)
To: Osamu MIHARA; +Cc: printing-architecture, printing-japan
Thank you for the second part of the translation. I will improve my PPD
extension specs this week.
Till
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.
>
> - 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.
>
> - 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.
>
> - 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.
>
>
> - Option Hints
>
> May need concrete example.
>
> - 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?
>
> - General
>
> Shouldn't the changes in printer-specific setting need to notify to apps?
>
> 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.
>
> 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-japan mailing list
> Printing-japan@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-japan
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
2008-06-23 8:47 ` Osamu MIHARA
` (2 preceding siblings ...)
2008-06-23 21:50 ` Till Kamppeter
@ 2008-06-25 21:39 ` Till Kamppeter
2008-06-25 23:53 ` Olaf Meeuwissen
3 siblings, 1 reply; 7+ messages in thread
From: Till Kamppeter @ 2008-06-25 21:39 UTC (permalink / raw)
To: Osamu MIHARA; +Cc: printing-architecture, printing-japan
Thank you for the review of the specs. I have improved the specs and
given my comments below.
Osamu MIHARA wrote:
> (4) CPD Specification Review
> ----------------------------
[...]
> ==== PPD Extensions ====
> - Quick Presets
> The definition should be in formal matter such as BNF.
>
I think BNF is somewhat overkill for the mostly one-line expressions in
the PPD file. I have now added man-page-like syntax schemes with
descriptions of the elements.
> Need more explanation for each items, in special a) in Quick Presets
> (no one can understand relationship of a) and b)).
>
I have added an introduction telling what the quick preset buttons are.
To simplify, I have dropped a) now. If a driver developer wants to
control exactly one option with the quick preset buttons, he lets each
button only set that one option to a value appropriate to the button.
> Need detail explanation for Lecacy case
>
I have improved these explanations now.
> - Option Tagging
> Is it a MUST item? What happens for a PPD without tagging?
>
It is not a MUST. A legacy fallback based on the option groups as
proposed by the Adobe specs is provided. But using tags is highly
recommended.
> - Icons for options and chises
> Icons should be switched based on language settings.
>
As it is intended for now the icons should play more or less the role of
icons in the menus and toolbars of desktop applications. These are
pictograms without any text to be used with any language, so icon sets
for different languages are not needed.
Please tell me what you would like to put into icons and logos and why
you want to have the language-dependent?
Till
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan June Meeting Minutes
2008-06-25 21:39 ` Till Kamppeter
@ 2008-06-25 23:53 ` Olaf Meeuwissen
0 siblings, 0 replies; 7+ messages in thread
From: Olaf Meeuwissen @ 2008-06-25 23:53 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Osamu MIHARA, printing-japan
Till Kamppeter <till.kamppeter@gmail.com> writes:
> Osamu MIHARA wrote:
>
>> - Icons for options and chises
>> Icons should be switched based on language settings.
>
> As it is intended for now the icons should play more or less the role of
> icons in the menus and toolbars of desktop applications. These are
> pictograms without any text to be used with any language, so icon sets
> for different languages are not needed.
>
> Please tell me what you would like to put into icons and logos and why
> you want to have the language-dependent?
Maybe not so much language dependent but territory dependent. While
the hardware advertises itself as the same thing everywhere, things
like model name (as printed on the box) and icons may vary between
territories.
One example is the USB device with vendor/product ID: 04b8/083f. It
sold as a:
Epson Stylus CX4300
Epson Stylus CX4400
Epson Stylus CX5500
Epson Stylus CX5600
Epson Stylus DX4400
depending on where on earth you buy the thing. With respect to the
icons I do believe that this model uses different icons in different
territories as well. If this one doesn't, I have seen models that do
(but can't recall any names :-().
Hope this helps,
--
Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
^ permalink raw reply [flat|nested] 7+ messages in thread