Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question

["Petrie, Glen" <glen.petrie@eitc.epson.com>]

Another thought;  have a preference setting for the dialog that would
always allow the media size to be enabled in the dialog.  This way
sophisticated get what they need.

> -----Original Message-----
> From: printing-architecture-bounces@lists.linux-foundation.org
> [mailto:printing-architecture-bounces@lists.linux-foundation.org] On
> Behalf Of Petrie, Glen
> Sent: Wednesday, April 22, 2009 11:00 AM
> To: Tobias Hoffmann
> Cc: printing-architecture@lists.linux-foundation.org; printing-
> summit@lists.linux-foundation.org; Michael Sweet
> Subject: Re: [Printing-architecture] [Printing-summit] Print Dialog:
> PreviewProcessing: Only A Question
> 
> > > [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
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e