[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