lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The PDF back end


From: Reimer Behrends
Subject: Re: The PDF back end
Date: Mon, 21 May 2001 16:19:19 -0400
User-agent: Mutt/1.2.5i

On Sat, May 19, 2001 at 02:55:14PM +0200, address@hidden wrote:
[...]
> You tell me. My point is that you don't _need_ a programming language to
> explain to a printer where, and in what colour, glyphs, polygons and other
> graphical objects are to be painted on paper, in the same way that you don't
> need a cruise missile to kill a mosquito.

Actually, there are distinct advantages to having a page description
language. The most important one is that it is much easier to accomplish
transformations of the output file (such as what the "psutils" do) when
you can simply augment the code accordingly. To perform equivalent
transformations on PDF output, a tool would have to understand most of,
if not the entire PDF format. In a time where IT talent is one of the
scarcest resources on the planet (compared to demand), being able to do
something quickly and easily is an important factor.

Second, many graphical objects are best described algorithmically.
Postscript gets away with a relatively small set of operators because
high-level graphical constructs can be created based on that without
driving up the file size. PDF instead has to support a large number of
high-level operators.

Third, sometimes output is device dependent (resolution, color
capability), yet you only want one output file. Again, having
programming facilities that can work dependent on the device parameters
is a big benefit.

Gradients, for instance, are almost impossible to do in a compact,
efficient and device-independent fashion without having support for
programmatic features, which is why PDF has to include specific
high-level operators to do them (which, while working for 99% of all
cases, still have some limitations). But essentially, for any new
type of graphical object that you come up with, you either have to
change the definition of PDF or "linearize" it as a series of simpler
objects, whereas with Postscript you'll just add in a new procset.

Finally, repetition of complex objects (such as watermarks) without
increasing the output file size is often best accomplished using
procedures, especially if there are slight variances (such as
incorporation of page numbers or section titles). PDF offers support for
this by means of object references, as long as the graphical objects are
identical in each case.

Note that this isn't meant to imply that either format should be
considered superior--merely that there are advantages to having a page
description language with programming features (and, of course, obvious
disadvantages). Postscript and PDF were created for different purposes,
one more focused on creating arbitrary graphical output, the other
focused on capturing and retaining the abstract content and structure of
the document. Naturally, there is a lot of overlap between both, but in
both cases there are things one does better than the other.

                        Reimer Behrends


reply via email to

[Prev in Thread] Current Thread [Next in Thread]