[Printing-architecture] LF Collaboration Summit Open Printing Minutes from Glen Petrie

[Printing-architecture] LF Collaboration Summit Open Printing Minutes from Glen Petrie

[Petrie, Glen]

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

 

Open Printing Minutes from Glen Petrie

 

Other people who attended the summit should make additions/correction were
needed

 

Action Items from desktop group:

 

1.	Define a specification for machine readable print setting at the
doc, app and desktop level.
2.	Define a set of simple top level state/status indicators for top
level of the Common Print Dialog.

 

 

9:15 am Introductions (Till, George, Glen, Fumio,  David)

============

Status Report from Till

--- Till discussion of GSOC 

      --- 8 students for LF  (5 for Open Printing)

           ---- 1-2:  Gnome and KDE for Print Dialog

           ---- 1:  JTAPI Implementation

           ---- 1: PAPI support 

           ---- 1:  Add modules to ????

           ---- 1:  Modularization of GhostScript

--- Lars if working Foomatic RIP in C (currently in PERL) to allow
connectivity to libraries and to improve performance.  Also, Processing PDF
for integration into CUPS

-- (CUPS computes a cost factor of the best way to print the job.)

-- It will be possible to have more than one command line to support PDF/PS.
--- Foomatic RIP is used for non-PDF/PS printers but is also used to add
print-time information (who, time, date, security)

-- CUPS is not supporting Custom-Options 

=========

- The common printing dialog is the desktop level with at interface to
applications.  Vendor options are put in the PPD extensions. 

-- The Common Print Dialog is dependent upon CUPS and vendor options are
done from PPD extension (via CUPS custom-options) or by APDialogExtensions
API.

-- George concern how the applications will invoke the common print dialog,
he feels this should be done first before worrying about the actual dialog
looks.

--- Glen is worried of extensibility of the dialog for manufacture.

-- Should application be able to restrict options?

 

--- Next Steps

   --- Define the App - to - common dialog interface

        --- Needs to be bi-dir

        --- Application to able constraint option

        --- Application to add their own options

        --- Printer Manufacture add their own options

   --- Define print manufacture to common dialog interface

       --- Done by PPD extensions - Till has a preliminary set of options

            ---  This is only mechanism to get extensions by adding new data
types.

       --- Future will have a mechanism for vendors to have binaries.   The
discussion was to extend the PPD to support this. 

--- A good summer project is support CUPS Web interface.

-- Foomatic extensions are different that CUPS but can use both.

 

GSOC projects are now

1.	Print dialog

a.	GUI dialog
b.	CUPS Extension /Web Interface  -- Lars [Till]
c.	Application Interface (API)Demonstration

2.	PAPI
3.	JTAPI - Dropped
4.	PDF Work : PDF to IJS,  Text to PDF

 

============

 

Slides from Japan

--- Version 1.0 of OPVP available for review

---  Implementation and driver testing completed   (NEC and Canon Drivers
have been tested)

(What license is OPVP and the driver from manufactures.)

 

============

 

11:50 am   Printing on the Desktop

 

Subject: Common Printing Dialog (CPD)

-- There should only be one dialog for all applications

-- The CPD should be part of the Gnome/KDE/Other? Desktops

-- Called using DBUS <--- Is this the best interface to applications.

 

= Like in Windows, there was an expressed desire for remembering print
setting at the desktop level, the application level and the document level.

-- Thus the desktop group is looking for a machine readable definition
(specification) of print settings.

 

= Want the CPD to have a state/status tab.

-- After some discussion, what the desktop people also wanted was some very
simple indicators in the main CPD window showing the "status" ("state",
"condition", "readiness", "busyness") of the printer.   That is, they want
to know that the printer is really ready/available for printing.  Is the
printer out of ink, is the print out of paper, is the printer busy, is the
printer online.   The idea was that the indicators are simple colored boxes.
For example, a box for ink-level is green if ink/toner level is ok, blue if
ink/toner low, red if ink/toner out.  Same for the other status items.  The
user could go to the state/status tab if they need more information.

 

= The desktop group would like to see the CPD be a plug-in solution versus a
separate process. 

 

= The CPD should not define it own basic display parameters such as font,
color, etc.  These should be inherited from the Desktop the CPD is running
on.

 

=========

 

 


