[Printing-architecture] Posted OP SC Minutes - 14 Jan 2008

[Printing-architecture] Posted OP SC Minutes - 14 Jan 2008

[Ira McDonald]

Hi,

I just posted the minutes from today's Open Printing Steering Committee at:

 ftp://ftp.pwg.org/pub/pwg/fsg/steering_committee/OP-SC-Minutes-20080114.htm

Toratani-san sent a note about an internal conflict and will
send monthly status today or tomorrow - thanks.

Cheers,
- Ira
-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

Re: [Printing-architecture] Posted OP SC Minutes - 14 Jan 2008

[TORATANI Yasumasa]

Hi,

This is the OpenPrinting Japan f2f meeting outline notes;

---
OpenPrinting Japan f2f Meeting Outline

Date and Time
  10th Jan. 2008

Attendees
  Otani (BBR)
  Toratani (Canon)
  Olaf (EPSON Avasys)
  Miyata (EPSON Avasys)
  Sekiguchi (Konica Minolta)
  Saitoh (NEC Soft)
  Sakai (NEC Soft)
  Ogasawara (RICOH)
  Izumisawa (TLF Japan)

Agenda
- Check Action Items
- Common Printing Dialog
- LF OpenPrinting Meeting in Tokyo
- Compatibility Test
- pdftoraster and texttopdf

<Check Action Items>
- ppd options conflicts of Common Printing Dialog
    - Should check the current status and how this issue has been resolved.
      (because this issue has already been done on the TLF-OP page)
- IPA font issue on major applications
    - Waiting results from IPA
- OPVP rpc update
    - Under testing.
- New IPA(CJK) font announcement on the OPFC sourceforge page
    - Should be done by the next f2f meeting

