[Printing-architecture] Print Dialog: Preview Processing: Only A Question
glen.petrie at eitc.epson.com
Wed Apr 22 06:45:11 PDT 2009
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 solution.
Question Summary: Will the Application or the Print Dialog Generate the
Preview? Perhaps some of both? Perhaps on one.
Something brought up at the summit which I need clarification on was the
aspect of the "preview"; specifically, where it is generated (where does
the "processing" occur) and whether the Print Dialog will initially
and/or subsequently need/request the application to generate new/updated
preview content. Maybe all of this is a non-issue. That this;
specifically, what printing attributes and what attributes would require
the application to generate/regenerate print(/preview) content? I
believe the ones that we could all agree on would be margins, pages size
and page orientation. I believe that most (if not all) applications
provide a mechanism for setting the page size and page orientation.
Applications also have a mechanism for margins or use the printer
default (how in Linux do applications get the default/min margin values
for a specific (the active) printer?). So, I believe that the Print
Dialog is not "controlling"/setting these attributes for the
applications. If the previous statements were true then what attributes
in the Print Dialog would need the application to generate/regenerate
What are the other printing parameters that should only be at the
What attributes can the dialog support generating the preview (note the
command would be passed to the print manager and printer driver for
actually printing or if no preview is skipped)
* scaling (i.e. scale to fit)
* booking (book layout)
* Please see the OpenPrinting JTAPI list of objects and attributes
for a more complete list.
(An interesting case is page size (or page orientation) when the user
selects "scale-to-fit"; so that the print dialog over rides these two
options by scaling the original print content from the applications to
fit the new pages size/orientation. However, the print content is not
recreated by the application.)
I don't believe that the actually printer driver would be needed to
render the preview at the level needed for the preview; so this keeps
generation of the preview within the confines of the print dialog.
Now, should we consider the design where the print dialog only receives
the print job and no preview image (less burden on the application);
then it is the responsibility of the print dialog to "render" the
--- If the print dialog receives an image then the Print Dialog
under-samples/sub-samples or uses a GDI command to create the preview
--- If the print dialog receives PS/PDF then the Print Dialog calls
Ghostscript to a DPI/resolution value needed for the preview. I assume
this processing is within an acceptable load.
--- If the print dialog receives text; use Ghostscript or "printing" to
off screen memory to create an image representation.
So, dose this support having all of the "processing" of the preview
contained with the print dialog only?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Printing-architecture