From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C350.32247D5B" Date: Wed, 22 Apr 2009 06:45:11 -0700 Message-ID: From: "Petrie, Glen" Subject: [Printing-architecture] Print Dialog: Preview Processing: Only A Question List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C350.32247D5B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I have been requested to get a better understanding of processing related to the print preview. =20 I am not proposing a solution or suggesting changing to a solution. =20 Question Summary: Will the Application or the Print Dialog Generate the Preview? Perhaps some of both? Perhaps on one. =20 Supporting Discussion: =20 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 the preview?=20 =20 What are the other printing parameters that should only be at the application level? =20 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) * n-up * duplex * booking (book layout) * watermarks * color-to-bw * Please see the OpenPrinting JTAPI list of objects and attributes for a more complete list. =20 (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.) =20 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. =20 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 =20 --- 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. =20 So, dose this support having all of the "processing" of the preview contained with the print dialog only?=20 =20 glen =20 =20 ------_=_NextPart_001_01C9C350.32247D5B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

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.

 

Supporting Discussion:

 

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 the preview?

 

What are the other printing parameters that should = only be at the application level?

 

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)

n       = scaling (i.e. scale to fit)

n       = n-up

n       = duplex

n       = booking (book layout)

n       = watermarks=

n       = color-to-bw

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

 

So, dose this support having all of the = “processing” of the preview contained with the print dialog only? =

 

glen

 

 

------_=_NextPart_001_01C9C350.32247D5B--