[Printing-architecture] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Printing-architecture] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[TORATANI Yasumasa]

OpenPrinting Mar. f2f Meeting Minutes

Date and Time: 14:30-18:30 on Mar.4th, 2010
Meeting Place: The Linux Foundation Tokyo Office

Attendees:
  Kunai (The Linux Foundation), Chigusa (Ricoh), Olaf (Avasys)
  Ohtani (BBR), Miyata (Canon), Toratani (Canon, minutes taker)

Agenda:
1) Confirm the progress of action items
2) Report of the US/EU/Japan joint telecon held on Mar.
3) Printing Summit
4) Items to be developed during the next GSoC project
5) LINUXCON Tokyo plan
6) CUPS bugs related to "cupsCommand" keyword


1) Confirm the progress of action items

Action Item #1) Check CPD current status
  - Tried to compile on Debian Stable, but failed (Olaf)
  - Tried to build on Ubuntu9.10 and succeed. Level 2 feature has
    already implemented on GNOME version, but not yet Level 3.
  - Shared the info. that CPD will not be supported on the next
    Ubuntu LTS release.
  - Comments from attendees are as following;
      - For most office use, Level 3 features are not needed.
      - For the CPD first step release, it's better that development
         resources focus on Level 2 implementation (for instanse
         test with some applications) than to develop Level 3 feature.

Action Item #2) Raise examples JobTicket attributes which should be
                     dealt par page (Except page size and rotation)
  - Coat paper for particular color image page, and plain paper for other.
  - Simplex for cover page, duplex for other
  - Folding particular page

Action Item #3) Comment to the translated OpenPrinting page
  - No one have comments

2) Report of the US/EU/Japan joint telecon held on Mar.

  - Continue Vector API approval process
  - Level 2 has been implemetend on CPD, but not yet Level 3 due to
    short and slow funding
  - Collect GSoC development item for OpenPrinting
  - Telecon requirement from Japan for Printing Summit

3) Printing Summit

  - Parson from EPSON US and RICOH US will participate in the meeting
  - Need to call from Japan
      - If the agenda includes SANE (Olaf)
      - If the agenda includes NetBook Printing (Miyata, Toratani)

  - Comment to agenda
      - Demonstrations and Screenshots
          - Hope to see the demonstration streaming or movies if possible

      - CUPS Raster Driver in Ghostscript maintenance
          - Few maintainer for Ghostscript CUPS raster driver? *1

      - CUPS Status
          - CUPS 1.4 topic? or something new? *2

4) Items to be developed during the next GSoC project
  - Implement CPD with major applications (OpenOffice, Firefox)
  - NetBook Printing sample printer driver

5) LINUXCON Tokyo plan
  - Will be held since 27th Sept until 29th in Tokyo

6) CUPS bugs related to "cupsCommand" keyword
  - We think that the following "cupsCommand" spec is not preferable, and
     if a PPD does not contain "cupsCommand" keyword, it should be dealt
     that the printer driver defined by the PPD does not support
     "cupsCommand" features.

    http://www.cups.org/documentation.php/doc-1.4/spec-command.html
    "If no cupsCommands keyword is provided, the command filter must support
    AutoConfigure, Clean, PrintSelfTestPage, and ReportLevels"

  - Can this spec be changed in CUPS 1.5?  *3

Action Item:
Mihara:  Define Vector API approval dead line
All:  Post more GSoC idea if have
Toratani: Confirm *1, *2 and *3 with Till (by this minutes)

Next:
  8th Apr, 2010 14:30- at The Linux Foundation Tokyo office

-----------------------------------------
TORATANI Yasumasa
Software Platform Technology Development Dept. 33
Digital Platform Technology Development HQs, CANON INC.

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Till Kamppeter]

Toratani-san, thank you for the quick translation.

Comments inline below.

    Till

On 03/05/2010 03:09 AM, TORATANI Yasumasa wrote:
> OpenPrinting Mar. f2f Meeting Minutes
>
> Date and Time: 14:30-18:30 on Mar.4th, 2010
> Meeting Place: The Linux Foundation Tokyo Office
>
> Attendees:
>    Kunai (The Linux Foundation), Chigusa (Ricoh), Olaf (Avasys)
>    Ohtani (BBR), Miyata (Canon), Toratani (Canon, minutes taker)
>
> Agenda:
> 1) Confirm the progress of action items
> 2) Report of the US/EU/Japan joint telecon held on Mar.
> 3) Printing Summit
> 4) Items to be developed during the next GSoC project
> 5) LINUXCON Tokyo plan
> 6) CUPS bugs related to "cupsCommand" keyword
>
>
> 1) Confirm the progress of action items
>
> Action Item #1) Check CPD current status
>    - Tried to compile on Debian Stable, but failed (Olaf)

