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

[peter sikking <peter@mmiworks.net>]

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 solution.
>
> Question Summary: Will the Application or the Print Dialog Generate  
> the Preview?  Perhaps some of both?  Perhaps on one.

both.

the preview generation mirrors the printing process. For the
real print job the application does the transformation (formatting
for paper) and the printer (+ driver + CUPS + lots more) does the rest.
For the preview the the application does the transformation and the
print dialog does the rest.

what triggers an application re-transformation for the preview?
well, any change of parameter in the dialog that the application
takes into account for its transformation.

Foremost: printable page area, which could also be changed
as a side effect of changing N-up (I do not expect the app to do the
scaling down and placing of more pages on a side, just to get (maybe)
a slightly different printable area).

Then there is orientation.
And scale to fit (see below).

> n       n-up
> n       duplex
> n       booking (book layout)
> n       watermarks
> n       color-to-bw


none of the above would _directly_ trigger a re-transformation
(although b+w optimisation could may be covered by apps like scribus).
I would be most interested in any other parameters I oversaw
or misjudged.

on top of this is every parameter that the application places
in the print dialog (under the application tag), it is only logical
that these application parameters directly control the transformation.

a simple example of an application parameter is a web browser
including the checkbox "Print headers and footers" in the
print dialog. toggling this should immediately reformat the
print, resulting even in more/less pages to print.

> (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.)

This reminded me to add this one above. scale to fit relates to
content, of which the application has the domain knowledge.

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

I agree.

> 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 preview. Examples
>
> --- If the print dialog receives an image then the Print Dialog  
> under-samples/sub-samples or uses a GDI command to create the  
> preview (size) image.
> --- 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.

this can only be a fall-back for a most uncooperative application,
that I cannot see placing its own parameters in the dialog.

so good enough for rock 'n' roll, but it would not fulfil the
minimal usability goals for the printing dialog.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture