Bug 129250

That's not a kdpf bug, but a kdeprint one

That's due to the internal handling of the number-up options when sending a file to a printer (this option is then by the print spooler, not kdeprint). I'm pretty sure that you get correct results in the final printed version.

However, this inconsistency is not easy to solve if you want to use the full post-processing capabilities of CUPS and provide a correct preview. Both are actually not possible.

Michael, the Apple printing developer I met in Atlanta a few weeks ago got from me this precise question (how they handle preview of CUPS-managed printing options) and he said that they "emulate" what CUPS does by inserting psnup (and other filters) in the chain of commands used to generate the preview. So, what is previewed is not actually the file that would be sent to CUPS in the end, but a duplicate of the original that is then modified for display according to user's requests. And it's then the original that it's sent to CUPS.

I wasn't surprised by his answer, since this was my first (and as such discarded as dumb) solution that I thought of when I saw this bug report first (it's a dupe btw, I'll fix this soon).

I think that in the next iteration of the KDEPrint toolkit, we will have to consider this solution more closely.

I don't exactly understand what the issue with "full post-processing capabilities" is, but as a first work-around the job can be printed into an temporary pdf or ps file wich could be shown.

As user I simple compare KPDF with Adobe Acorbat Reader where the print-preview is really nice.


@Michael Goffioul:
There is a second bug which causes incorrect print results. Please have a look: http://bugs.kde.org/show_bug.cgi?id=129249

Stefan, Michael is a very knowledgeable developer of printing technology. Trust us, it's not as simple as it seems.

KDE, faithful to its principle that requires to reuse good technology when available, instead of reinventing the wheel, chooses to rely on CUPS for most of its printing features. There are many advantages to this approach. And a few drawbacks. One of which is that CUPS has to he handed a fairly raw piece of data, in form of a PS file, as generated by the application requiring printing, to which KDEPrint adds the set of options the user requires and which will be used _by CUPS_ to manage the print job.

Now, keep in mind, CUPS can run on a remote server, thus communicating back and forth large pieces of data isn't easily acceptable.

What do you mean by "compare KPDF to Acrobat Reader"? Acrobat Reader on my machine doesn't have a preview at all. I choose to print through "kprinter" command exactly so that I get a decent configuration tool. Please elaborate.

As I mentioned, we will at least try to look at solutions for the request you have.

Thank you

Created attachment 16650 [details]
screenshot of adobes acrobat reader print preview

@Cristian: Your Acrobar Reader Version seems to be too old. With Version 7 you
get something like in the screenshot (german).

Please try it yourself. Change the Options around and watch how they affect die
print-prewiew directly.

Adobe reader handles 2-up printing itself, it does not relies on external tools (like psnup or CUPS) to do it. That's why you can see directly the result. KDE relies on external tool to produce n-up printing:
- psnup: when printing to a pseudo-printer (like "print-to-PS"), it then have access to the result *before* sending the data to CUPS
- CUPS: when printing to a real printer, it then have *not* access to the result

At the time I wrote the code, I implemented a mixed of both. At that time, there was nothing, so it was better anyway. However, it now reveals inconsistent and confusing. The Apple-way is the easiest, but you have to be sure that psnup will match *exactly* what CUPS will do; otherwise people will complain pretty soon. I also see 2 other solutions:
1) use psnup in all cases, but you loose something if the CUPS implementation provides more features (and you need psnup installed to make things work)
2) handle n-up printing in Qt/kdeprint transparently, using automatic scaling and rotation in the paint device; this requires much more work from the developper; you could also think about the same to perform page selection.

I'm changing this bug report as to "Confirmed"/NEW and turn it into a wishlist item for KDE4.

As for the implementation of a preview which will guarantee an identical result as the processing by CUPS is .... let the preview be done by CUPS. :-P

Instead of calling psnup to do the n-up call the CUPS filtering chain (consisting of a single filter for now):

  $(cups-config --serverbin)/filter/pstops \
                                           99999 \
                                           $USER \
                                           "KDEPrint Preview n-up" \
                                           1 \
                                           number-up=$number \
                                           $tmp_file_waiting_for_printing.ps
where arguments:
  $1: 99999                   -- a dummy job ID
  $2: $USER                   -- the username
  $3: "KDEPrint Preview n-up" -- the job title
  $4:  1                       -- number of copies
  $5: number-up=$number       -- number for n-up
are of type and order as CUPS expects them for its filters.

To get correct results, the CUPS-specific env var $PPD for the target printer  (plus some more, such as CHARSET, CONTENT_TYPE, PRINTER, CUPS_FONTPATH) would need to be set as well (and maybe even *all* options like for the final job should be sent as $5).

Advantage:
  - exact same preview result should be ensured (outcome of pstops filter)
    as for the "real" printrun 

Drawbacks:
  - possibly slow; runs same file through pstops filter twice in case preview
    is selected
  - of course this would not work if there is no local CUPS installation (but
    if printing only happens thru a remote CUPS server), 
  - it may not work perfectly, if local and remote CUPS versions are different

In case no local pstops filter is available (== no local CUPS server installed) we could fallback to using psnup, if no psnup just show the "raw" PostScript file (like now), and inform the user in each case that the preview is only an "approximation".

Duplicate of bug 59718 (in a way, even if not exactly).

*** This bug has been marked as a duplicate of 59718 ***