OpenPrinting Summit - Print Dialog and Colour Management

Christoph Bartoschek bartoschek at
Sun Mar 20 21:37:31 GMT 2011

Am Sonntag 20 März 2011 schrieb John Layt:
> Hi,
> Some very good points, some definately belong in the dialog, others belong
> in CUPS itself, but I'll take them all with me as everyone will be at the
> summit.

For me as user it does not matter where it is implemented. However I think 
this all should be controlled by the print dialog. I do not want to have some 
options in the cups configuration and some options in the print dialog. There 
will definitively be conflicts between the options and users will be 
confused. I would like to compare it with the mess one has with volume 
control.  There are about 5 levels on which I can control the volume on my 
system. This are 4 too much.
For printers a similar issue is the portrait/landscape mode.  This can 
sometimes be specified in the application, the print dialog and the cups 
system.  It never works as expected.

> > - My biggest wish for a printing dialog is that the preview exactly
> > matches the output. All current print dialogs that I know on linux have
> > the problem that the output is not really predictible if one goes away
> > from the default: printing A4 portrait to an A4 portrait printer.
> This is actually a very hard thing to do, basically it would involve
> asking the print system (in our case CUPS) to process the print job right
> up to the point of sending it to the printer, then to give us back the
> processed job to use for the preview which would be close, but there's
> always a conversion process from the job format (was ps, soon to be pdf)
> into the printer format (e.g. PCL) as there's very few printers that
> speak ps or pdf natively.  So there's always a chance something will
> still not look right.  All this back- and-forth of course adds overhead
> and slows the process down.  I know there's a wish for this in the CUPS
> bugzilla.
> At the moment the CPD uses poppler to render the pdf print file as the
> preview, and then does manipulations on that pdf to simulate what CUPS
> would do.  I assume the filters it applies to the preview pdf are the
> same ones used in CUPS so it should be fairly close.

If one only uses poppler to simulate the processing of CUPS then the dialog 
is a failure. There will definitively be differences which lead to confusion.

In my opinion CUPS should not do any processing but just convert a PDF to the 
printer`s language and send it to the printer. The print dialog can then 
apply all necessary filters to get the desired output. This is the only way 
to ensure that the output is as expected.

> > - The choice of the output paper size and tray should be more prominent.
> > I have one printer where I can find the paper size only in the General
> > tab at the last position of 50 options.
> The design of the CPD is that all the options will appear in the one area,
> no more tabs or separate Properties dialog.  To control what options
> appear at any one time there will be a number of filters you can apply
> and even a search box.  You'll also be able to save groups of presets. 
> The default should be the most commonly used options.  It's the polish on
> this stuff that the dialog is currently lacking and is planned for this
> years GSoC.
> It will be interesting to see if this works as well in practice as the
> usability engineers designed it to.
> > - There should be visual feedback how the document applies to the paper.
> > What happens if I print an A4 document and select an A5 paper? How can I
> > specify that the document has to be shrunk to fit?
> > 
> > - For duplex printing I would like to see a left and right page or top
> > and down page side by side in the preview.
> > 
> > - The preview should optionally show the media borders, the printable
> > area borders and the document borders on the media.
> These should all be part of the dialog preview, I'll see if it's in the
> design or not, it could be one of the unimplemented things.
> > - Is it possible let the dialog shrink the document by a given
> > percentage and to align the document on the paper to have more empty
> > space on the left for a hole-puncher
> This is usually best achieved using a word processor and setting different
> margins for odd/even pages, but not every app can do that, so it sounds
> like a good idea for CUPS to implement.  CUPS can certainly apply the
> shrink, and it can apply the paper margins, but I don't think it can
> currently vary the margins based on page being odd/even.

I have the problem when I am printing scientific papers. Printing documents 
that are designed for letter on A4 printers results in very small margins.  

> > - Is it possible to print an A5 document on A4 paper centered with
> > optional with crop marks at the border?
> I've think I've seen Adobe Acrobat do that on Windows?  It would be a nice
> CUPS option, but something the dialog could generate too with a filter.
> > - Will the applications be able to change the document and send a new
> > preview as soon as the options change?
> Yes, that's part of the protocol, as soon as any option that affects the
> document layout changes (as opposed to affecting the printed page layout),
> then the dialog tells the app and requests a new preview.  It will be
> interesting to see what performance lag there is as a result.

Could you please explain the difference between document layout and printed 
page layout?

If I understand it correctly one has for exmple two page sizes.  The page 
size the application should print to and the media size. 

For example there is a huge difference between the following scenarios for a 
word processor:

- Lay out for A5 and print two resulting pages on a A4 sheet.
- Lay out for A4, and print two resulting pages on a A4 sheet after shrinking 

Both scenarios however should also be possible if the input is already 
finished. Think of a Latex document that is rendered for A4 and A5. I do not 
think that Latex will ever use the printing dialog directly for its options.

However I do not see how to do this with the current dialog.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list