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

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

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

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)

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

 

(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

 

 


[-- Attachment #2: Type: text/html, Size: 13253 bytes --]

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

[peter sikking]

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

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

[Petrie, Glen]

Johannes,

I think the situation is like this...

The preview, in most cases, will not be generated by the printer-driver
or by the printer itself.  Printing, that is, the rendering of physical
page from the electronic page is a one-way process done within the
printer-driver or within the printer. In almost all cases (maybe all
cases), it will be a filter (that means Ghostscript) that will generate
the preview.  The filter is taking the electronic document page (PS,
PDF, image(jpeg, tiff, png, ...), ...) and producing an "electronic
print page" (an image) for viewing or passing to printer-drivers (or
printers) that process only image data.

I am not aware of a printer-driver that directly generates preview
images.

(Just to make sure, the "printer-driver" is the software/firmware that
takes the electronic print content and converts its into printer
specific commands to produce physical printed pages.  For example,
inkjet "printer-drivers" typical take in images and rasterize the image
to PCL for HP, ESC/P for Epson, and so forth.  In this case, the
"printer-driver" output is not displayable (unless you were to use a
filter!))

Glen


> -----Original Message-----
> From: Johannes Meixner [mailto:jsmeix@suse.de]
> Sent: Thursday, April 23, 2009 2:39 AM
> To: peter sikking
> Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org;
> printing-summit@lists.linux-foundation.org
> Subject: Re: [Printing-summit] [Printing-architecture] Print Dialog:
> Preview Processing: Only A Question
> 
> 
> Hello,
> 
> On Apr 22 17:56 peter sikking wrote (shortened):
> > Glen wrote (shortened):
> ...
> >>  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.
> 
> I do not understand how this fits to what Peter required
> in his previous mails:
> ------------------------------------------------------------------
> ...
> the usability test results proved that the preview is a huge
> success and needs to be 100% "true"
> ...
> without a doubt _and_ proven by our first tests: the preview
> needs to be a lo-res version of exactly what will come out
> of the printer.
> -----------------------------------------------------------------
> 
> How should the preview be 100% "true" when it is done only
> "within the confines of the print dialog" (i.e. without
> the actual printer driver and without the actual printer)?
> 
> I understand that a "combination of the printer driver
> and the dialog set-up files" (see the mails at the bottom)
> might be able to generate a true wysiwyg preview
> but I do not understand at all how to do it
> without driver and printer.
> 
> Compare what I wrote in a previous mail here:
> ------------------------------------------------------------------
> For example to get a preview which is "exactly what will
> come out of the printer" ;-)
> To make such a preview, the printing dialog must query the
> printer device (e.g. to find out which media is currently
> actually loaded).
> ------------------------------------------------------------------
> 
> Regarding "cupsfilter" see
> http://www.cups.org/documentation.php/doc-1.4/man-cupsfilter.html
> ------------------------------------------------------------------
> cupsfilter currently does not use the filters defined in
> the PPD file. This will be addressed in a future CUPS release.
> ------------------------------------------------------------------
> The driver is one of the filters defined in the PPD file
> so that currently cupsfilter does not run the driver
> so that currently cupsfilter cannot produce an image
> which shows '100% "true" exactly what will come out
> of the printer'.
> 
> 
> To aviod another mail war:
> 
> I neither want to accuse a programmer (like "your software
> is bad because it does not do what the user wants")
> nor to accuse an usability expert (like "your usability test
> are bad because the users ask for nonsense stuff").
> 
> I only want to avoid a continuous misunderstanding between
> programmers and usability experts which results in the end
> nothing else but frustration when in the end the software
> does not do what the usability experts wanted simply
> because at the current time it was not possible for the
> programmer to implement what the usability experts wanted.
> 
> I fully agreed all the time that "true wysiwyg" is what
> everybody wanted and wants to have.
> 
> But on the other hand I think that it does not help to
> only demand it without listening to what is currently
> possible to be implemented and adapting the current
> requirements to what is currently possible.
> 
> I think this is a precondition so that it is possible
> to move forward step by step to "true wysiwyg".
> 
> I think it might help a lot when the usability experts
> keep the "true wysiwyg" requirement as ultimate goal
> but provide some fallback designs what to do
> when this or that precondition for "true wysiwyg"
> is not fulfilled:
> 
> E.g. what should be shown as "best effort preview" when
> - it fails to find out e.g. which media is currently
>    actually loaded in the printer (e.g. when there is
>    no communication with the printer device)
> - it fails to find out anything at all about the printer
>    (e.g. when a laptop user is on his way and prints into
>    a local queue which points to a remote queue on a remote
>    CUPS server where the PPD file is located but the server
>    is currently not accessible)
> 
> 
> For more information have a look at
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001140.html
> ------------------------------------------------------------------
> printing dialog cannot reliably determine what the
> physical outcome will be - it can only guess the physical outcome
> by hoping that everything works as the printing dialog assumes
> see (*) below.
> 
> ...
> 
> Unfortunately some printer manufacturers make also cheap and stupid
> printers ( for their customers who like to buy cheap hardware ;-)
> 
> Those printers get their input data as a "bitmap" of dots which are
> to be printed and usually the driver of such a piece of hardware
> cannot ask the printer which paper is currently loaded.
> Often the printer is so stupid that it doesn't know it but usually
> the reason is that there is no bidirectional communication with
> the printer while a print job is processed (and there is no
> communication with the printer at all while a print job is created
> by the application (*)).
> ------------------------------------------------------------------
> 
> and
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001142.html
> ------------------------------------------------------------------
> Please provide some ideas how such a wysiwyg preview is to
> be implemented so that it really works...
> 
> In particular I like to learn how to get a wysiwyg preview
> for those big printers which do it all internally.
> 
> The printing dialog would have to ask the printer somehow
> what it would actually produce (in particular a network
> printer which is only accessible via a CUPS server).
> 
> E.g. such printers decide (based upon their internal settings)
> what to do when there is A4 content but only Letter paper is
> available or vice versa.
> Some printers scale it onto the paper which is available,
> some clip what doesn't fit on the paper,
> ------------------------------------------------------------------
> and Peter's reply:
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001143.html
> ------------------------------------------------------------------
> The combination of the printer diver and the dialog set-up files
> (PPDs, etc.) controls the dialog, knows how the printer ticks and
> generates the data to the printer. That is enough to make it
> work with near-zero network polling.
> ------------------------------------------------------------------
> and my reply:
> https://lists.linux-foundation.org/pipermail/printing-
> summit/2007/001145.html
> ------------------------------------------------------------------
> For a PostScript printer there is no driver.
> 
> For printing in the network the driver runs on the print server
> so that there is no communication between a user application
> which runs on the user's workstation and the driver which runs
> at any time later when the print job is actually processed
> on the print server.
> 
> The printing system and the user application only knows the
> possible options and option values (and forbidden combinations
> of option settings) from the PPD but it does not know what the
> printer will actually spit out for each allowed combination
> of option settings.
> ------------------------------------------------------------------
> 
> 
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> AG Nuernberg, HRB 16746, GF: Markus Rex

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

[Till Kamppeter]

The only things which the dialog can make use of to poll from the CUPS 
server or the printer is the PPD to list options and choices and to make 
the preview giving an impression on what at least some known options 
affect on the printout and perhaps the loaded papers sizes/types polled 
from the printer to reflect them somehow in the preview. But we always 
need to be prepared to not be able to access this info and thenm we need 
to make the best out of what we have.

    Till

Petrie, Glen wrote:
> I think the situation is like this...
> 
> The preview, in most cases, will not be generated by the printer-driver
> or by the printer itself.  Printing, that is, the rendering of physical
> page from the electronic page is a one-way process done within the
> printer-driver or within the printer. In almost all cases (maybe all
> cases), it will be a filter (that means Ghostscript) that will generate
> the preview.  The filter is taking the electronic document page (PS,
> PDF, image(jpeg, tiff, png, ...), ...) and producing an "electronic
> print page" (an image) for viewing or passing to printer-drivers (or
> printers) that process only image data.
> 
> I am not aware of a printer-driver that directly generates preview
> images.
> 
> (Just to make sure, the "printer-driver" is the software/firmware that
> takes the electronic print content and converts its into printer
> specific commands to produce physical printed pages.  For example,
> inkjet "printer-drivers" typical take in images and rasterize the image
> to PCL for HP, ESC/P for Epson, and so forth.  In this case, the
> "printer-driver" output is not displayable (unless you were to use a
> filter!))

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

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

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

	

	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.

 

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? 


[-- Attachment #2: Type: text/html, Size: 8287 bytes --]

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

[Tobias Hoffmann]

Petrie, Glen wrote:
> [...]
>
> [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.

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

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.

Tobias

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

[Petrie, Glen]

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

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


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

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

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

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


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

[gwp] I have some concerns about the "back to the app for reflow"; but
that's a discussion for another mail thread.


> Tobias

Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question

[Petrie, Glen]

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
> 
> > > [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.
> 
> [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)
> 
> 
> > 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.
> 
> [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.
> 
> > 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?).
> >
> 
> [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.
> 
> 
> > 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.
> >
> 
> [gwp] I have some concerns about the "back to the app for reflow"; but
> that's a discussion for another mail thread.
> 
> 
> > Tobias
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
>
https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
e

Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question

[Till Kamppeter]

In case of a page-oriented apps we could have for example the following 
options:

1. Page Size: Choices "Document Page Size(s)" (Default) and all page 
sizes from the PPD.

2. Fit to Page: Selects behavior when for "Page Size" "Document Page 
Size(s)" is NOT selected: "Shrink to fit" (Default), "Scale to fit", 
"Crop to fit". This option gets grayed out if "Page Size" is set to 
"Document Page Size(s)".

For non-page-oriented apps (brower, e-mail, ...) the "Document Page 
Size(s)" in "Page Size" and the "Fit to Page" will either not be shown 
or grayed out.

WDYT?

    Till


Petrie, Glen wrote:
> 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
>>
>>>> [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.
>> [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)
>>
>>> 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.
>> [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.
>>
>>> 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?).
>>>
>> [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.
>>
>>
>>> 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.
>>>
>> [gwp] I have some concerns about the "back to the app for reflow"; but
>> that's a discussion for another mail thread.
>>
>>
>>> Tobias
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.linux-foundation.org
>>
> https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
> e
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
> 

Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question

[Till Kamppeter]

Michael R Sweet wrote:
> Or just use the size from the document/app as the default and changing 
> to any other size does scaling. (otherwise, what is the document size if 
> you don't show it?)

There can be documents which have different page sizes, for example page 
1 and A4, page 3 A3 and page 4 A4 again. With "Document Page Size(s)" an 
appropriately loaded printer will take A4 paper for the pages 1, 2, and 
4 and A3 paper for page 3. All selections of a concrete page size will 
let the printer print all pages on the same paper size, using different 
scaling factors if needed.

    Till

Re: [Printing-architecture] [Printing-summit] Print Dialog: PreviewProcessing: Only A Question

[Petrie, Glen]

I believe the examples need to be divided up.  As I discussed, there is
the typical user and sophisticated user.  Maybe we should think of the
documents the same way.  I would believe that any one that wants to
print a document of various paper size (paper types) within the single
document will not change the page setting in the dialog -- so this is
really the sophisticated document and, as such, represents a very small
percentage of documents to be printed in the SOHO, Business and
Enterprise environments.  Note that in Production Printing Environment,
these complex documents are common but there the printers are very
sophisticated and have print operators.

I think we should establish a guideline for the 90% user case to help
developers, users and applications understand what to expect and I think
Michael's proposal is the best suggestion.

glen

> -----Original Message-----
> From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
> Sent: Wednesday, April 22, 2009 1:56 PM
> To: Michael R Sweet
> Cc: Petrie, Glen; Tobias Hoffmann; printing-architecture@lists.linux-
> foundation.org; printing-summit@lists.linux-foundation.org
> Subject: Re: [Printing-architecture] [Printing-summit] Print Dialog:
> PreviewProcessing: Only A Question
> 
> Michael R Sweet wrote:
> > Or just use the size from the document/app as the default and
changing
> > to any other size does scaling. (otherwise, what is the document
size if
> > you don't show it?)
> 
> There can be documents which have different page sizes, for example
page
> 1 and A4, page 3 A3 and page 4 A4 again. With "Document Page Size(s)"
an
> appropriately loaded printer will take A4 paper for the pages 1, 2,
and
> 4 and A3 paper for page 3. All selections of a concrete page size will
> let the printer print all pages on the same paper size, using
different
> scaling factors if needed.
> 
>     Till

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

 

So, is the follow summary correct?  Please correct if I did not capture
the mail thread discussion correctly.

 

 

Applications will send the (source) paper-size as part of the print job
(job-ticket???) and the Print Dialog will set the (destination)
paper-size that the one defined in the print job.

 

*       The Application can not disable the (destination) paper-size
setting in the print dialog

*       The User can change the print (destination) paper-size

o        Default action: The print content will be scaled to fit the
specified destination paper-size on a page-to-page basis.

*         In the event of complex documents, all pages will be scaled to
fit on a page-by-page basis.

o        Options: The dialog may provide optional transforms for going
from the source paper-size to the destination paper-size.

*         In the event of complex documents, all pages will be
transformed the same way on a page-by-page basis.

 

Question: (Always one more question) - Should a warning message be
displayed when the user is changing the source paper-size to a different
destination paper-size?

 

==================

*       Although you don't normally see margin settings in print dialog;
if they are in the print dialog, I think we should use the same
guideline outlined above.

 

Finally, if the above guideline is ok, then does it imply that the print
dialog does not need to ask the application to re-render the preview?

 

==================

I would like to discuss more about whether the Application renders the
preview or the print dialog does it.

 

Some considersations:

*       Actually, one reason to have the print dialog render is to the
display an accurate depiction of what will be printed versus previewing
what the application expects will be printed.

*       I believe moving rendering responsibility to the print dialog
puts the rendering in a common place and removes the burden from the
application.

*       Removes bi-directional communication between the application and
print dialog; that is, printing is handed off operation to print dialog.

*       The print dialog may be used to open spooled print job to
provide a preview even when the application has been closed.

 

 

 

 

 

 

 


[-- Attachment #2: Type: text/html, Size: 11829 bytes --]

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Till Kamppeter]

Petrie, Glen wrote:
> So, is the follow summary correct?  Please correct if I did not capture 
> the mail thread discussion correctly.
> 
> Applications will send the (source) paper-size as part of the print job 
> (job-ticket???) and the Print Dialog will set the (destination) 
> paper-size that the one defined in the print job.
>

Jobs from page-oriented applications will get sent with page sizes for 
each page, jobs from other apps will be sent without page size.

Default destination size is using the sizes of the document pages, in 
case of complex documents the page size can change during the job. If 
the application does not supply a page size, the default destination 
page size is the CUPS default.

> n       The Application can not disable the (destination) paper-size 
> setting in the print dialog
>

Yes, the user can decide to keep the original sizes of each page or he 
can choose one of the page sizes defined in the PPD file.

> n       The User can change the print (destination) paper-size
> 
> o        Default action: The print content will be scaled to fit the 
> specified destination paper-size on a page-to-page basis.
> 

This happens if the user chooses a size, if he stays with "Original page 
size(s)" the source page sizes are used as destination sizes and the 
pages are printed in original size.

> §         In the event of complex documents, all pages will be scaled to 
> fit on a page-by-page basis.
> 

As above, only if the user chooses a page size. Otherwise all pages are 
printed in original size and the printer switches trays is the pages 
have different sizes.

> o        Options: The dialog may provide optional transforms for going 
> from the source paper-size to the destination paper-size.
> 
> §         In the event of complex documents, all pages will be 
> transformed the same way on a page-by-page basis.
> 

Yes, one could also make available "Shrink to fit" (scale pages which 
are too big and center pages which are too small for the destination 
page size) and "Crop to fit" (Keep page in original size and crop if it 
is bigger than the destination page size, try to crop only from the 
white margins if possible).

>  
> 
> Question: (Always one more question) – Should a warning message be 
> displayed when the user is changing the source paper-size to a different 
> destination paper-size?
> 

No, "Page Size" option should have "Original page size(s)" as first 
entry and default (for page-oriented apps).

>  
> 
> ==================
> 
> n       Although you don’t normally see margin settings in print dialog; 
> if they are in the print dialog, I think we should use the same 
> guideline outlined above.
>

Yes, we should do so.

>  
> 
> Finally, if the above guideline is ok, then does it imply that the print 
> dialog does not need to ask the application to re-render the preview?
> 

For page-oriented apps re-rendering is not needed, but for apps like 
browsers or plain text editors the app has to re-render on changes of 
page size or margins.

>  
> 
> ==================
> 
> I would like to discuss more about whether the Application renders the 
> preview or the print dialog does it.
> 
>  

The application generates a (low quality, single pages) PDF and sends it 
to the print dialog. The preview widget is a PDF viewer. The dialog can 
do transformations on this PDF to show color management/grayscale, N-up, ...

> 
> Some considersations:
> 
> n       Actually, one reason to have the print dialog render is to the 
> display an accurate depiction of what will be printed versus previewing 
> what the application expects will be printed.
> 

The application has to do the first step, creating a PDF from the 
document, to have an app-independent format which the dialog 
understands. To the PDF transformations can get applied.

> n       I believe moving rendering responsibility to the print dialog 
> puts the rendering in a common place and removes the burden from the 
> application.
> 

Re-rendering by the app is still needed for tthe apps which are not 
page-oriented, like browsers or mailers.

> n       Removes bi-directional communication between the application and 
> print dialog; that is, printing is handed off operation to print dialog.
> 
> n       The print dialog may be used to open spooled print job to 
> provide a preview even when the application has been closed.
> 

For re-printing jobs from the job history, we have to work as our app 
would be a PDF viewer (page-oriented!) sending us the PDF which we are 
taking from the history. This means when re-printing an e-mail from the 
job history on a different paper size we can only do scale to fit and 
not reflowing the e-mail text into the new paper size.

    Till

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Till Kamppeter]

[ Re-posting to the lists ]

Petrie, Glen wrote:
> Till,
> 
> What applications do you consider Not-Page Oriented.  I am having a hard thinking of an application that does not render it content to a paper-size (page-size).   
>

I mean applications where the user is not already working on the actual 
page size. These are for example e-mail clients, browsers, plain text 
editors, where text is simply a sequence of data and flowing somehow 
into the view area (screen, paper, ...). So for printing the document 
visible on the screen or for changing the paper size the text has to be 
flown again into the new paper size. Also photo viewers/editors are not 
page oriented. Photos are bitmaps of XxY pixels without defined absolute 
size. they have to get scaled into the requested ensemble of paper size, 
margins, and resolution.

For these applications a "document paper size" does not exist, so in 
contrary to page-oriented applications (OpenOffice.org, Scribus, PDF 
viewer, ...) "Document paper size(s)" should not be added to the paper 
size option (or grayed out). The page size has to be selected in the 
printing dialog (and the default taken from CUPS) and the app has to 
regenerate the preview data if the page size and/or the margins are 
changed in the printing dialog.

In the case of the page-oriented applications the preview does not need 
to be regenrated by the app when the page size or another printer or 
printing-system option is changed.

In any case the app needs to deliver a regenerated preview if an 
application-specific option changes, as for these options the 
application knows best what happens.

> Web pages must format the print-content before calling the print dialog.  If I look at Firefox in Ubuntu it supports page-set within the application; so it would format content before calling the print dialog.  The text editor in Ubuntu has page-set.  
>

Here the print content needs to be re-formatted if the user changes the 
page size.

> I don't think of the print dialog formatting generic print content like text.  I don't think of the application involved in a bi-directional communication with the print dialog.
>

Yes, the print dialog can only do things like scaling, rotating, N-up, 
color transformation, not re-flowing text for example. In such a case 
the app has to regenerate the preview.


> Can you help me with some specific examples.
> 

As I said, page size change when the app ius a browser or a plain text 
editor for example.

>> The application has to do the first step, creating a PDF from the
>> document, to have an app-independent format which the dialog
>> understands. To the PDF transformations can get applied.
> 
> I don't completely understand this.  Why do applications have to create PDF.  If the application is a photo application, it can send print content that is just an image.  If the application is a text application is can sent text (which has been laid out in the page-size required).

Not necessarily PDF but a format which the printer dialog understands. 
For the preview (at least a non-scalable one as Peter considers as 
sufficient) one could perhaps even take only a bitmap format like PNG. I 
was simply thinking in the format which the app usually sends to CUPS 
(PostScript or PDF) and also that we are now going towards PDF as job 
format. Theoretically one could let the dialog accept anything what CUPS 
accepts and let the "cupsfilter" command convert it to a format used by 
the preview (PDF or PNG), but this is probably an additional slowing 
factor. So the easiest is to standardize on a format, like PDF. One 
could let the app generate low-quality PDF for previews and high-quality 
PDF for printing.

> 
> Or are you saying that all drivers must accept/process PDF.
> 

Drivers only need to accept a format which CUPS can generate from the 
input data. Usually they accept PostScript and PDF (Ghostscript-based 
drivers) or CUPS Raster (CUPS Raster drivers). CUPS converts PostScript 
and PDF to the driver's input format.

> Or since Linux does not have a single gdi, that you are simply making all print content be in a single format.
> 

This is the idea. It is easier for the dialog and faster to process if 
it gets only one data format. PDF is the most universal one. Also note 
that there can be daemon-less CUPS clients, so CUPS is not always 
available for converting incoming documents on the client.

> I confused.
> 
> If I have a photo app that wants to print an image. The steps are
> 
> 1. app creates a pdf instantiation of the image
> 2. send pdf to print dialog
> 3. send pdf to CUPS
> 4. CUPS sends pdf to GhostScript to render
> 5. Ghostscript creates an image
> 6. Image is sent to a printer driver 
> 

The image created in 5. is not the same format as the image coming from 
the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster is 
created.

> Versus  
> 1. app sends image to print dialog
> 2. print dialog display image (as preview)
> 3. send image to CUPS
> 4. Image sent to print driver.
> 

So if all apps send images this would make sense, but apps like 
OpenOffice.org or Firefox would preferably send PDF. So the dialog would 
get much more complex if we make it capable of all formats which CUPS 
can convert. So standardizing on one format simplifies the 
implementation of the dialog a lot.

> My point is that not all drivers support PDF.  I think rendering to PDF and then de-rendering by Ghostscript may produce artifacts.
> 
> What if we define acceptable print formats: sRGB-Image, simple text, formatted text, PS, PDF, ???, ???, html-print, ????, ????
>

Up to now all apps have produced PostScript for print jobs. This was not 
perfect as PostScript gave to many liberties to application programmers 
(it is a programming language) which made page management (N-up, 
selected pages, ...) break very often. So we agreed on PDF to solve this 
problem. In general, we have one standard print job format. CUPS is 
converting everything to this standard format (currently PostScript, 
with the extra filters from OP Japan PDF), running the page management 
(pstops or pdftopdf filter), and passing the job ont to Ghostscript. 
Ghostscript understands both PostScript and PDF, so it does not matter 
which format arrives here.

You are now suggesting that the apps can send a wide range of formats 
(ideally the full range of formats which the stock CUPS package 
accepts). This would change the internal (not UI) design of the dialog 
(and the apps) vastly. Apps like text editors or image viewers could 
then internally "save into the print queue" and so delegate all the 
formatting for printing the file to the dialog. The dialog would need to 
use CUPS filters to find out how the printout will look like (or even 
reimplement them and then the maintainer has to hunt after each little 
change in CUPS).

It would be much easier to implement and much more reliable if the 
dialog supports one standardized format like PDF.

    Till

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

I tried to explain differently my concerns and hope this long discussion
continues.   Please, I am not trying being stubborn; I just want to help
create a solution that is best for the user, the application and driver
developers (oops, forgot CUPS).  So help me understand some of your
choices and understand some of my suggestions.

This discussion is really hard by email, this would be a good one for a
F2F.

This note has three issues; namely,

1. What to do when the application page-size does not match the print
page-size.
2. Who renders the preview
3. Should applications support just PDF print format.

==============================================================
==============================================================
==============================================================
1. What to do when the application page-size does not match the print
page-size.

I believe it is becoming clearer that the key to this on going
discussion is how we are thinking about the relationship between 

Electronic paper-size === Electronic page-size === EPS
  This is set only by the application

and

Physical paper-size === Printer paper-size ===  PPS
  This is set only by the print dialog

EPS really has/should-have nothing to do with PPS.  I can have an A3 EPS
while the printer only support letter.  This is an issue.  This issue
needs to be handled by the print-system and shown in the print dialog,
so the user will know what to expect and what to do.

I think examining this issue is something you really need to actually
perform; so I tried it on a Mac and Window using PowerPoint.  In either
system, when the EPS != PPS then the preview show the EPS clipped to the
PPS (I assume the paper-size (PPS) the currently selected printer
reports as the installed paper-size (PPS)).  If the scale-to-fit option
is set; then, the EPS is scaled (maintaining the aspect ratio) to the
PPS.

Mac's version of PowerPoint also illustrates more about dialog <->
application interaction. (I believe Michael already commented on this
but I will repeat here for completeness).  In the print dialog, you will
not see a paper-size (PPS) option but you will see a button for
page-size (EPS).  When this button is pressed, the print dialog returns
control to the application (powerpoint) and powerpoint shows its dialog
for the page-size (EPS) (this is completely independent of the print
dialog).  The user can change the page-size (EPS) and indeed the
powerpoint pages are reflowed in powerpoint and the powerpoint display
changes.  Unfortunately, control is transferred automatically to the
print dialog and user has to cancel the print dialog to fix any changes
the new page-size (EPS) caused.

----- I don't believe this experience was end-user friendly.  If the
print dialog is not going to have paper-size (PPS), then the user uses
the preview to see what they will get.  Then if the user does not like
what will be printed (scale-to-fit or center-and-clip) then the user
should cancel the print dialog and return to the application to fix
things.  
----- If the print dialog shows a paper-size (PPS) option, then the user
still uses the preview to see that they will get.  If the user changes
the paper-size (PPS) then the print-system should scale-to-fit or
center-and-clip the print content (format at EPS) to the paper-size
(PPS).  Otherwise, the user needs to cancel the print dialog and return
to powerpoint to modify things.  This is what I hope is the final choice
for OpenPrinting.

((( An interesting case to consider is when a photo-printer (PhotoSmart,
PictureMate) is the connected printer.  )))

I hope we have been saying the same thing but just in a different way.

??? Do we have a way to support custom paper size (EPS and PPS) ???

==============================================================
==============================================================
==============================================================
2. Who renders the preview

I really do want to push the case where the print-system creates the
preview from the print-content.  It is really the only way for the print
preview to display the best representation (we can do today) that the
printer will actually print.


==============================================================
==============================================================
==============================================================
3. Should applications support just PDF print format.

Till, in general I understand and probably agree with your comments.  

PDF format is great for documents.  There are concerns about have any
filters in the print-chain between photo applications and the
printer-driver (i.e. rendering and re-rendered image).

Can we support at least one image format or have a way for the filers
that process PDF to not alter the original images.  


==============================================
Till below are some additional comments on your reply


[...snip...]
 
> > Or are you saying that all drivers must accept/process PDF.
> >
> 
> Drivers only need to accept a format which CUPS can generate from the
> input data. 

Doesn't CUPS needs to transform (filter) input data to a format the
driver can accept (image, ps, pdf, ???)!!!

> Usually they accept PostScript and PDF (Ghostscript-based
> drivers) or CUPS Raster (CUPS Raster drivers). 

None of Epson's consumer inkjet printers accept PDF or PS; that why
Ghostscript is needed.  Yes, office printer and high-end printer accept
PS and PDF - is this the only printers we are targeting.

Cups Raster is not really "raster" content; it is better described as a
job-ticket (print-ticket) (actually done at on a page to page if I
remember correctly) with image data attached.  So it really helps
(although increase the processing) in rendering pages (to actual printer
raster).  


The point is "why the constraints".


> CUPS converts PostScript
> and PDF to the driver's input format.
> 



> >
> > If I have a photo app that wants to print an image. The steps are
> >
> > 1. app creates a pdf instantiation of the image
> > 2. send pdf to print dialog
> > 3. send pdf to CUPS
> > 4. CUPS sends pdf to GhostScript to render
> > 5. Ghostscript creates an image
> > 6. Image is sent to a printer driver
> >
> 
> The image created in 5. is not the same format as the image coming
from
> the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster
is
> created.
> 

As a vendor supporting photo printing; print vendors may have an issue
with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
changes the colors and, then, the printer-driver dithers and performs
color-to-ink conversion you have high risk of creating artifacts in the
final print.  Who will the user call or issue a bug report against - the
print vendor.  And the user has a bad experience.

> > Versus
> > 1. app sends image to print dialog
> > 2. print dialog display image (as preview)
> > 3. send image to CUPS
> > 4. Image sent to print driver.
> >
> 
> So if all apps send images this would make sense, but apps like
> OpenOffice.org or Firefox would preferably send PDF. 

I bet that neither openoffice nor firefox cares about PDF; what they
prefer is that the GDI they are using supports a printer deviceContext
and they just "display" to the printer deviceContext and deviceContext
generate the print content (image, pdf, ps, cups raster, foo....)

> So the dialog would
> get much more complex if we make it capable of all formats which CUPS
> can convert. So standardizing on one format simplifies the
> implementation of the dialog a lot.
> 

Not if the dialog request CUPS to create the preview via it's filters.

> You are now suggesting that the apps can send a wide range of formats
> (ideally the full range of formats which the stock CUPS package
> accepts). This would change the internal (not UI) design of the dialog
> (and the apps) vastly. 

Not if the dialog request CUPS to create the preview via it's filters.

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Hal V. Engel]

On Thursday 23 April 2009 11:56:44 am Petrie, Glen wrote:
> ==============================================================
> 3. Should applications support just PDF print format.
>
> Till, in general I understand and probably agree with your comments.  
>
> PDF format is great for documents.  There are concerns about have any
> filters in the print-chain between photo applications and the
> printer-driver (i.e. rendering and re-rendered image).

I would also argue that PDF is great for image formats as well.  For example 
it will facilitate color management and also help with correct page formating 
(IE the user only wants to use the top or bottom half of the page for this 
photo).

>
> Can we support at least one image format or have a way for the filers
> that process PDF to not alter the original images.  

The problem is that current drivers do not handle images correctly at least 
not without some external help.  For example none of the current drivers does 
color management and this must be done someplace upstream from the driver.

snip
> The point is "why the constraints".
>
> > CUPS converts PostScript
> > and PDF to the driver's input format.
> >
> > > If I have a photo app that wants to print an image. The steps are
> > >
> > > 1. app creates a pdf instantiation of the image
> > > 2. send pdf to print dialog
> > > 3. send pdf to CUPS
> > > 4. CUPS sends pdf to GhostScript to render
> > > 5. Ghostscript creates an image
> > > 6. Image is sent to a printer driver
> >
> > The image created in 5. is not the same format as the image coming
>
> from
>
> > the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster
>
> is
>
> > created.

Yes but the image embedded in the PDF is an unaltered JPG or PNG or TIFF... 
file.  The PDF is a container and the image is NOT altered when it is embedded 
in the PDF.  But there are necessary steps that will take place in #5 that are 
currently NOT happening.

>
> As a vendor supporting photo printing; print vendors may have an issue
> with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
> changes the colors 

Dithering and half toning should not be happening at this stage.  The only 
transformation that should be happening at this stage is application of the 
correct ICC profiles to target the print device.   This is "changing the 
colors" but it is a necessary step for getting correct results that can not be 
avoided unless the user does not care about color accuracy and only then if 
the user is only dealing with simple images or documents that are already in 
the devices generic color space.  After all if the driver expects images to be 
RGB and the user sends a CMY(K) image to CUPS the color will have to be 
changed at some point along the way.  It seems logical that the software doing 
this would use the images embedded CMY(K) profile and the printers RGB profile 
to do the transformation correctly rather than using some generic CMYK to RGB 
transform unless it had no other choice.  The image(s) and other objects in 
the PDF file should have embedded profile(s) and CUPS should pass the correct 
printer profile to the pdftoraster filter based on the cupsICCProfile settings 
in the PPD file.   Images without embedded profiles can be handled in a more 
generic way (IE. using default image profiles) but in that case the user 
apparently does not care about color correctness. 

The color management step has to occur somewhere and this is the logical place 
for it to happen.  In addition, this is one of the intended purposes of PDF 
and I know of no current printer drivers that do this.  The only way to avoid 
this and satisfy the color management community is to make all of the printer 
drivers handle the color transformations or to find another system wide 
location where this happens (if not #5 or the printer drivers then where?).  
If you are ready to add color management to your printer drivers and you can 
convince all of the other vendors to do the same then I am fine with that.   
But I don't think that is even a remote possibility.  On the other hand the 
PDF CM solution is being worked on right now and should be usable, at least 
for testing, in the not too distant future.  When this happens users using 
your drivers will end up with CM without you doing anything if they are 
sending PDFs to CUPS.   In the long run this will benefit everyone.

> and, then, the printer-driver dithers and performs
> color-to-ink conversion 

This is where dithering and half toning belong and the color management 
transformation that takes place in the pdftoraster filter should target the 
color and tonal characteristics that result from the driver doing these 
things.  And of course only the printer driver can handle the color to ink 
processing, forgetting for the moment that this could also be handled with 
deviceN printer profiles if the driver had deviceN support like the gutenprint 
drivers do.

> you have high risk of creating artifacts in the
> final print.  

Only if your assumptions are correct and I don't think all of them are.
 
snip
> I bet that neither openoffice nor firefox cares about PDF; what they
> prefer is that the GDI they are using supports a printer deviceContext
> and they just "display" to the printer deviceContext and deviceContext
> generate the print content (image, pdf, ps, cups raster, foo....)

This is probably correct for some applications but I think there are two sets 
of exceptions and these exceptions cover a wide range of applications.  

1. For some tool sets like Qt it is a fairly simple thing to create a PDF 
document as the output when using the printer context.  So this means that 
this is a non-issue for KDE/Qt applications and there this may also be true 
for some other tool sets.

2. Many applications already support exporting PDF files.  OpenOffice is an 
example and I think this is true for many other applications that require high 
quality output.  Even if the tool set they use does not support PDF as a 
printer context like Qt it should be fairly simple for these applications to 
use their PDF export code as part of the print work flow. 

So OpenOffice is not be a good example for supporting Glen's argument but his 
point may be more applicable to firefox and some other applications.  At the 
Open Printing Summit a significant part of one session was about issues with 
apps not handling printing correctly or in a consistent way.   Isn't this one 
more thing to consider as part of that list of issues?

>
> > So the dialog would
> > get much more complex if we make it capable of all formats which CUPS
> > can convert. So standardizing on one format simplifies the
> > implementation of the dialog a lot.
>
> Not if the dialog request CUPS to create the preview via it's filters.
>
> > You are now suggesting that the apps can send a wide range of formats
> > (ideally the full range of formats which the stock CUPS package
> > accepts). This would change the internal (not UI) design of the dialog
> > (and the apps) vastly.
>
> Not if the dialog request CUPS to create the preview via it's filters.

But this makes things for CUPS more complex.  For example, setting up things 
on the CPD side to color manage a PDF based preview using a color management 
aware GhostScript or poppler would be fairly easy.  In fact once there is a 
color management aware way to render PDF files the code needed to make the CPD 
do color managed previews is almost trivial (at most 20 lines of code) and 
almost mandatory to have the rendering work correctly.   I have played with 
the poppler Qt demo app along with the CM code that was added to poppler a few 
months ago.  It took perhaps 20 or 30 lines of code to add the CM hooks to the 
poppler Qt4 wrapper library which completed the Qt4 interface for this 
functionality and then it took all of 14 lines of code to make the Qt4 demo 
app color manage PDFs to the display and most of that was XOrg related code to 
get the display profile to setup the transform. 

But to do a color managed preview using the CUPS pipeline requires that CUPS  
to get the display profile otherwise it has no way to know how to create the 
needed color management transforms.  The profile could conceivably be passed 
to CUPS by the application or the CPD but there are issues with this.   CUPS 
will not use a profile that is not logically installed in the 
<prefix>/share/cups/profiles directory of the CUPS server for security reasons 
(at least this was the case - if I am wrong about this please correct me). 
Since the application would need to pass the XOrg _ICC_PROFILE atom there is 
no way currently to pass this to CUPS and even is this were possible CUPS 
would reject it because it in not located in <prefix>/share/cups/profiles 
since the _ICC_PROFILE atom is a memory blob.

Hal

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Till Kamppeter]

Petrie, Glen wrote:
> I tried to explain differently my concerns and hope this long discussion
> continues.   Please, I am not trying being stubborn; I just want to help
> create a solution that is best for the user, the application and driver
> developers (oops, forgot CUPS).  So help me understand some of your
> choices and understand some of my suggestions.
> 
> This discussion is really hard by email, this would be a good one for a
> F2F.
> 
> This note has three issues; namely,
> 
> 1. What to do when the application page-size does not match the print
> page-size.
> 2. Who renders the preview
> 3. Should applications support just PDF print format.
> 
> ==============================================================
> ==============================================================
> ==============================================================
> 1. What to do when the application page-size does not match the print
> page-size.
> 
> I believe it is becoming clearer that the key to this on going
> discussion is how we are thinking about the relationship between 
> 
> Electronic paper-size === Electronic page-size === EPS
>   This is set only by the application
> 
> and
> 
> Physical paper-size === Printer paper-size ===  PPS
>   This is set only by the print dialog
> 
> EPS really has/should-have nothing to do with PPS.  I can have an A3 EPS
> while the printer only support letter.  This is an issue.  This issue
> needs to be handled by the print-system and shown in the print dialog,
> so the user will know what to expect and what to do.
> 
> I think examining this issue is something you really need to actually
> perform; so I tried it on a Mac and Window using PowerPoint.  In either
> system, when the EPS != PPS then the preview show the EPS clipped to the
> PPS (I assume the paper-size (PPS) the currently selected printer
> reports as the installed paper-size (PPS)).  If the scale-to-fit option
> is set; then, the EPS is scaled (maintaining the aspect ratio) to the
> PPS.
> 
> Mac's version of PowerPoint also illustrates more about dialog <->
> application interaction. (I believe Michael already commented on this
> but I will repeat here for completeness).  In the print dialog, you will
> not see a paper-size (PPS) option but you will see a button for
> page-size (EPS).  When this button is pressed, the print dialog returns
> control to the application (powerpoint) and powerpoint shows its dialog
> for the page-size (EPS) (this is completely independent of the print
> dialog).  The user can change the page-size (EPS) and indeed the
> powerpoint pages are reflowed in powerpoint and the powerpoint display
> changes.  Unfortunately, control is transferred automatically to the
> print dialog and user has to cancel the print dialog to fix any changes
> the new page-size (EPS) caused.
> 
> ----- I don't believe this experience was end-user friendly.  If the
> print dialog is not going to have paper-size (PPS), then the user uses
> the preview to see what they will get.  Then if the user does not like
> what will be printed (scale-to-fit or center-and-clip) then the user
> should cancel the print dialog and return to the application to fix
> things.  
> ----- If the print dialog shows a paper-size (PPS) option, then the user
> still uses the preview to see that they will get.  If the user changes
> the paper-size (PPS) then the print-system should scale-to-fit or
> center-and-clip the print content (format at EPS) to the paper-size
> (PPS).  Otherwise, the user needs to cancel the print dialog and return
> to powerpoint to modify things.  This is what I hope is the final choice
> for OpenPrinting.

I think we should go this way. But we should have the choice of taking 
the document paper size so that (if the printer is appropriately 
equipped) documents with multiple paper sizes are printed correctly, 
too. One could warn the user if the document contains pages which the 
printer is not capable of doing (which are not in the printer's PPD nor 
in the range of supported custom sizes if the printer supports custom 
sizes according to the PPD). If a certain paper size is not loaded, the 
printer can prompt for it. The warning that the document contains pages 
which the printer is not capable of, could have buttons to let the user 
choose between scale to fit, crop to fit, and print over several sheets.

> 
> ((( An interesting case to consider is when a photo-printer (PhotoSmart,
> PictureMate) is the connected printer.  )))
> 

You mean printers here which are too small for A4 or Letter?

> I hope we have been saying the same thing but just in a different way.
> 
> ??? Do we have a way to support custom paper size (EPS and PPS) ???
> 

Yes, PPDs and CUPS support it, so it is no problem to support custom 
page sizes in the printing dialog.

> ==============================================================
> ==============================================================
> ==============================================================
> 2. Who renders the preview
> 
> I really do want to push the case where the print-system creates the
> preview from the print-content.  It is really the only way for the print
> preview to display the best representation (we can do today) that the
> printer will actually print.
>

What we do is taking the output geometry from the printer by polling the 
PPD from the CUPS server. We will also poll the ICC profile to allow a 
preview of the color reproduction of the printer. CUPS' page management 
options and their behavior are known so we can emulate them in the 
preview. Also PPD options with known behavior (like grayscale) we can 
emulate in the preview. So the dialog will display the preview based on 
PDF coming from the app.

> 
> ==============================================================
> ==============================================================
> ==============================================================
> 3. Should applications support just PDF print format.
> 
> Till, in general I understand and probably agree with your comments.  
> 
> PDF format is great for documents.  There are concerns about have any
> filters in the print-chain between photo applications and the
> printer-driver (i.e. rendering and re-rendered image).
> 
> Can we support at least one image format or have a way for the filers
> that process PDF to not alter the original images.  
> 

PDF is also important for color management, see Hal's answer. Hal also 
tells that it embeds images, so an image format is not needed and could 
lead to jobs top which color management cannot be applied.

> 
> ==============================================
> Till below are some additional comments on your reply
> 
> 
> [...snip...]
>  
>>> Or are you saying that all drivers must accept/process PDF.
>>>
>> Drivers only need to accept a format which CUPS can generate from the
>> input data. 
> 
> Doesn't CUPS needs to transform (filter) input data to a format the
> driver can accept (image, ps, pdf, ???)!!!
> 

Yes. Therefore sending PDF to CUPS works with all drivers as CUPS can 
convert it with its filters. Drivers usually take PostScript or CUPS 
Raster as input. Ghostscript understands both PDF and PostScript and 
together with Foomatic 4.0 the Ghostscript based drivers also work with 
PDF as input. See the cupsFilter lines in the PPDs. PPDs without 
cupsFilter line take PostScript as input.

>> Usually they accept PostScript and PDF (Ghostscript-based
>> drivers) or CUPS Raster (CUPS Raster drivers). 
> 
> None of Epson's consumer inkjet printers accept PDF or PS; that why
> Ghostscript is needed.  Yes, office printer and high-end printer accept
> PS and PDF - is this the only printers we are targeting.
> 

We target all printers. For non-PDF/PostScript printers CUPS uses 
Ghostscript and a driver.

> Cups Raster is not really "raster" content; it is better described as a
> job-ticket (print-ticket) (actually done at on a page to page if I
> remember correctly) with image data attached.  So it really helps
> (although increase the processing) in rendering pages (to actual printer
> raster).  
> 

Yes, this way it is a printing-optimized image/raster format. The format 
is usually generated by Ghostscript ("cups" output device) from PDF or 
Postscript input (pdftoraster and pstoraster CUPS filters).

> 
> The point is "why the constraints".
> 
> 
>> CUPS converts PostScript
>> and PDF to the driver's input format.
>>
> 
> 
> 
>>> If I have a photo app that wants to print an image. The steps are
>>>
>>> 1. app creates a pdf instantiation of the image
>>> 2. send pdf to print dialog
>>> 3. send pdf to CUPS
>>> 4. CUPS sends pdf to GhostScript to render
>>> 5. Ghostscript creates an image
>>> 6. Image is sent to a printer driver
>>>
>> The image created in 5. is not the same format as the image coming
> from
>> the app. The app sends JPG or PNG, in 5. PCL, ESC/P 2, or CUPS Raster
> is
>> created.
>>
> 
> As a vendor supporting photo printing; print vendors may have an issue
> with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
> changes the colors and, then, the printer-driver dithers and performs
> color-to-ink conversion you have high risk of creating artifacts in the
> final print.  Who will the user call or issue a bug report against - the
> print vendor.  And the user has a bad experience.
>

In 5. we get CUPS Raster. This is not yet dithered. The dithering is 
done by the rasterto... driver.

>>> Versus
>>> 1. app sends image to print dialog
>>> 2. print dialog display image (as preview)
>>> 3. send image to CUPS
>>> 4. Image sent to print driver.
>>>
>> So if all apps send images this would make sense, but apps like
>> OpenOffice.org or Firefox would preferably send PDF. 
> 
> I bet that neither openoffice nor firefox cares about PDF; what they
> prefer is that the GDI they are using supports a printer deviceContext
> and they just "display" to the printer deviceContext and deviceContext
> generate the print content (image, pdf, ps, cups raster, foo....)
> 

and the deviceContext generates Postscript in most cases currently. The 
Qt library generates PDF when printing to CUPS.

>> So the dialog would
>> get much more complex if we make it capable of all formats which CUPS
>> can convert. So standardizing on one format simplifies the
>> implementation of the dialog a lot.
>>
> 
> Not if the dialog request CUPS to create the preview via it's filters.
> 

The CUPS filters are not necessarily installed on the client which runs 
the app. The client can have only the CUPS library (libcups) installed 
and can have an /etc/cups/client.conf file telling on which machine is 
the CUPS daemon which takes the jobs. The local execution of the CUPS 
filters is not possible.

>> You are now suggesting that the apps can send a wide range of formats
>> (ideally the full range of formats which the stock CUPS package
>> accepts). This would change the internal (not UI) design of the dialog
>> (and the apps) vastly. 
> 
> Not if the dialog request CUPS to create the preview via it's filters.
> 

See above.

    Till

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

[...snip...]

> > ----- If the print dialog shows a paper-size (PPS) option, then the
user
> > still uses the preview to see that they will get.  If the user
changes
> > the paper-size (PPS) then the print-system should scale-to-fit or
> > center-and-clip the print content (format at EPS) to the paper-size
> > (PPS).  Otherwise, the user needs to cancel the print dialog and
return
> > to powerpoint to modify things.  This is what I hope is the final
choice
> > for OpenPrinting.
> 
> I think we should go this way. But we should have the choice of taking
> the document paper size so that (if the printer is appropriately
> equipped) documents with multiple paper sizes are printed correctly,
> too. One could warn the user if the document contains pages which the
> printer is not capable of doing (which are not in the printer's PPD
nor
> in the range of supported custom sizes if the printer supports custom
> sizes according to the PPD). If a certain paper size is not loaded,
the
> printer can prompt for it. The warning that the document contains
pages
> which the printer is not capable of, could have buttons to let the
user
> choose between scale to fit, crop to fit, and print over several
sheets.
> 

This is great.

[...snip...]
> > ==============================================================
> > ==============================================================
> > ==============================================================
> > 2. Who renders the preview
> >
> > I really do want to push the case where the print-system creates the
> > preview from the print-content.  It is really the only way for the
print
> > preview to display the best representation (we can do today) that
the
> > printer will actually print.
> >
> 
> What we do is taking the output geometry from the printer by polling
the
> PPD from the CUPS server. We will also poll the ICC profile to allow a
> preview of the color reproduction of the printer. CUPS' page
management
> options and their behavior are known so we can emulate them in the
> preview. Also PPD options with known behavior (like grayscale) we can
> emulate in the preview. So the dialog will display the preview based
on
> PDF coming from the app.
> 

1. I was not aware that the print preview would be concerned with CM.  I
though of it more as what the print format would be and not on the fine
details like "is this the right blue".  I am confused how this works.  I
would have thought the preview would have to use CM stuff for the
display; I guess the preview could use the reduced gamut of the printer.
But, what will the user do with this knowledge.  The best the user can
do is go back to the calling application.  But, if the calling
application cannot adjust the content to account for the intended
printer; then what.  

2. I thought the major emphasis of the current printing activities was
for the desktop.  I didn't really consider that an individual's desktop
(really the computer) would just have CUPS clients and the CUPS server
would hosted some place else.  In mobile/handheld this may be true. 

[...snip...]

> >
> > As a vendor supporting photo printing; print vendors may have an
issue
> > with step 5.  If the filters (i.e. Ghostscript) dithers, halftone or
> > changes the colors and, then, the printer-driver dithers and
performs
> > color-to-ink conversion you have high risk of creating artifacts in
the
> > final print.  Who will the user call or issue a bug report against -
the
> > print vendor.  And the user has a bad experience.
> >
> 
> In 5. we get CUPS Raster. This is not yet dithered. The dithering is
> done by the rasterto... driver.
> 

As Ghostscript is the most critical filter here, I would like to verify
this with the Ghostscript folks.

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Hal V. Engel]

On Friday 24 April 2009 11:33:51 am Petrie, Glen wrote:
snip
> > > ==============================================================
> > > ==============================================================
> > > ==============================================================
> > > 2. Who renders the preview
> > >
> > > I really do want to push the case where the print-system creates the
> > > preview from the print-content.  It is really the only way for the
>
> print
>
> > > preview to display the best representation (we can do today) that
>
> the
>
> > > printer will actually print.
> >
> > What we do is taking the output geometry from the printer by polling
>
> the
>
> > PPD from the CUPS server. We will also poll the ICC profile to allow a
> > preview of the color reproduction of the printer. CUPS' page
>
> management
>
> > options and their behavior are known so we can emulate them in the
> > preview. 

This is called soft proofing and I am not sure that this is a good fit for the 
CPD preview as it adds additional complexity that may only be useful to a 
small subset of users and because of the small size of the preview it may not 
be useful at all.

> > Also PPD options with known behavior (like grayscale) we can
> > emulate in the preview. So the dialog will display the preview based
>
> on
>
> > PDF coming from the app.

This is one place where using a proofing transform may make sense since it is 
possible that the user may be sending a color document to a gray scale device 
and this should be reflected in the preview.

>
> 1. I was not aware that the print preview would be concerned with CM.

If we are using PDF then CM is not optional.  PDF rendering engines are 
required by the PDF specification to use CIE color spaces and ICC profiles to 
do the rendering.  My point was that it is trivial to get the actual display 
profile from XOrg and pass it to the PDF rendering engine so that it can use 
the actual device profile rather than some generic "best guess" profile.  On 
many displays a generic "best guess" profile like sRGB is not ideal but may be 
"good enough" for users who are not doing color critical work.  But wide gamut 
displays are becoming increasingly common and with this type of display using 
a generic "best guess" profile will result in the colors in the preview being 
quite distorted.   These colors will be way too saturated to the point that 
the printed output would be far different from the preview and this will 
likely be an issue for even for users who are not doing color critical work.  
Why have that happen if it can be prevented with a few lines of fairly trivial 
code?

As a side note if the XOrg _ICC_PROFILE atom is not set the CPD should default 
the display profile to sRGB. This is not ideal but if the user has not set the 
_ICC_PROFILE atom then they are likely not too concerned about color accuracy 
and they will probably find the result acceptable if they do not have a wide 
gamut display.

> I
> though of it more as what the print format would be and not on the fine
> details like "is this the right blue".  I am confused how this works.  I
> would have thought the preview would have to use CM stuff for the
> display; I guess the preview could use the reduced gamut of the printer.

Again we are mixing up soft proofing with getting a reasonably accurate 
preview.  I don't think the small preview being proposed is large enough to be 
a workable solution for soft proofing.  Applications where color critical work 
is normally done like GIMP, cinepaint and Scribus already have soft proofing 
as a built in feature of the actual image/document editor (Photoshop and other 
parts of the Adobe suite also do this).  So I don't think soft proofing is a 
requirement for the preview and I agree with Glen that at least for now 
getting and using the correct display profile, if it is set, or a suitable 
default, if it is not set, is what should be done for the preview.

> But, what will the user do with this knowledge.  The best the user can
> do is go back to the calling application.  But, if the calling
> application cannot adjust the content to account for the intended
> printer; then what.

Glen is correct.  Only users who are using apps that can correct for this (IE. 
GIMP, cinepaint, Scribus...) need soft proofing and then they need it directly 
in the app so that they see the affects of those edits on the soft proof as 
the changes are made.

Hal

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

Thanks for clarification on the color management side of things.  My
concern is a little different, and is about whether or not Ghostscript
will dither/halftone the image independent or in connection with of CM.
But, if I understand correctly, Ghostscript will only dither/halftone if
requested.  So, for the case I was describing, the printer driver will
do the dither/halftoning along with conversion from color-to-inks and
print control language stuff.

This sounds like a good approach; printer drivers may not (maybe they
should not) worry about the complexities of CM; there are better
applications, filter, processes for that.  Printer driver, however,
should and need to focus on dither/halftone and color-to-inks processing
that is device dependent anyway.

Back to preview; the preview cares (may care) about the CM but
won't/can't care about the dither/halftone.  (I won't get into how
dither/halftone may affect the CM!!!).


glen


> -----Original Message-----
> From: ralph.giles@artifex.com [mailto:ralph.giles@artifex.com] On
Behalf
> Of Ralph Giles
> Sent: Friday, April 24, 2009 12:46 PM
> To: Petrie, Glen
> Cc: Till Kamppeter; printing-architecture@lists.linux-foundation.org;
> printing-summit@lists.linux-foundation.org; Michael Vrhel
> Subject: Re: [Printing-summit] [Printing-architecture] Print
> Dialog:PreviewProcessing: Only A Question
> 
> On Fri, Apr 24, 2009 at 11:33 AM, Petrie, Glen
> <glen.petrie@eitc.epson.com> wrote:
> 
> >> In 5. we get CUPS Raster. This is not yet dithered. The dithering
is
> >> done by the rasterto... driver.
> >
> > As Ghostscript is the most critical filter here, I would like to
verify
> > this with the Ghostscript folks.
> 
> Till and Mike are more expert here, because it's not what ghostscript
> does, but what cups asks it and the driver together to do.
> 
> I don't think we have real colour management working yet. The cups
> raster format can accept halftoned images, in which case gs can do the
> halftoning. Normally, I think the driver does the halftoning, in which
> case ghostscript generates a continuous-tone cups raster.
> 
> Ghostscript has to do *some* colour management because the input pdf
> could have different components in different colour spaces. Right now,
> I think everything gets converted to some 'device space' and then goes
> through some hard coded transformations in both ghostscript's graphics
> library and the cups raster driver to get the right number of
> components. Aside from applying an rgb matrix that looks like it came
> from the cups ppd, I don't see any attempt at calibrating these colour
> spaces.
> 
> The point of the work Michael talked about at the summit is that cups
> will be able to supply an ICC profile describing exactly what space
> ghostscript should generate output in. If the application embeds an
> icc profile in the pdf it generates, this will result in end-to-end
> colour management if ghostscript is doing the halftoning. If not, the
> PPD can at least request generation of a cups raster in an
> intermediate space with an appropriate gamut for passing to the
> rasterto* driver, which minimizes conversion loss. The printing dialog
> would supply the screen's ICC profile *and* the printer's profile, so
> ghostscript (or libpoppler, when it also has ICC support) could
> approximate the appearance of the document within the constraints of
> both the printer and the screen gamuts.
> 
> If you don't want gs to do any colour management, then you have to
> ensure that the image and output ICC profiles combine to a null
> transform. The application can do this by looking up the printer
> driver's ICC profile and using that directly. The printer driver can
> do this by accepting sRGB, which would help applications that can't be
> bothered since that's usually the default. As long as the image in the
> pdf has a profile that matches the requested output profile, gs will
> leave the image colour alone and let the next stage do all the work.
> 
>  -r

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

(I know I start getting hate mail....)

My understanding is the same a Michael; printer drivers typically
(mostly, almost always, 'only') accept/expect sRGB.  So, as a starting
place can we say printer driver will be accepting sRGB

BUT

can we also define the approach, design, details of accepting other
inputs.  It may already exist; if so, lets use it as a
stepping-stone/staring-place.   If we can design the hooks in now, it
will be a whole lot easier later.  This is a good area for the CM people
to provide input the printer-driver folk.

For driver developer the real question is how much effort and code will
it take to support.  Also, for at least inkjet processing time can be
critical.

At some point the filter folks need to be involved if something new is
defined.

Glen 

> -----Original Message-----
> From: Michael R Sweet [mailto:msweet@apple.com]
> Sent: Friday, April 24, 2009 2:04 PM
> To: Ralph Giles
> Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org;
> Michael Vrhel; printing-summit@lists.linux-foundation.org
> Subject: Re: [Printing-summit] [Printing-architecture] Print
> Dialog:PreviewProcessing: Only A Question
> 
> On Apr 24, 2009, at 12:46 PM, Ralph Giles wrote:
> > On Fri, Apr 24, 2009 at 11:33 AM, Petrie, Glen
> > <glen.petrie@eitc.epson.com> wrote:
> >
> >>> In 5. we get CUPS Raster. This is not yet dithered. The dithering
is
> >>> done by the rasterto... driver.
> >>
> >> As Ghostscript is the most critical filter here, I would like to
> >> verify
> >> this with the Ghostscript folks.
> >
> > Till and Mike are more expert here, because it's not what
ghostscript
> > does, but what cups asks it and the driver together to do.
> >
> > I don't think we have real colour management working yet. The cups
> > raster format can accept halftoned images, in which case gs can do
the
> > halftoning. Normally, I think the driver does the halftoning, in
which
> > case ghostscript generates a continuous-tone cups raster.
> 
> Right.  All of the original sample drivers included with CUPS and a
> handful of third-party drivers take advantage of the Ghostscript/
> imagetoraster/cgpdftoraster/etc. filters ability to do basic 1-bit
> (and in some cases 2-bit and 4-bit) dithering for the driver.
> However, the rest of the drivers in the world use at least 8-bits per
> component and do their own dithering.
> 
> As for color management, some existing RIP filters (notably the
> CoreGraphics PDF to raster filter on Mac OS X) support the
> cupsICCProfile stuff, and I hope at some point we'll get the same
> support in the Ghostscript driver and imagetoraster filter so that it
> is widely supported.  However, what we've found on Mac OS X is that
> many vendors stick with sRGB and only accept sRGB in their filters (HP
> and EPSON do this almost exclusively), so an important first step is
> to ensure that our default RGB profile matches sRGB (and that's what
> CUPS defines for both CUPS_CSPACE_RGB and
> CUPS_CSPACE_W - gamma 2.2 with sRGB primaries - while CUPS_CSPACE_CMYK
> and CUPS_CSPACE_K are defined as device-specific...)
> 
> Drivers like Gutenprint can also use CMYK, which is where color
> managed workflows really start getting interesting, and that is where
> a CM-enabled preview can provide a real color proof of what will be
> printed.
> 
> > Ghostscript has to do *some* colour management because the input pdf
> > could have different components in different colour spaces. Right
now,
> > I think everything gets converted to some 'device space' and then
goes
> > through some hard coded transformations in both ghostscript's
graphics
> > library and the cups raster driver to get the right number of
> > components. Aside from applying an rgb matrix that looks like it
came
> > from the cups ppd, I don't see any attempt at calibrating these
colour
> > spaces.
> 
> Right, that's pending work for the CUPS backend in Ghostscript (along
> with cupsBackSide and proper RGBW support...)
> 
> > The point of the work Michael talked about at the summit is that
cups
> > will be able to supply an ICC profile describing exactly what space
> > ghostscript should generate output in. If the application embeds an
> > icc profile in the pdf it generates, this will result in end-to-end
> > colour management if ghostscript is doing the halftoning. If not,
the
> > PPD can at least request generation of a cups raster in an
> > intermediate space with an appropriate gamut for passing to the
> > rasterto* driver, which minimizes conversion loss. The printing
dialog
> > would supply the screen's ICC profile *and* the printer's profile,
so
> > ghostscript (or libpoppler, when it also has ICC support) could
> > approximate the appearance of the document within the constraints of
> > both the printer and the screen gamuts.
> 
> Like I said, most vendor drivers want RGB data (and usually sRGB).
> CMYK is often not supported directly (the CM code has to convert to
> the destination colorspace regardless...)
> 
> ____________________________________
> Michael R Sweet, Senior Printing System Engineer
> 
> 

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Hal V. Engel]

On Friday 24 April 2009 02:20:50 pm Petrie, Glen wrote:
> (I know I start getting hate mail....)
>
> My understanding is the same a Michael; printer drivers typically
> (mostly, almost always, 'only') accept/expect sRGB.  So, as a starting
> place can we say printer driver will be accepting sRGB
>

No this is nonsensical.  Most printer drivers accept RGB input and many of 
these expect it to be sRGB but some accept many other forums of input.  The 
GutenPrint drivers, for example, accept RGB, CMYK and DeviceN input and these 
are some of the most common drivers on Linux systems. 

Getting the print content in the right color space for the printer is the job 
of the ICC printer profile(s) and the color management engine (and depending 
on exactly what is being printed some other parts of the printing pipeline way 
need to be involved).  If your driver only accepts (or is expecting) sRGB then 
simply setup the PPD file so that cupsICCProfile is set to a file that has an 
sRGB profile and set it up so that this sRGB profile is the only profile ever 
used.  Assuming (I know not a good thing to do) that the printing pipeline has 
CM support and handles this correctly you don't need to do anything else and 
your driver will only ever get sRGB unless the user does something to override 
that setting.  Overriding this will happen only when a very experienced user 
decides that the printer (IE. meaning his/her printer with his/her 
paper/inks/settings) is not really sRGB and it needs a different profile.

As an aside.  Even though sRGB is sort of a default color space and most stuff 
has been tuned to work OK (sort of, maybe) using it most "sRGB devices" really 
are not truly sRGB.  In other words almost any "sRGB device" can benefit from 
having custom profiles created.   This is particularly true for printers. 

The correct thing to say is that printer drivers can accept many different 
color representations (even if many can only accept RGB) and it the job of the 
color management system to allow for the management of the proper conversion 
of any print job into the printers actual color space.  If you set things up 
correctly no one other then the driver vendor cares what color spaces the 
driver accepts all that matters is that the PPD file correctly specifies the 
ICC profile(s) that characterize that printers color space so that printing 
pipeline passes the printer driver input in the color space it expects.

> BUT
>
> can we also define the approach, design, details of accepting other
> inputs.  It may already exist; if so, lets use it as a
> stepping-stone/staring-place.   If we can design the hooks in now, it
> will be a whole lot easier later.  This is a good area for the CM people
> to provide input the printer-driver folk.

Again the hooks are getting CM working with the most common printing work 
flows.  With a CM aware pdf work flow we have a path that can work for the 
vast majority of user applications that can accept input in any color space 
and convert it into whatever color space the printer needs.

>
> For driver developer the real question is how much effort and code will
> it take to support.  

None if you let the *toraster filters and the CM engine handle it.

> Also, for at least inkjet processing time can be
> critical.

The *toraster filter that have CM support will run slightly slower but not 
much.  But this will not affect the drivers at all are far as performance is 
concerned.  The only thing the driver suppliers need to do is to make sure 
that profiles are correctly specified in the PPD files for the printers they 
support.

>
> At some point the filter folks need to be involved if something new is
> defined.

Isn't this what is happening now with the GhostScript work and the work that 
will be happening with the pdftoraster filter when the GhostScript CM work is 
far enough along?

>
> Glen
>
> > -----Original Message-----
> > From: Michael R Sweet [mailto:msweet@apple.com]
> > Sent: Friday, April 24, 2009 2:04 PM
> > To: Ralph Giles
> > Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org;
> > Michael Vrhel; printing-summit@lists.linux-foundation.org
> > Subject: Re: [Printing-summit] [Printing-architecture] Print
> > Dialog:PreviewProcessing: Only A Question
> >
> > On Apr 24, 2009, at 12:46 PM, Ralph Giles wrote:
> > > On Fri, Apr 24, 2009 at 11:33 AM, Petrie, Glen
> > >
> > > <glen.petrie@eitc.epson.com> wrote:
> > >>> In 5. we get CUPS Raster. This is not yet dithered. The dithering
>
> is
>
> > >>> done by the rasterto... driver.
> > >>
> > >> As Ghostscript is the most critical filter here, I would like to
> > >> verify
> > >> this with the Ghostscript folks.
> > >
> > > Till and Mike are more expert here, because it's not what
>
> ghostscript
>
> > > does, but what cups asks it and the driver together to do.
> > >
> > > I don't think we have real colour management working yet. The cups
> > > raster format can accept halftoned images, in which case gs can do
>
> the
>
> > > halftoning. Normally, I think the driver does the halftoning, in
>
> which
>
> > > case ghostscript generates a continuous-tone cups raster.
> >
> > Right.  All of the original sample drivers included with CUPS and a
> > handful of third-party drivers take advantage of the Ghostscript/
> > imagetoraster/cgpdftoraster/etc. filters ability to do basic 1-bit
> > (and in some cases 2-bit and 4-bit) dithering for the driver.
> > However, the rest of the drivers in the world use at least 8-bits per
> > component and do their own dithering.
> >
> > As for color management, some existing RIP filters (notably the
> > CoreGraphics PDF to raster filter on Mac OS X) support the
> > cupsICCProfile stuff, and I hope at some point we'll get the same
> > support in the Ghostscript driver and imagetoraster filter so that it
> > is widely supported.  However, what we've found on Mac OS X is that
> > many vendors stick with sRGB and only accept sRGB in their filters (HP
> > and EPSON do this almost exclusively), so an important first step is
> > to ensure that our default RGB profile matches sRGB (and that's what
> > CUPS defines for both CUPS_CSPACE_RGB and
> > CUPS_CSPACE_W - gamma 2.2 with sRGB primaries - while CUPS_CSPACE_CMYK
> > and CUPS_CSPACE_K are defined as device-specific...)
> >
> > Drivers like Gutenprint can also use CMYK, which is where color
> > managed workflows really start getting interesting, and that is where
> > a CM-enabled preview can provide a real color proof of what will be
> > printed.
> >
> > > Ghostscript has to do *some* colour management because the input pdf
> > > could have different components in different colour spaces. Right
>
> now,
>
> > > I think everything gets converted to some 'device space' and then
>
> goes
>
> > > through some hard coded transformations in both ghostscript's
>
> graphics
>
> > > library and the cups raster driver to get the right number of
> > > components. Aside from applying an rgb matrix that looks like it
>
> came
>
> > > from the cups ppd, I don't see any attempt at calibrating these
>
> colour
>
> > > spaces.
> >
> > Right, that's pending work for the CUPS backend in Ghostscript (along
> > with cupsBackSide and proper RGBW support...)
> >
> > > The point of the work Michael talked about at the summit is that
>
> cups
>
> > > will be able to supply an ICC profile describing exactly what space
> > > ghostscript should generate output in. If the application embeds an
> > > icc profile in the pdf it generates, this will result in end-to-end
> > > colour management if ghostscript is doing the halftoning. If not,
>
> the
>
> > > PPD can at least request generation of a cups raster in an
> > > intermediate space with an appropriate gamut for passing to the
> > > rasterto* driver, which minimizes conversion loss. The printing
>
> dialog
>
> > > would supply the screen's ICC profile *and* the printer's profile,
>
> so
>
> > > ghostscript (or libpoppler, when it also has ICC support) could
> > > approximate the appearance of the document within the constraints of
> > > both the printer and the screen gamuts.
> >
> > Like I said, most vendor drivers want RGB data (and usually sRGB).
> > CMYK is often not supported directly (the CM code has to convert to
> > the destination colorspace regardless...)
> >
> > ____________________________________
> > Michael R Sweet, Senior Printing System Engineer
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Tobias Hoffmann]

Petrie, Glen wrote:
>
> n       Removes bi-directional communication between the application 
> and print dialog; that is, printing is handed off operation to print 
> dialog.
>
If the CPD will be extensible by the application, bi-directional 
communication has to be there, anyway.
In my understanding, e.g. for Thunderbird, essentially all the "Page 
Setup..." will move into the CPD (?)
So don't forget about the "Portrait / Landscape"-Option, which requires 
the application to generate a new preview.

  Tobias

Re: [Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]


> n       Removes bi-directional communication between the application
> and print dialog; that is, printing is handed off operation to print
> dialog.
>
If the CPD will be extensible by the application, bi-directional
communication has to be there, anyway.
In my understanding, e.g. for Thunderbird, essentially all the "Page
Setup..." will move into the CPD (?)
 
[gwp] I did not know this was an intent; I typically don't think of application page setup related to printing other than the application typically needs to know the minimum margins.
          So, in this case the dialog will change any "PRINT" button to "OK" and return to applicatoins
 

So don't forget about the "Portrait / Landscape"-Option, which requires
the application to generate a new preview.
 
[gwp] Yes, all apps typically have a landscape/portrait.  But when printing n-up within the dialog this has the meaning of orientation of the n-pages on the printed-page and really not done by the application. 
 


  Tobias


[-- Attachment #2: Type: text/html, Size: 1726 bytes --]

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

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

 

 

________________________________

From: Michael R Sweet [mailto:msweet@apple.com] 
Sent: Wednesday, April 22, 2009 9:29 AM
To: Petrie, Glen
Cc: printing-architecture@lists.linux-foundation.org;
printing-summit@lists.linux-foundation.org
Subject: Re: [Printing-summit] Print Dialog: Preview Processing: Only A
Question

 

On Apr 22, 2009, at 9:13 AM, Petrie, Glen wrote:

	...

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

 

OK, here are some more Mac'isms...

 

Applications choose whether the page size chooser is displayed in the
print dialog. For page-based applications, it makes more sense for the
application to pre-select the page size and margins since the user is
formatting their document for that size. For other applications (email,
web browser, image viewer, etc.) it makes more sense for the page size
control to be in the print dialog since pages and page size have no
meaning unless you are printing.

 

[gwp] This is a perfect solution and I would like to encourage this idea
for OpenPrinting.

 

 

 


[-- Attachment #2: Type: text/html, Size: 8311 bytes --]

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

[peter sikking]

Wow guys,

that discussion is sort of mushrooming, so I'll have to cover
stuff here in sweeping summaries.

Some things discussed here have been 'designed in' for
a long time:

- applications shall be able to pre-set printing parameters in
   the dialog, for when they know from their domain knowledge
   what is the "correct" value;

- applications shall be able to hide standard printing parameters in
   the dialog, for when they can supply a more advanced control(s)
   that take into account the application domain. I expect the
   application to decompose the advanced control value(s) partially to
   control their own transformation and partially to set those
   hidden standard printing parameters.

The two above cover a lot of the page formatting app + printer
cooperation scenarios you are sketching. When discussing this
"application is paper-based" scenario, we should not forget
that is an exception:

<http://www.mmiworks.net/eng/publications/2008/07/to-istanbul-via-tokyo.html#rule4 
 >

but it is an exception that we have planned for and that is handled
by the principles above. Since the application rules in its domain,
it should be able to take over and take full responsibility of the
page size, margins, orientation when it needs that. This is
a structural requirement to get the apps on board. At the end the
printing infrastructure service is (seen as) part of their app.

(and building in go-it-alone overrides from the printer side
can create massive usability problems).

Transformation parameters update:

yes, I can see that scaling is one that the app should know about.

also seeing the discussion about 'scale to fit' I tend more
and more to see that as an application exclusive parameter.
As Tobias said: "Only the application knows the "right" way
to print it's  content onto a differently sized paper"

Till wrote:

> There can be documents which have different page sizes, for example  
> page
> 1 and A4, page 3 A3 and page 4 A4 again. With "Document Page  
> Size(s)" an
> appropriately loaded printer will take A4 paper for the pages 1, 2,  
> and
> 4 and A3 paper for page 3. All selections of a concrete page size will
> let the printer print all pages on the same paper size, using  
> different
> scaling factors if needed.

this is an excellent example why applications must be fully in
control of getting it on paper (it knows what is on those 4 pages).

Then there is a lot of talk about if application need to re-render,
reformat their transformation. the transformation of data and putting
it on paper is a holistic part of the print job, that is why the
parameters controlling it are in the print dialog. they must, else
the simplest things stop actually working. my example:

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


shows this in all its simpleness. It make a real difference to
users if a web page is going to print on 3.1 or 2.9 pages.
This example works today on OS-X, and makes me confident
that is is not outrageous to engineer a framework to facilitate
this for linux applications + printing.

The phase we are now in is the 40% phase. I see this in every
project in my interaction architecture practice:

I present the design that solves lots of usability issues,
and the engineers respond with: I think we can achieve only
40% of that. What happens then is that the engineers actually
start checking out and testing what can be done, and at the
the end of the project we achieve by cooperation 90% of the
goals that I had set for the project.

So knowing Till and having met Lars in SF, and knowing how they
both see the point of the usability innovation in the designs,
I am optimistic about what we can achieve here.

Johannes Meixner is worried about what it will take to make
the preview accurate enough. I suspect now that everybody here
has a different perception of "accurate enough", and that everybody
is not that sure that their counterparts in this conversation
has the same perception.

I say it is only a (fixed) 225 or so pixels on the longest side
of the preview page. It is a really complex mix of any change
users make in the dialog being reflected straight away in the
preview (where possible), and the fact that being a millimetre
off in the display is not that bad. It is all in the
UI designer-developer cooperation to sort that out, one by one.

Now about those ppd-only postscript printers: does not the
the standardisation of the whole printing process point at
a standardisation of how that can be reflected in the
preview?

     --ps

         founder + principal interaction architect
             man + machine interface works

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