Olaf, please send a mail with the errors to me and to Lars Uebernickel 
(larsuebernickel@gmx.de).

>    - Tried to build on Ubuntu9.10 and succeed. Level 2 feature has
>      already implemented on GNOME version, but not yet Level 3.

The actual state is:

The GNOME version was brought very far in last year's Google Summer of 
Code. Level 3 was implemented. Missing is the size and some layout 
issues are still to solve.

The Qt dialog has a completely implemented level 2, recently finished by 
Lars Uebernickel, financed by a German federal government agency. For 
level 3 there are only code pieces which are not activated currently.

>    - Shared the info. that CPD will not be supported on the next
>      Ubuntu LTS release.

Ubuntu 10.10 at the earliest, but only if we get enough man power. I 
asked Canonical whether they help funding (no answer yet). I also posted 
a GSoC project idea for patching toolkits and applications.

>    - Comments from attendees are as following;
>        - For most office use, Level 3 features are not needed.
>        - For the CPD first step release, it's better that development
>           resources focus on Level 2 implementation (for instanse
>           test with some applications) than to develop Level 3 feature.
>

We will have to release with level 3, as access to the PPD options was 
available before and removing this feature would be a regression.

> Action Item #2) Raise examples JobTicket attributes which should be
>                       dealt par page (Except page size and rotation)
>    - Coat paper for particular color image page, and plain paper for other.
>    - Simplex for cover page, duplex for other
>    - Folding particular page
>
> Action Item #3) Comment to the translated OpenPrinting page
>    - No one have comments
>
> 2) Report of the US/EU/Japan joint telecon held on Mar.
>
>    - Continue Vector API approval process
>    - Level 2 has been implemetend on CPD, but not yet Level 3 due to
>      short and slow funding
>    - Collect GSoC development item for OpenPrinting
>    - Telecon requirement from Japan for Printing Summit
>
> 3) Printing Summit
>
>    - Parson from EPSON US and RICOH US will participate in the meeting
>    - Need to call from Japan
>        - If the agenda includes SANE (Olaf)
>        - If the agenda includes NetBook Printing (Miyata, Toratani)
>

For call-in from Japan I have set up an evening session on Thursday 
April 15. This falls into the morning in Japan.

>    - Comment to agenda
>        - Demonstrations and Screenshots
>            - Hope to see the demonstration streaming or movies if possible
>

Demos of the Common Printing Dialog will be done with the real 
implementations of it. For call-in participants I can perhaps make a 
Ubuntu package so that one can boot a Ubuntu live CD and then install 
the package to try out the dialog.

>        - CUPS Raster Driver in Ghostscript maintenance
>            - Few maintainer for Ghostscript CUPS raster driver? *1
>

The problem occurred when ESP Ghostscript got merged into GPL 
Ghostscript. Since then Mike Sweet did not do any maintenance work on 
the CUPS Raster output device any more. I have fixed many bugs in it in 
the time up to now, but as I am not a Ghostscript expert I did not 
succeed to fix all bugs. The Ghostscript developers at Artifex do no do 
much on this driver, too.

It would be great if someone could help here. CUPS Raster is one of the 
three standard printer driver architectures (standardized in the LSB).

>        - CUPS Status
>            - CUPS 1.4 topic? or something new? *2
>

This session will be held by Mike Sweet, it is as in the previous years 
mainly planned development for the next version (1.5).

> 4) Items to be developed during the next GSoC project
>    - Implement CPD with major applications (OpenOffice, Firefox)
>    - NetBook Printing sample printer driver
>

Netbook printer driver are not planned for GSoC. What is planned is to 
have a session about netbook printing on the OpenPrinting Summit.

> 5) LINUXCON Tokyo plan
>    - Will be held since 27th Sept until 29th in Tokyo
>

Could also be an opportunity to couple a printer driver tutorial for the 
Japanese manufacturers.

