On Tue, Jul 31, 2012 at 07:43:13PM +1200, Chris Bannister wrote: > On Mon, Jul 30, 2012 at 04:51:11PM +0000, Camaleón wrote: > > I just wanted to point a scenario where the jump to a PDF filter as the > > default backend can have its troubles and not be nor as good nor as > > simple nor as easy as the white papers say. Companies have always showed > > different needs than users and these "jumps" are seen differently when > > you have to hold them as user or as admin. > > The understanding I got from reading Roger's post was that if you are > using CUPS, *THEN* you are automatically using "a PDF filter paradigm" > because it **is considered superior/"more robust"**. > > The discussion of whether it **actually is** superior/"more robust" is > irrelevant, and better discussed with the CUPS developers. :-)
This is pretty much the case. I'll address a few of the points in this thread here to save writing many separate replies: 1) What is a PDF printer? It's a printer you can submit PDF jobs to directly. Whether this is implemented in software/firmware/hardware is irrelevant--it just needs to be able to accept it and print it. This is completely orthogonal to having a PDF workflow. 2) Having a PDF workflow does not require a PDF printer, any more than having a PostScript workflow (as before) required having a PostScript printer. Since CUPS (and LPRng) implement printing through filters including ghostscript, one can convert any input format to any output format. The only difference is that the intermediary format is now PDF rather than PostScript. 3) PostScript is a crap intermediary format. You can't do page accounting without processing the entire file; PDF can just give you a page count. It can have unbounded complexity and consume lots of CPU and disc; and if the pipeline has multiple steps, you have to do this multiple times; and again on the printer, if it's a PostScript printer. You can't do accurate colour matching; PDF supports embedded colour profiles. You can't easily do rearrangement of the input for n-up, rescaled, or reordered for book printing. These are all things that matter, and which PDF makes a great deal easier, faster, and more robust. PostScript is a *lossy* intermediary format in consequence--you lose information and get lower quality output if the input made use of any features not representable in PostScript. 3) PostScript is a crap input format. Generating it is a pain; you have to output text PostScript, i.e. your program has to generate a program. It's hard to do. It's hard to use fonts, it's hard to use graphics. It's hard to do lots of things. And it lacks modern graphics primitives such as gradient meshes, opentype fonts, transparency, etc. which just aren't representable. Contrast with PDF: we have a multitide of free software libraries which generate PDF, making it simple to do. PNG and JPEG can be embedded directly, without having to be encoded and ballooning the filesize, again with attached colour profiles. 4) PostScript has the document structuring conventions (DSC), which are text comments (%%) in the code; but it's optional, and can be incorrect and buggy itself. PDF has /real/ structure, meaning that it's possible to reliably and simply process the document. 5) Most applications used to output PostScript for printing. They now mostly output PDF. There's a reason for that, linked to (2-4) above. Lots of professional graphics software (e.g. Adobe illustrator, inkscape) uses PDF as either the native format or a supported graphics format. It's not just for output. Even older applications such as LaTeX have long been PDF by default (pdflatex, now xelatex etc.); DVI and PostScript are still supported, but the vast majority of users use a PDF workflow. As does R. It's simply better on all counts. 6) PDF contains tons of junk features. That's right, but they are completely irrelevant for printing and general use in the world outside Adobe. Printing just uses the sensible subset actually used for drawing (obviously). One could argue that having a programming language as a file format is useful. But the main use case is to construct things such as Mandelbrot fractals during printing. The only thing this does is to anger all the other users of your printer as it takes hours to print a single page. The reality is, very little software took advantage of it; it's far easier just to precalculate such things and have a slightly bigger filesize in this special case. Are there any examples of software outputting PostScript containing code any more complex than abbreviated macro expansions? The reality is no, and the number of people writing PostScript by hand is vanishingly small. For all but odd esoteric cases, PDF is objectively better. If you're writing an application which needs to print, you're going to pick PDF, because it's what all the libraries support, and it's objectively better. In the professional world, printing has all been PDF-based for quite some time now. For some of the reasons outlined above, and probably others I don't know about. The changes in CUPS are just the Linux printing ecosystem just catching up with that reality. And it really *is* better. While CUPS is now owned by Apple, the reality is that it would have happened eventually anyway--PDF is already the predominant input format; making it the intermediary format is just a logical consequence of that. (Anecdote: I do not have fond memories of editing buggy PostScript to fix the DSC comments so that tools like psnup, psselect etc. could work with it. This is due to the fragility of the tools in coping with incorrect comments! In contrast, you never have such a situation with PDF unless the file is actually corrupt.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120731093455.gi25...@codelibre.net
