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

Petrie, Glen glen.petrie at eitc.epson.com
Thu Apr 24 08:35:25 PDT 2008


Finally catching up with email...

General request; Can the specification development content of GSoC
activities be openly communicated on the mail-list __during__ the
development.  Manufactures and others may have comments or needs to be
added/considered.



<...snip...>

> >    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

[gwp] can this part be openly discussed on the mail-list, so others can
understand and participate?



<...snip...>

> >    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,

[gwp] Can this part be openly discussed on the mail-list.  There may be
manufacture specific indicators (number of, state of, etc)?



<...snip...>

> 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.

[gwp] How does an application "know" / "understand" what the manufacture
extensions/options actually do?  So an application can't really do more than
simply turn off manufacture extensions/options.



<...snip...>

> > = 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.

[gwp] This may be a big deal if it requires the document format to change!



<...snip...>

> > -- Thus the desktop group is looking for a machine readable definition
> > (specification) of print settings.
> >
> 
> Simply use key-value pairs:
> 
> PageSize=A4
> Resolution=1200dpi

[gwp] As I remember the conversation; this is exactly what they did not
want. They want a binary representation (machine readable, not human
readable) definition.  
Example
0x07 0x42		(means PageSize(0x07) = A4 (0x42)
0x08 0x04 0xB0	(means Resolution(0x08) = 1200 (0x04 0xB0)

[gwp] We need to get clarification 


<...snip...>

> > = 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.

[gwp]  The desktop people stated the "somewhere" should be the main dialog
window/view.  The user should not have to go to a tab to get this info.


<...snip...>

> > = 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.

[gwp] Then I support separate process model.


gwp


More information about the Printing-architecture mailing list