> 6) CUPS bugs related to "cupsCommand" keyword
>    - We think that the following "cupsCommand" spec is not preferable, and
>       if a PPD does not contain "cupsCommand" keyword, it should be dealt
>       that the printer driver defined by the PPD does not support
>       "cupsCommand" features.
>
>      http://www.cups.org/documentation.php/doc-1.4/spec-command.html
>      "If no cupsCommands keyword is provided, the command filter must support
>      AutoConfigure, Clean, PrintSelfTestPage, and ReportLevels"
>
>    - Can this spec be changed in CUPS 1.5?  *3
>

Probably yes, and I think we should change it. There are a lot of 
printers (especially laser printers) which do not have all these for 
hardware features implemented.

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Olaf Meeuwissen]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Till,

Till Kamppeter wrote:

> On 03/05/2010 03:09 AM, TORATANI Yasumasa wrote:
>> OpenPrinting Mar. f2f Meeting Minutes
>>
>> Action Item #1) Check CPD current status
>>    - Tried to compile on Debian Stable, but failed (Olaf)
> 
> Olaf, please send a mail with the errors to me and to Lars Uebernickel 
> (larsuebernickel@gmx.de).

The compile errors are due to the dialog using GTK+ API that is not yet
available in the versions that are in Debian GNU/Linux 5.0.4, the latest
stable release.  This release only has GTK+ 2.12 (and GLib 2.16).
A new Debian release should come out this year and will have at least
GTK+ 2.18 (GLib 2.22).

Whether you want to fix that basically boils down to what minimal
version of GTK+ you want to go with so I'll leave that up to you.

What I would suggest fixing though, is documenting/checking/enforcing
your build requirements.

Just in case, a `make -k` build log for r137 has been attached.

Hope this helps,
- --
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuUO3QACgkQt5qrxaZLMnJsHQCfS988n0ZeQoLejXqzwSSaeZy9
dhAAn1dlz5LD1CARbgvSoJ0tyAG0vs0Y
=Mv8p
-----END PGP SIGNATURE-----