[-- Attachment #2: Type: text/html, Size: 19326 bytes --]

Re: [Printing-architecture] LF Collaboration Summit Open Printing Minutes from Glen Petrie

[Till Kamppeter]

Petrie, Glen wrote:
> Action Items from desktop group:
>    1. Define a specification for machine readable print setting at the
>       doc, app and desktop level.

      Will be part of Lars' GSoC work on the application/printing dialog
      interface

>    2. Define a set of simple top level state/status indicators for top
>       level of the Common Print Dialog.

      We will tell Lars and Alex Wauck (implementation of the dialog
      itself in the GSoC) about taking into account this,

> 9:15 am Introductions (Till, George, Glen, Fumio,  David)
> 
> ============
> 
> Status Report from Till
> 
> --- Till discussion of GSOC
> 
>       --- 8 students for LF  (5 for Open Printing)
> 
>            ---- 1-2:  Gnome and KDE for Print Dialog
> 
>            ---- 1:  JTAPI Implementation
> 
>            ---- 1: PAPI support
> 
>            ---- 1:  Add modules to ????
> 
>            ---- 1:  Modularization of GhostScript
> 
> --- Lars is working on Foomatic RIP in C (currently in PERL) to allow 
> connectivity to libraries and to improve performance.  Also, Processing 
> PDF for integration into CUPS
> 
> -- (CUPS computes a cost factor of the best way to print the job.)
> 

      This way one can simply add filters and conversion rules to an
      installed CUPS and a PDF workflow will be preferably done.

> -- It will be possible to have more than one command line to support 
> PDF/PS.

      This way the new foomatic-rip will not require a PDF workflow.

> -- Foomatic RIP is used for non-PDF/PS printers but is also 
> used to add print-time information (who, time, date, security)
> 

     As currently done for Ricoh PostScript printers

> -- CUPS is not supporting Custom-Options
> 

    CUPS in general supports them (if anything special is needed in the
    CUPS daemon), but the web interface of CUPS (the only GUI which comes
    with CUPS) does not support them.

    Lars Uebernickel has done a patch for the web interface of CUPS to
    correct this. See http://www.cups.org/str.php?L2807

    He needed one night for that.

> =========
> 
> - The common printing dialog is the desktop level with at interface to 
> applications.  Vendor options are put in the PPD extensions.
> 
> -- The Common Print Dialog is dependent upon CUPS and vendor options are 
> done from PPD extension (via CUPS custom-options) or by 
> APDialogExtensions API.
> 

- CUPS custom options
- Special keywords to assign tags to the options
- Marking one option to represent the quick selection buttons of the
   standard view of the dialog
- UU-encoded icons for options and choices

> -- George concern how the applications will invoke the common print 
> dialog, he feels this should be done first before worrying about the 
> actual dialog looks.
>

There will be one GSoC student concentrated on modularizing the printing 
dialog, Lars Uebernickel. He will make an interface to make the dialog 
exchangeable, so that the desktop can provide one and the same dialog 
for all applications. This dialog does not need to be Peter Sikking's 
design necessarily, it can also be the desktop's native dialog for example.

> --- Glen is worried of extensibility of the dialog for manufacture.
>

Manufacturer extensions cannot be done by means of executable code, as 
printer drivers run on the server and server and client can be different 
architectures. Manufacturer extensions can only be done by PPD options, 
the custom options of CUPS allow extended data formats.

> -- Should application be able to restrict options?
>

This is a good idea, will pass it on to the GSoC students who will work 
on the dialog.

> --- Next Steps
> 
>    --- Define the App – to – common dialog interface
>

This will be Lars' task in the Google Summer of Code

>         --- Needs to be bi-dir
> 

- Dialog reports back the settings of application-specific options, so 
that the app can re-generate the PDF for the dialog to update preview.

- Dialog reports back all option settings when user clicks "Print", so 
that app can save them in the document.

>         --- Application to able constraint option
> 

- For example if a specialized app can only produce a few given page sizes.

>         --- Application to add their own options
> 

- Like "Print with Background Graphics" in a browser. See also the 
current print dialog of KDE.

>         --- Printer Manufacture add their own options
> 

- PPD options.

>    --- Define print manufacture to common dialog interface
> 
>        --- Done by PPD extensions – Till has a preliminary set of options
> 

- CUPS custom options
- Special keywords to assign tags to the options
- Marking one option to represent the quick selection buttons of the
   standard view of the dialog
- UU-encoded icons for options and choices

>             ---  This is only mechanism to get extensions by adding new 
> data types.
> 
>        --- Future will have a mechanism for vendors to have binaries.   
> The discussion was to extend the PPD to support this.
 >
> --- A good summer project is support CUPS Web interface.
>

To small for a Google Summer of Code project. Lars Uebernickel is 
already on it. See

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

> -- Foomatic extensions are different that CUPS but can use both.
> 
> GSOC projects are now
> 
>    1. Print dialog
>          1. GUI dialog
>          2. CUPS Extension /Web Interface  -- Lars [Till]
>          3. Application Interface (API)Demonstration
>    2. PAPI
>    3. JTAPI – Dropped
>    4. PDF Work : PDF to IJS,  Text to PDF
>

Update on GSoC projects:

1. Common Printing Dialog: Implementation of OpenUsability design
2. Common Printing Dialog: App/dialog interface
3. Implementation of PAPI in CUPS
4. utf8topdf and pdftoijs CUPS filters for PDF workflow
5. Web app for triaging user contributions to the OpenPrinting database

> 
> ============
> 
>  
> 
> Slides from Japan
> 
> --- Version 1.0 of OPVP available for review
> 
> ---  Implementation and driver testing completed   (NEC and Canon 
> Drivers have been tested)
> 
> (What license is OPVP and the driver from manufactures.)
> 
>  
> 
> ============
> 
>  
> 
> 11:50 am   Printing on the Desktop
>

These issues will be forwarded to the two students working on the Common 
Printing Dialog in the GSoC.

>  
> 
> Subject: Common Printing Dialog (CPD)
> 
> -- There should only be one dialog for all applications
> 
> -- The CPD should be part of the Gnome/KDE/Other? Desktops
> 
> -- Called using DBUS <--- Is this the best interface to applications.
> 
>  
> 
> = Like in Windows, there was an expressed desire for remembering print 
> setting at the desktop level, the application level and the document level.
> 

Will be no big deal: Dialog reports back option settings as simple 
key/value pairs to app. App keeps them as text and adds them to document 
file on saving. When dialog is opened again, app sends saved options to 
dialog.

> -- Thus the desktop group is looking for a machine readable definition 
> (specification) of print settings.
> 

Simply use key-value pairs:

PageSize=A4
Resolution=1200dpi
...

>  
> 
> = Want the CPD to have a state/status tab.
> 
> -- After some discussion, what the desktop people also wanted was some 
> very simple indicators in the main CPD window showing the “status” 
> (“state”, “condition”, “readiness”, “busyness”) of the printer.   That 
> is, they want to know that the printer is really ready/available for 
> printing.  Is the printer out of ink, is the print out of paper, is the 
> printer busy, is the printer online.   The idea was that the indicators 
> are simple colored boxes.  For example, a box for ink-level is green if 
> ink/toner level is ok, blue if ink/toner low, red if ink/toner out.  
> Same for the other status items.  The user could go to the state/status 
> tab if they need more information.
> 

Dialog could poll status from CUPS and show it somewhere.

>  
> 
> = The desktop group would like to see the CPD be a plug-in solution 
> versus a separate process.
> 

Problems of plug-in: Dialog and app is one process, dialog and app 
cannot be of arbitrary licenses then, crash of dialog would crash app.

>  
> 
> = The CPD should not define it own basic display parameters such as 
> font, color, etc.  These should be inherited from the Desktop the CPD is 
> running on.

    Till

Re: [Printing-architecture] LF Collaboration Summit Open Printing Minutes from Glen Petrie

[Klaus Singvogel]

Till Kamppeter wrote:
[...]
> > --- Glen is worried of extensibility of the dialog for manufacture.
> >
> 
> Manufacturer extensions cannot be done by means of executable code, as 
> printer drivers run on the server and server and client can be different 
> architectures. Manufacturer extensions can only be done by PPD options, 
> the custom options of CUPS allow extended data formats.
[...]

I agree.

But want to point out that manufacturers should also keep in mind,
that there is no _our_ nor any _single_ printer on _the_ only USB
port.

Means: LSB team should remember manufacturers regularly to avoid using
a direct communication to "/dev/usb/lp*" (or similar) to a printer in
their drivers.

Thanks in advance.

Kindly regards,
	Klaus.
-- 
Klaus Singvogel  -  Maxfeldstr. 5  -  90409 Nuernberg  -  Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D  1994-06-27
SUSE LINUX Products GmbH,  GF: Markus Rex,  HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] LF Collaboration Summit Open Printing Minutes from Glen Petrie

