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

Petrie, Glen glen.petrie at eitc.epson.com
Wed Apr 22 09:13:50 PDT 2009

On Apr 22, 2009, at 6:45 AM, Petrie, Glen wrote:




	I have been requested to get a better understanding of
processing related to the print preview.  

	I am not proposing a solution or suggesting changing to a


	Question Summary: Will the Application or the Print Dialog
Generate the Preview?  Perhaps some of both?  Perhaps on one.


That really depends on the implementation and API.  If the dialog is
given a print file, it can use the "cupsfilter" command to generate
preview data with all options applied and display the results.  If the
application can supply per-page data to the dialog, it makes more sense
to do the preview generation in the application (faster).



[gwp]  Ok, so unless we want to dictate one or the other; we should make
either option possible.



FWIW, on Mac OS X we use a hybrid approach - in-dialog preview is done
via Cocoa class methods (all in-process), while external preview and the
PDF workflow/save-as-pdf functionality uses cupsfilter.


Either way, you can normally restrict yourself to a subset of known
options that affect layout, scaling, and basic color presentation (color
vs grayscale, maybe proof using ICC color profiles) - none of the dozens
of Gutenprint color options can be represented in the preview, for
example. (The Gimp plug-in supports it by linking to Gutenprint,
something we probably don't want since it would involve binary plug-ins
and then we have the mess of platforms/architectures to deal with...)


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


[gwp] Do we need to make a general policy on how to handle these cases? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20090422/584f12ac/attachment.htm 

More information about the Printing-architecture mailing list