Comment 36 for bug 382379

NoOp, Hardy had a completely different workflow, here Inkscape produced PostScript, CUPS did page management on PostScript and then cups-pdf turned the PostScript to PDF with Ghostscript. Ghostscript's "pdfwrite" output device does not turn text characters into bitmaps.

From Intrepid on, the printing workflow is PDF-centric. Applications are supposed to send PDF to CUPS, like many applications including Inkscape do, and CUPS to do the page management on PDF. The pdftops filter of CUPS is primarily a PostScript printer driver in this scenario, but also a fallback if some printer driver is not adapted to the new workflow, like cups-pdf.

Most printer drivers are raster drivers, and printed paper you cannot magnify arbitrarily. So there the rasterization of the document by the pdftops driver is no big problem. cups-pdf plays a special role as it is a vector driver creating PDFs for screen view, with the option of arbitrary magnification. The best output quality you get here if you avoid unneeded conversions. Therefore I have reported bug 385709 where I suggest simple changes in cups-pdf to accept PDF directly to avoid conversion to PostScript and back to PDF.

cups-pdf is also not necessarily needed nowadays, as most applications (at least all KDE and GNOME applications, and also OpenOffice.org) can generate PDF without a special CUPS queue, either via "Print to file" or via "Export as PDF". Therefore cups-pdf was already demoted to Universe and not shipped on the CDs any more.