Re: Printers using free software only
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
Reply to: