Bug 117344

It would be possible if the print preview were PDF, but it's PostScript.

Let's see what brings Qt4 in the domain of PS and PDF (yesss!) rendering. I am looking into using PDF as primary rendering. Yet, should be understood that "libraries" like xpdf and gs have many more years of experience with PDF rendering and we should look forward for a quite intensive debugging session for Qt4 ;-)

So, yes, I know about the slow preview problem, I intend to tend to it, but for now I will have to look after more pressing things.

Thanks.

Will all applications start sending kdeprint PDF input instead of PS?

No, I don't think so. In the end, I can't answer for all apps. But I guess some (like koffice suite) will be able to generate pdf directly. Another example is kpdf. Some modern printers (e.g. Ricoh printers) have pdf interpreters in their engines. So, for printing from kpdf to such a printer, why convert the pdf to ps for preview/processing with kdeprint then from ps to pdf for actual printing?

I guess kdeprint with _also_ support pdf rendering.

Yeah, now that would be nice.

Aside from those printers, I don't see how kpdfpart would help: applications generate PostScript and CUPS expects PostScript.

Actually, CUPS also supports PDF, but it probably converts it to PS first. Indeed, PPD options are given PS commands, hence to process a print data file to insert those commands correctly, it has to process PS data. To make it short, I wonder how a print spooler would handle driver options from PPD, with an input PDF file, if it does not convert it first to PS.

Michael.

Today, I needed to print a 2 Megapixel photograph. It took KGhostView 16 minutes (!!) to render a print preview. 

I wanted to find out how much faster this could be, so I printed the image to PDF and viewed it in KPDF. The PDF generation took about 10 seconds, KPDF displayed the PDF file within one second.

Conclusion: Using PDF in stead of PS is about 1000 times faster...

The problem of the PDF approach is, I guess, that the PDF version may not be 100% identical to the PS data which is sent to the printer, which means that it is no longer a real print preview. 

I guess this huge speedup of the print system can only be achieved when either Ghostscript bitmap rendering is optimized, or Poppler gets support for rendering ghostscript files.

Correct?

Support for postscript rendering in KPDF has been requested in Bug 120933.

Unfortunately, when the image is actually sent to the printer, CUPS will still need to render it using Ghostscript...

@ comment 5:

   Yes, Thiago, for now CUPS expects PostScript, but it can also handle it
   already if it receives PDF.


@ comment 6:

   Yes, if CUPS gets PDF, it runs its pdftops|pstops filter chain where pstops
   inserts the device specific jobsettings

CUPS is set to support direct PDF processing in the near future as well (and the players who participated in the Desktop Printing Summit in Atlanta 2005 all agreed to move over to PDF over time). My guess is that direct PDF processing would use the industry standard "JobTicket" format, and it would be CUPS' task to process (as well as generate) such a JobTicket for all cases need (like, if the target device should be sent PDF instead of PostScript).

However, you can be pretty sure that PostScript will be around for a long time still. First, CUPS will continue to support it. Second, all current and future PDF print devices will have PostScript support too. Third, for all non-PS/PDF printers, PostScript will probably remain an importat intermediate format in the processing of the jobfile (conversion by CUPS).

I marked this as a wishlist item for KDE4.

@ comment 1 (Thiago):

  * BTW, you *can* use kpdf as a PostScript viewer (it cheats, and runs ps2pdf
    first).

This has a few pros and a few cons:

  cons: - running ps2pdf first slows down a *little* the start of the preview 
        - the PDF displayed on screen may differ visually from PS print on paper
  pros: + kpdf can *scale* the preview
        + kpdf can possibly *search* the preview (depending on embedded fonts)
        + kpdf/PDF may, overall, be much faster in rendering *certain* files

I've set up my own KDEPrint to use kpdf as the preview program (run "kaddprinterwizard --kdeconfig" --> "Preview" to do so) and I've yet to find some major glitch.

I'm not at all aware how kghostview is in shape for KDE4 and what its longterm roadmap is. But I suggest to set kpdf as the default print preview program now in KDE4 SVN; it'll be a test run by these few developers who actually do print previews when they run compiled KDE4 SVN code (and it can easily be reverted after a while, and peole who don't like it can easily re-enable kghostview for themselves).

In KDE4 there is a new KPrintPreview class that uses QPrinter to create a PDF preview file and calls the PDF KPart to display it, i.e. Okular.  So this is one KDEPrint KDE4 idea that did get implemented.  

Closing.