<Common Printing Dialog>
- Comment from vendors
    - How the common dialog shows the ppd options conflict to users?
       (Not defined on the Peter's dialog)
      The current common printing dialog design is fine, but because
      the dialog has more complex features than the current GNOME
      or KDE print dialog, showing the conflict to users easily might be
      more difficult (If conflicts occur, message box are shown? Or
      some conflicts mark are shown on the dialog?)
    - Need the new ppd keyword for grouping items
       (Grouping keyword for each ppd options including vendor options)

<LF OpenPrinting Meeting in Tokyo>
- TLF-Japan suggested to have a TFL OpenPrinting f2f meeting Tokyo
   in 11th of Mar. if we have some agenda.
   - For instance, if the Common Printing Dialog Hacker's meeting in
      Europe will be held before the Tokyo meeting, and if we can see
      the prototype dialog working on PC, it can be a good agenda.
   - All vendors should bring other meeting agenda at the next Japan meeting.

<Compatibility Test>
- We read all the document Glen posted at the meeting, and confirmed
   that we agree on the basic concept of the document.

<pdftoraster and texttopdf>
- Currently we do not have any development resources for these filters.
   Under arranging, but will inform the result of it around Apr.

Next meeting
  7th of Feb. 2008

Re: [Printing-architecture] Posted OP SC Minutes - 14 Jan 2008

[Till Kamppeter]

Thank you for the report. More inline.

TORATANI Yasumasa wrote:
> <Check Action Items>
> - ppd options conflicts of Common Printing Dialog
>     - Should check the current status and how this issue has been resolved.
>       (because this issue has already been done on the TLF-OP page)
> - IPA font issue on major applications
>     - Waiting results from IPA
> - OPVP rpc update
>     - Under testing.
> - New IPA(CJK) font announcement on the OPFC sourceforge page
>     - Should be done by the next f2f meeting
> 
> <Common Printing Dialog>
> - Comment from vendors
>     - How the common dialog shows the ppd options conflict to users?
>        (Not defined on the Peter's dialog)
>       The current common printing dialog design is fine, but because
>       the dialog has more complex features than the current GNOME
>       or KDE print dialog, showing the conflict to users easily might be
>       more difficult (If conflicts occur, message box are shown? Or
>       some conflicts mark are shown on the dialog?)

See the section "the gray zone" on

http://www.mmiworks.net/eng/publications/labels/openPrinting.html

for the common printing dialog. Conflicting choices will get grayed out 
and by clicking an icon near a grayed out choice one gets info with 
which setting this choice conflicts.

XPP and KDE Print mark conflicting settings in red.

>     - Need the new ppd keyword for grouping items
>        (Grouping keyword for each ppd options including vendor options)
> 

I have already made suggestions about how to tag the options in PPDs and 
in the Foomatic XML data and also about how to generate the quick 
settings on the left of the dialog via PPDs and Foomatic. See my 
suggestions which I e-mailed to OpenUsability people below.

> <LF OpenPrinting Meeting in Tokyo>
> - TLF-Japan suggested to have a TFL OpenPrinting f2f meeting Tokyo
>    in 11th of Mar. if we have some agenda.
>    - For instance, if the Common Printing Dialog Hacker's meeting in
>       Europe will be held before the Tokyo meeting, and if we can see
>       the prototype dialog working on PC, it can be a good agenda.

As Peter Sikking had no student in the time after the Montreal Printing 
Summit up to now, we have postpond the Hacker kick-off meeting to May. 
He will have a new student from February 1 on and this student will work 
on the spec. I will add PPD and Foomatic extensions as suggested below.

Peter also told that he will prepare something for me to show in Tokyo 
in  March.

As another agenda item I will demo automatic printer driver download 
from OpenPrinting with system-config-printer.

>    - All vendors should bring other meeting agenda at the next Japan meeting.
> 
> <pdftoraster and texttopdf>
> - Currently we do not have any development resources for these filters.
>    Under arranging, but will inform the result of it around Apr.
>

Should I perhaps ask the Linux Foundation for opening another internship 
so that a student can work on the missing CUPS filters? Who should be 
this student's supervisor then? OP Japan? Mike Sweet? Me?

    Till

--------------------------------------------------------------------

Very important is the draft specification, especially what PPD 
extensions are needed. As far as I have seen the current design, we need

- to tag the options: Every user-visible option in the PPD (with 
*OpenUI...*CloseUI) should get a line/lines added which holds one or 
more tags. Example:

*OPUITags: "
PaperHandling/Paper Handling
ResourceSaving/Resource Saving"
*End

Note that we also need to find a concept for the translation in 
multi-language PPDs ("Globalized PPD Support" on 
http://www.cups.org/documentation.php/spec-ppd.html, PPDs which come 
with CUPS 1.3.x).

For backward compatibility: If the options in a PPD are not tagged, the 
groups will be used as tags, but then the tags will act like tabs and so 
not give all their functionality.

For PPDs built from the Foomatic database, new XML markup for tagging 
the options is needed, for example:

<tags>
   <tag id="PaperHandling">
      <en>Paper Handling</en>
   </tag>
   <tag id="ResourceSaving">
      <en>Resource Saving</en>
   </tag>
</tags>

- to define the "Quick Presets": Several Foomatic-generated PPDs have an 
option named "PrintoutMode" which has usually settings like "Draft". 
"Normal Quality", "Photo", ... (Gutenprint IJS driver, HPIJS, ...). This 
option has the same intention as the "Quick Presets". It sets several 
other options to quickly set up the printer for a common printing task. 
  So I suggest that for generating the "Quick Presets" buttons the PPD 
is searched for an option named "QuickPresets" and if such an option 
does not exist it is searched for "PrintoutMode" for backward 
compatibility. The choices of this option are shown as the "Quick 
Presets" buttons and the option is not shown under the tags.

In Foomatic PPDs this option is a composite option which describes which 
of the other option it sets in which way and foomatic-rip takes care of 
the correct execution. For PPDs for PostScript printers I recommend that 
one codes up the appropriate functionality in PostScript and for CUPS 
raster drivers the handling should be done in the rastertoXXX executable.