[Printing-architecture] [Printing-summit] Print Dialog: Preview Processing: Only A Question

[Petrie, Glen]

> > [gwp] I think I understand your point. I would like to explore the
> > case where the app does the "layout" settings and, then, the print
> > dialog has "layout" settings. What is your expectation if the app
> > (like OpenOffice Write) sets (and flows) the document to letter
size;
> > then the print dialog offers "page size" attribute and the user now
> > selects A4. Would you expect the print dialog to send the info back
to
> > application to reformat/reflow the document or clip letter content
> > exceeding A4 or scale the letter content (without calling the
> > application) to fit A4. I guess I would you go with the last
> > option....but I have seen the system where letter formatted content
is
> > printed on 4x6 cards (silly I know) by simply clipping the letter
> > content to 4x6. I had not seen any implementation of calling back to
> > the application.
> >
> In general: Only the application knows the "right" way to print it's
> content onto a differently sized paper:
> - e.g. a PDF Viewer, or a DTP program has a fixed destination page
size.
> So they will most likely give the user an option like "scale contents
to
> fit page", as the user might want to get either of these.
> - a web-brower or OO Writer will want to reflow the content.

[gwp] Michael's (Apple's) solution I think is the best for the typical
end-user; that is, smart application will inform the dialog to gray out
media size and margins.  There is always the sophisticated user -
requires more thought on how support them. (see may next comment below)


> Actually its more a question of Media Size - and Media selection - vs.
> Content Size:
> I might (just a thought) want to print a Document flowed to A5
(Content
> size) to a A4 medium, and have it scaled to 141% e.g. for proofing
fine
> details.

[gwp] This is a good feature; but if following the typical end-user
solution above; then you might not get the media size (A4) options if
the application has requested to gray out the media size.  A quick
thought is have some kind of "advanced mode" that always allow the user
to set the print media size no matter what the content size is or what
the application has requested be grayed out.  The issue here is the
complexity of the dialog; anyway...  Thus, the gray-out (non-advanced)
mode protects the typical user from printing media-size-1 to
media-size-2 (which may produce strange/unexpected results) while
allowing sophisticated user the capability they need.

> The content size is technically only a matter of the application, and
> the medium size only matters for the printing process. And the user
has
> to decide whether to scale or print in 100% - when these size don't
match.
> 
> The casual user, however, will never want to know any of these details
> and IMO in the reflowable case expects the media size to directly
affect
> the content size, or being offered "scale-to-fit" for the fixed
content
> size case (what does the usability testing say?).
>

[gwp] Agreed, if you don't implement the suggested solution above.  In
this case, the user (typical or sophisticated) can change the print
media size.  If this approach is used, I would recommend that
scale-to-fit be the default.  At least this way the end-user will get
all content printed; and if they really want clipping to occur; they
will have to set that condition.


> Last but not least, the preview has to always show what the user will
> get, so callback to the application for potential reflow is necessary
> whenever the _content size_ changes.
> 

[gwp] I have some concerns about the "back to the app for reflow"; but
that's a discussion for another mail thread.


> Tobias