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

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

[Petrie, Glen]

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

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

[Till Kamppeter]

Lars, Alexander, and Jonathan, can you all subscribe to the 
printing-architecture mailing list and do all discussion concerning the 
specifications of the Common Printing Dialog and the interface between 
application and dialog here on the printing-architecture mailing list, 
so that printer manufacturers and others can participate?

Thanks.

    Till


Petrie, Glen wrote:
> 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
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>