[Printing-architecture] OpenPrinting Mobile Behavior Guidelines

[Printing-architecture] OpenPrinting Mobile Behavior Guidelines

[Petrie, Glen]

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

All,

 

I had an action item to produce the "OpenPrinting Mobile Behavior
Guidelines".  It is time to start.

 

Please comment on the following: do you agree or do you have another
opinion (explain your opinion)?

 

 

What should be in the guidelines:  

General what the mobile device (client) needs to do and can expect.
And, what the print "interface" needs to do and can expect.

 

From my presentation at the last F2F, I had defined the guidelines would
include such things as

1.      Definition of objects,  elements and attributes

2.      Definition ranges or the set of extensible and non-extensible
values

3.      Groupings of related objects, elements and attributes

4.      Interrelationships between objects, elements, attributes and
their values

5.      Constraints between  objects, elements, attributes and their
values

 

Looking at the list above, the first three things are covered the JTAPI.
So I would propose that the Guidelines state that elements of JTAPI be
used.

 

For item 4 and 5, I can go through the various combinations to determine
the determinable constraints and relationships.

 

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. 

 

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.

 

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)

*         pull down menus?

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

*         one or more iconic?

*         keystroke commands?

*         gesturing (double tap to print)?

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

 

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 (?)

 

 

 

 

 

 


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

Re: [Printing-architecture] OpenPrinting Mobile Behavior Guidelines

[Till Kamppeter]

On 06/20/2011 11:55 PM, Petrie, Glen wrote:
> All,
>
> I had an action item to produce the “OpenPrinting Mobile Behavior
> Guidelines”. It is time to start.
>
> Please comment on the following: do you agree or do you have another
> opinion (explain your opinion)?
>
> What should be in the guidelines:
>
> General what the mobile device (client) needs to do and can expect. And,
> what the print “interface” needs to do and can expect.
>
>  From my presentation at the last F2F, I had defined the guidelines
> would include such things as
>
> 1.Definition of objects, elements and attributes
>
> 2.Definition ranges or the set of extensible and non-extensible values
>
> 3.Groupings of related objects, elements and attributes
>
> 4.Interrelationships between objects, elements, attributes and their values
>
> 5.Constraints between objects, elements, attributes and their values
>
> Looking at the list above, the first three things are covered the JTAPI.
> So I would propose that the Guidelines state that elements of JTAPI be used.
>

OK.

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

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

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

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


> •pull down menus?
>
> •hierarchical menus? (same as display on a printer)
>
> •one or more iconic?
>

Depends on how ell it works on a touch screen.

> •keystroke commands?
>

Not suitable for touch but useful for netbooks.

> •gesturing (double tap to print)?
>

Nice for touch, but should not interfere with existing gestures and 
should not print without confirmation.

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

> 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

Re: [Printing-architecture] OpenPrinting Mobile Behavior Guidelines

[Petrie, Glen]

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

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


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