[Printing-architecture] OpenPrinting Mobile Behavior Guidelines

Petrie, Glen glen.petrie at eitc.epson.com
Fri Jun 24 06:54:56 PDT 2011


Till,

 

Thanks for the feed back.  I believe we have a similar understanding of
the problem and what should be in the guideline.   I have noted your
comments below and will make sure to capture them as part of the
development of the guideline. 

 

I hope to hear from other on guideline.   Once I get some more comments
I will try to capture all of the ideas and comments.

 

Have some other ideas related to this guideline that I will try to send
out today or next week.

 

Glen

 

 

> For item 4 and 5, I can go through the various combinations to
determine

> the determinable constraints and relationships.

> 

 

Constraints and relationships often depend on the particular printer, 

some can do duplex on envelopes, others no. For that the client (the 

mobile device) needs to be able to poll this info from the 

printer/server before displaying a printing dialog.

 

[gwp] My idea for mobile print is that we would limit the options like
"duplex on envelopes".  The guideline we only recommend support for the
90% (95% or 99%) print intents.  Thus, I am hoping that the constraints
and relationships are definable up front and, thus, can be
predetermined.   For mobile, this predetermined constraints and
relationships would greatly reduced complexities. 

 

> I can go through the various combinations and create a set of
predefined

> print mode (photo, web page, etc) that mobile devices (clients) can

> specify and will be understood by the print services or printer.

> 

 

Presets are a good idea on mobile as the limited space cannot hold lots 

of fine-tune options and most users want to select a simple document 

type instead of lots of settings. By the way, Apple AirPrint also uses 

presets.

 

[gwp] same comment as above. 

 

> What would the simplest print-architecture look like and various
levels

> of complexity. That is can a mobile device include CUPS or another,
and

> simpler, print manager (management) solution. How thin can a print

> manger (management) module be? We would specific (as part of the

> guideline) what was the minimum support and the ordering for adding
more

> complex capabilities.

> 

 

One important thing is that on mobile we do not need a 

RIP/filters/backends and also not the CUPS web interface. A pure 

CUPS/IPP client with a simple printing dialog would be enough. Then we 

can print onm AirPrint (PDF files via IPP) and on IPP Everywhere.

 

[gwp] I would like to initially determine (review) the requirements of
the "Print Manager" versus specify an implementation at this time.
Then, the guideline would recommend components. 

[gwp] The "simple printing dialog" is what the guideline is about along
with what components it takes to support it.   I am hoping the printing
dialog (no matter was interface type or what level of complexity) can be
coherent as perceived the user.

 

> For the various combinations of interface types shown below, I can

> create proposed "values" (names or iconics or keystroke or whatever)
to

> support each interface type.

> 

> *a dialog box? (how big?, how many pixels)

> 

 

Mobile screen sizes vary, especially as there are conventional phones, 

smartphones, and tablets/netbooks. So we need flexibility. Tablets and 

netbooks can even show the desktop dialog.

 

[gwp]  Yes; this is challenge.  While we also way think of the printer
supplying capabilities; now the display will have to provide
capabilities (physical size, pixel size, aspect ratio, color (how many
levels), interface type (touch, stylus, etc).   Printing will not be the
only application that will need this capability information.  Virtually,
any post-hosted application would need this information.  

 

> *pull down menus?

> 

> *hierarchical menus? (same as display on a printer)

> 

> *one or more iconic?

> 

 

Depends on how well it works on a touch screen.

 

[gwp] Agreed.  But the guideline would provide a recommendation based on
the display capabilities.

 

> *keystroke commands?

> 

 

Not suitable for touch but useful for netbooks.

 

[gwp] Agreed.  But the guideline would provide a recommendation based on
the device capabilities.

 

 

> *gesturing (double tap to print)?

> 

 

Nice for touch, but should not interfere with existing gestures and 

should not print without confirmation.

 

[gwp] Sorry, I meant double tapping on a printer iconic to initiate
printing.  Whether this will actually prints or just bring up the print
dialog is something we need to examine and explore. 

[gwp] I am not sure that a print-confirmation is always needed.  I
believe we need to examine the interface solutions and make a
recommendation (as part of the guideline) on whether print-confirmation
is necessary.

 

 

> *a physical button action?

> 

> *combinations of the above?

> 

> The guideline would need a conformance section (include what not to
do).

> 

> The guideline conformance should define the level of print "dialog"

> (interface) support is required for a mobile device with specific

> display size and computing power. (think of phone to iPad to netbook
to

> laptop)

> 

 

This is a good idea, priinting dialog guideline by screen size class.

 

[gwp] This is the key concept for the mobile print guideline.  We need
to take care in developing this part of the guideline.

 

> The guideline needs to define how applications can """extent""" mobile

> printing and mobile dialogs. The same would be true for print vendor

> extension.

> 

> The guideline would need a complete glossary. (I suspect that this
would

> be used by people with various levels of print interface development

> experience.)

> 

> The guideline would need a sample implementation (?) of each interface

> type (?)

 

 

    Till

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20110624/f204fb65/attachment-0001.htm 


More information about the Printing-architecture mailing list