[-- Attachment #2: gtk-dialog-r137.log --]
[-- Type: text/x-log, Size: 3216 bytes --]

Generating manager-glue.h from ../org.openprinting.printdialog.manager.xml
Generating printdialog-glue.h from ../org.openprinting.printdialog.printdialog.xml
Checking for "gtk+-2.0 poppler-glib cairo dbus-glib-1"
Checking for CUPS
Checking for "gtk+-2.0 poppler-glib cairo dbus-glib-1"
Checking for CUPS
Compiling cpd.c
Compiling manager.c
Compiling manager-net.c
Compiling printdialog-adapter.c
Compiling cpd-options.c
Compiling cpd-cups.c
Compiling cpd-cups-ipp.c
cpd-cups-ipp.c: In function 'start_element':
cpd-cups-ipp.c:81: warning: implicit declaration of function 'g_markup_parse_context_push'
cpd-cups-ipp.c: In function 'end_element':
cpd-cups-ipp.c:92: warning: implicit declaration of function 'g_markup_parse_context_pop'
Compiling cpd-transform.c
Compiling cpd-settings.c
Compiling printdialog.c
printdialog.c: In function 'print_dialog_display_ppd':
printdialog.c:424: error: 'GFile' undeclared (first use in this function)
printdialog.c:424: error: (Each undeclared identifier is reported only once
printdialog.c:424: error: for each function it appears in.)
printdialog.c:424: error: 'gfile' undeclared (first use in this function)
printdialog.c:424: warning: implicit declaration of function 'g_file_new_for_path'
printdialog.c:425: warning: implicit declaration of function 'g_file_get_basename'
printdialog.c:425: warning: assignment makes pointer from integer without a cast
make: *** [printdialog.o] Error 1
Compiling dialog-options.c
Compiling dialog-optioneditors.c
dialog-optioneditors.c: In function 'color_button_clicked':
dialog-optioneditors.c:1754: warning: implicit declaration of function 'gtk_color_selection_dialog_get_color_selection'
dialog-optioneditors.c:1754: warning: cast to pointer from integer of different size
dialog-optioneditors.c: In function 'calendar_button_clicked':
dialog-optioneditors.c:1793: warning: implicit declaration of function 'gtk_dialog_get_content_area'
dialog-optioneditors.c:1793: warning: cast to pointer from integer of different size
Compiling dialog-optiontable.c
Compiling dialog-pagesize.c
Compiling dialog-pagerange.c
Compiling dialog-preset.c
dialog-preset.c: In function 'save_preset_clicked':
dialog-preset.c:439: warning: implicit declaration of function 'gtk_dialog_get_content_area'
dialog-preset.c:439: warning: assignment makes pointer from integer without a cast
Compiling dialog-progress.c
dialog-progress.c: In function 'dialog_progress_static_get_password':
dialog-progress.c:106: warning: implicit declaration of function 'gtk_dialog_get_content_area'
dialog-progress.c:106: warning: assignment makes pointer from integer without a cast
Compiling dialog-preview.c
Generating cpd.ui from cpd.glade
Generating progressdlg.ui from progressdlg.glade
cc -g -Wall -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include     -c -o view-dialog.o view-dialog.c
make: Target `all' not remade because of errors.

[-- Attachment #3: gtk-dialog-r137.log.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Till Kamppeter]

On 03/08/2010 12:49 AM, Olaf Meeuwissen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Till,
>
> Till Kamppeter wrote:
>
>> On 03/05/2010 03:09 AM, TORATANI Yasumasa wrote:
>>> OpenPrinting Mar. f2f Meeting Minutes
>>>
>>> Action Item #1) Check CPD current status
>>>     - Tried to compile on Debian Stable, but failed (Olaf)
>>
>> Olaf, please send a mail with the errors to me and to Lars Uebernickel
>> (larsuebernickel@gmx.de).
>
> The compile errors are due to the dialog using GTK+ API that is not yet
> available in the versions that are in Debian GNU/Linux 5.0.4, the latest
> stable release.  This release only has GTK+ 2.12 (and GLib 2.16).
> A new Debian release should come out this year and will have at least
> GTK+ 2.18 (GLib 2.22).
>
> Whether you want to fix that basically boils down to what minimal
> version of GTK+ you want to go with so I'll leave that up to you.
>
> What I would suggest fixing though, is documenting/checking/enforcing
> your build requirements.
>
> Just in case, a `make -k` build log for r137 has been attached.

Lars, can you update the documentation of the dialog package (README, 
...) telling which versions of libraries are exactly needed for the dialog?

Olaf, can you try with a newer distribution, like Ubuntu Karmic or newer?

    Till

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Per Hermansson]

On 2010-03-14 15:12, Till Kamppeter wrote:
>> The compile errors are due to the dialog using GTK+ API that is not yet
>> available in the versions that are in Debian GNU/Linux 5.0.4, the latest
>> stable release.  This release only has GTK+ 2.12 (and GLib 2.16).
>> A new Debian release should come out this year and will have at least
>> GTK+ 2.18 (GLib 2.22).
>>
>> Whether you want to fix that basically boils down to what minimal
>> version of GTK+ you want to go with so I'll leave that up to you.
>>
>> What I would suggest fixing though, is documenting/checking/enforcing
>> your build requirements.
>>
>> Just in case, a `make -k` build log for r137 has been attached.
>>      
> Lars, can you update the documentation of the dialog package (README,
> ...) telling which versions of libraries are exactly needed for the dialog?
>
> Olaf, can you try with a newer distribution, like Ubuntu Karmic or newer?
>
>      Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>    

Hi all
I merged a fix that removes the reference to GFile with 
g_path_get_basename which seems to exist in GLib 2.16
so that compile error shouldn't exist anymore.
Hopefully it works with 2.16 now, but I haven't tested it.

/Per Hermansson

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Till Kamppeter]

On 03/14/2010 05:23 PM, Per Hermansson wrote:
> Hi all
> I merged a fix that removes the reference to GFile with
> g_path_get_basename which seems to exist in GLib 2.16
> so that compile error shouldn't exist anymore.
> Hopefully it works with 2.16 now, but I haven't tested it.
>
> /Per Hermansson
>

Per, thank you very much. For me it still compiles on Lucid.

    Till

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Olaf Meeuwissen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per Hermansson wrote:

> Hi all
> I merged a fix that removes the reference to GFile with
> g_path_get_basename which seems to exist in GLib 2.16

It does but you need to link against libgio to get it.  At leas on my
system `pkg-config --libs` does _not_ include that.  Looks like you need
to add `gio` to the list of `packages` in the Makefile if you really
want it.

> so that compile error shouldn't exist anymore.
> Hopefully it works with 2.16 now, but I haven't tested it.

It's gone on Debian 5.0.4.

Hope this helps,
- --
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkudfCsACgkQt5qrxaZLMnIxaQCgkDaCO0KDguGxlKyWGlN5/jUt
GY0An36zAC288z/v5R/bd0D8928iXOAY
=rxU9
-----END PGP SIGNATURE-----

Re: [Printing-architecture] [Printing-japan] OpenPrinting Japan Mar. 2010 meeting minutes (in English)

[Olaf Meeuwissen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Till Kamppeter wrote:

> Lars, can you update the documentation of the dialog package (README,
> ...) telling which versions of libraries are exactly needed for the dialog?
> 
> Olaf, can you try with a newer distribution, like Ubuntu Karmic or newer?

Apart from a format and unused variable warning, r144 compiles fine on
Karmic.
- --
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkudfDoACgkQt5qrxaZLMnKswwCcCV6XJAz7oVqPx9SaoQrqo9D7
FGoAoLU2joypGKFu0GQNYb5nzyw6avCY
=jKgf
-----END PGP SIGNATURE-----

[Printing-architecture] Problem with cupsCommand

[Till Kamppeter]

On 03/05/2010 03:09 AM, TORATANI Yasumasa wrote:
> 6) CUPS bugs related to "cupsCommand" keyword
>    - We think that the following "cupsCommand" spec is not preferable, and
>       if a PPD does not contain "cupsCommand" keyword, it should be dealt
>       that the printer driver defined by the PPD does not support
>       "cupsCommand" features.
>
>      http://www.cups.org/documentation.php/doc-1.4/spec-command.html
>      "If no cupsCommands keyword is provided, the command filter must support
>      AutoConfigure, Clean, PrintSelfTestPage, and ReportLevels"
>
>    - Can this spec be changed in CUPS 1.5?  *3

The problem is less the cupsCommands keyword and the defaults which are 
used if cupsCommands is not supplied, the problem is more that if a 
'*cupsFilter:' line like

*cupsFilter:    "application/vnd.cups-postscript 100 pstopxl"

is supplied and no 'cupsCommands' attribute that the 
CUPS_PRINTER_COMMANDS bit is set for the printer-type attribute. This 
makes client applications assume that the printer supports CUPS commands 
via the standard command filter commandtops. See

http://www.cups.org/str.php?L3273

But on the other side I have tested with a lot of print queues and found 
out that only for native PostScript printers (no *cupsFilter line) and 
for printers with explicit *cupsFilter line for a command filter in the 
PPD support the application/vnd.cups-command input format (according to 
error_log messages on daemon startup or queue creation, having set 
LogLevel=debug2). A queue with the pstopxl filter from Ghostscript (Tim, 
this is the case you reported in the CUPS bug report) is reported as not 
supporting application/vnd.cups-command.

So a client should perhaps better check for available input formats and 
ignore the CUPS_PRINTER_COMMANDS bit. Tim, please test (you could try to 
send a status check to the printer and see if a "data format not 
supported error gets reported").

    Till

Re: [Printing-architecture] Problem with cupsCommand

[Till Kamppeter]

On 03/05/2010 06:21 PM, Tim Waugh wrote:
> On Fri, 2010-03-05 at 17:36 +0100, Till Kamppeter wrote:
>> But on the other side I have tested with a lot of print queues and found
>> out that only for native PostScript printers (no *cupsFilter line) and
>> for printers with explicit *cupsFilter line for a command filter in the
>> PPD support the application/vnd.cups-command input format
>
> That's not what I'm seeing.  e.g. with a CUPS-1.4.2 server with a queue
> for "HP PSC 2210 Foomatic/hpijs", advertising the queue using CUPS
> browsing packets, and a CUPS-1.4.2 client discovering that queue, the
> client says it supports application/vnd.cups-command (even though the
> server does not).

My tests were only on one machine, I did not check how the queues get 
advertized on remote clients. What I expect is that on a remote client 
EXACTLY the same input data types are accepted, as all the filtering 
happens on the server. If this is not the case, then you should report a 
CUPS bug. Best is you now report a new bug telling that the range of 
accepted data types on server and client is different, once supporting 
application/vnd.cups-command and once not supporting it.

    Till