From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Apr 2009 11:18:19 -0700 Message-ID: References: <3602B1A0-C33E-4665-BBB6-46D59F2F044E@apple.com><49EF53C7.8020901@the-axe-effect.de> From: "Petrie, Glen" Subject: Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" , Tobias Hoffmann Cc: printing-architecture@lists.linux-foundation.org, Michael Sweet , printing-summit@lists.linux-foundation.org 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 >=20 > > > [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. >=20 > [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) >=20 >=20 > > 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. >=20 > [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. >=20 > > 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?). > > >=20 > [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. >=20 >=20 > > 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. > > >=20 > [gwp] I have some concerns about the "back to the app for reflow"; but > that's a discussion for another mail thread. >=20 >=20 > > Tobias > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/printing-architectur e