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

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

[Osamu MIHARA]

Hi, This is part one of translation of meeting minutes.
Please wait for the part two until next Monday or Tuesday or...
-----------------------------------------------------------------

OPWG-J Meeting Minutes (June 2008)

June 19, 2008, 14:3-18:30 (JST)
The Linux Foundation Japan Meeting Room

Participants
------------
Kunai-san (TLF)
Olaf-san, Miyata-san (Avasys)
Otani-san (BBR)
Sekiguchi-san (Konica Minorura)
Ogasawara-san, Chigusa-san (Ricoh)
Toratani-san (Canon)
Saito-san (NEC Soft)
Mihara (Fuji Xerox)


Agenda
------
(1) Action Items
(2) Some issue in PDF filter configuration
(3) Agenda for OpenPrinting/LF Japan Symposium Tokyo (July 8th)
(4) CPD Specification Review
(5) Implementation of Printer Management Standard (PWG/OPWG Co'op) -
postponed to next meeting due to timeout.


(1) Action Items
-----------------
o Procedure for the formalization of specs.
  -> Done.  Glen has updated the procedure document and announce to ML.

o Translation of  readme/install of pdftoraster
  -> Done.

o Release source code of pdf filters to Mike
  -> Done

o Give proposal of RPC code for opvp
  -> Done.  Both of 0.2 and 1.0 can be supported at the same time.
     Toratani-san will prepare for release of sample code.

o Post comments for Distribution Independend Driver Package (DDK)
  -> Saito-san has posted 2 bugs to Bugzilla and Till has already fixed
them.
  -> There is a search path problem because the driver executives and
libraries are installed under /opt.

    - Adding the vendor specific path to PATH and LD_LIBRARY_PATH will
      not solve the naming conflicts, which "/opt proposal" will try
       to solve.
       Same can be said for making symbolic links under /usr.
       (If two vendors happen to use same file name for their
        executables or libraries, we can not expect which one is used.)
    - paths for filters and libraries should be described in PPD file.
       A keyword for filter path is already defined.
       Vendors can define vendor specific keyword for library path,
       if they need their own library path.

o Post the Austin report presentation.
    -> done

o Post comments on CPD to ML
    -> done

o Request comment on the posting about LSB, again.
    -> Done
    -> There is a comment on PPD path (should be defined in LSB),
        as it is not included in LSB 3.2
    -> SANE 1.0 seems to be included in next LSB.

o Participate SC meeting
    -> Done


(2) PDF Filters issue
----------------------
Problem ONE:
Currently PDF filters SRPM includes source code of poppler for each
distributions, because PDF filters depends on poppler *internal*
functions, which cannot be used even if -dev package of poppler is
installed.  This causes source code management problem as we need
prepare SRPMS customized for distro by distro.

-> Libpoppler can be linked statically, but configuraion and cmap files
can be redundant.

-> It may cause problem if pdf filters are commited into poppler source
code tree.  It is because pdf filters are application and poppler is a
library project and they have completely different type of projects.

==> Solution: Take stable version of poppler and make a package of
libpoppler dedicated for pdf filters.  (It's not a fork. No modification
on poppler.  Just use it)

Problem TWO: (from discussion with Otani-san and Till-san)
PostScript output from Adobe Reader 8 cannot be converted to PDF by
pstopdf.  It happens with PDFs with printing permission but no other
permissions.

-> If printing out to PS printer, it will cause problems if PS (from
Acrobate) is once converted to PDF.  So "pstopdf" may not be needed.

-> If this problem is discussed on a assumption to add penalties for an
application which can generate only postscript to printing, it
shouldn't.  The promotion of PDF workflow should be done by adding
merits on it compared to current ps workflow.

-> We also need to provide way to PDF job control to CPD api.


(3) Agenda for OpenPrinting/LF Japan Symposium Tokyo (July 8th)
----------------------------------------------------------------
- Main discussion will be on CPD spec. (some hours)
- Discussion on transition promotion to PDF printing workflow
   -> What's we need to provide?
      What is missing?
      What kind of merits we can append?

(4) CPD Specification Review
----------------------------
(5) Others
----------------------------

(((Translation will be later.)))


// Osamu Mihara

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

[Osamu MIHARA]

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

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

[Lars Uebernickel]

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

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

[Till Kamppeter]

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
> 

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

[Till Kamppeter]

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
> 

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

[Till Kamppeter]

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

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

[Olaf Meeuwissen]

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/