[Till Kamppeter]

Klaus Singvogel wrote:
> Till Kamppeter wrote:
> [...]
>>> --- Glen is worried of extensibility of the dialog for manufacture.
>>>
>> Manufacturer extensions cannot be done by means of executable code, as 
>> printer drivers run on the server and server and client can be different 
>> architectures. Manufacturer extensions can only be done by PPD options, 
>> the custom options of CUPS allow extended data formats.
> [...]
> 
> I agree.
> 
> But want to point out that manufacturers should also keep in mind,
> that there is no _our_ nor any _single_ printer on _the_ only USB
> port.
>

See for example the Brother drivers, you cannot install two of them on 
the same machine (independent of the connection type), due to common 
files. Bad for good customers of Brother, who want to use more than one 
Brother printer. I have found a volunteer and mentored him through 
making these drivers distro friendly. It was a HUGE effort for him to 
make 14 simultaneously installable Ubuntu packages out of ~200 .deb 
packages provided by Brother:

https://bugs.launchpad.net/bugs/25966
https://bugs.launchpad.net/bugs/219509

This made me adding several new items to the driver design guidelines:

http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers
http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers#What_to_do_and_what_not_to_do

> Means: LSB team should remember manufacturers regularly to avoid using
> a direct communication to "/dev/usb/lp*" (or similar) to a printer in
> their drivers.
>

Mike Sweet tries to move distros and driver developers away from this 
bad behavior by not supporting URIs like usb:///dev/usb/lp0 with his 
"usb" CUPS backend.

But anyway, good point you mention here. I will add it to my guidelines.

    Till