|
|
The "QUESTION" and "ANSWER" information below was
written in 2002, and the evolution of PPML has taken some twists and
turns since then.
PPML was supposed to be a standard file format. However, what has actually happened
is that there are several different "flavors" of PPML. Market forces are
responsible for this. That is: for business reasons, some manufacturers of printers and
RIPs have found that it is advantageous for them to support their own, proprietary
versions of the PPML specification.
For example, some variable-data-printing solutions are capable of
generating two different kinds of PPML output:
- PPML that is geared for software and equipment made by EFI
- PPML that is geared for software and equipment made by HP (Hewlett-Packard)
What does this mean to you, the user or potential user of software
and printers/RIPs that support PPML?
It means that if you're planning to purchase software and/or a printer/RIP to do variable-data
printing, and if you're planning to rely on PPML output, you should definitely take
it upon yourself to make sure that the software and the printer/RIP work together properly
before you make the investment. Reputable software vendors and printer/RIP vendors
will offer you an opportunity to do such testing free of charge before you
commit to a purchase.
When performing your tests, try to think of the most complicated kinds of documents
that you're likely to produce, and focus on documents like those.
REMEMBER: Just because the literature for a particular software solution claims
support for PPML, it doesn't mean that the PPML code generated by that software
solution will work properly with all printers & RIPs that claim to support PPML
— and vice versa.
QUESTION: What is PPML?
ANSWER: PPML stands for Personalized Print Markup Language.
Here is a basic definition:
PPML is an XML-based language
for variable-data printing.
Below, we'll flesh out this definition as we talk
more about exactly what PPML is and what it does. But first,
let's talk about where PPML came from, and why.
Who Developed PPML?
PPML was developed by The
Digital Printing Initiative (PODi).
PODi, formerly known as the Print On Demand Initiative, is
a not-for-profit multi-vendor initiative that's working to develop
the market for digital printing.
Quite a few high-profile companies belong to PODi. Here
is a list of some of them:
- Adobe Systems Incorporated
- Barco
- Canon
- CreoScitex
- Electronics for Imaging (EFI)
- Epson
- Hewlett-Packard
- IBM
- Indigo
- Lexmark
- NexPress
- Nimblefish
- Noosh
- Oce
- Pageflex
- Xeikon
- Xerox.
Why Did PODi Think There Was a Need for PPML?
To understand why PODi thought that PPML was needed,
you first need to understand that variable-data
print jobs are likely to print more slowly than
non-variable-data print jobs.
Depending on the types of documents
you are printing, this
can be a mild problem, a moderate problem,
or a very severe problem. In some
situations, variable-data print jobs
print so slowly that it might not even be profitable
for a printing company to take on such jobs.
This degradation in print speed is
one of the major challenges faced by
printing companies that want to participate
in the variable-data-printing marketplace.
While they were developing the PPML specification,
the PODi members devoted much attention
to this issue.
Why Do Variable-Data Jobs Print Slowly?
As we've said, a variable-data print job will
probably take longer to print than a similar,
non-variable-data print
job. This happens because - with the variable-data-print
job - the
code for each and every text element and the code
for each and every
graphic element on each and every page must be sent to
the printer/RIP
each time that a customized version of that
page is printed, and the printer/RIP must
rasterize all of this code each time it is sent.
("Rasterization"
is the process of converting code that describes
text and graphics into the format that is
required by the "print engine," which
is the machinery that actually puts the marks
on the page.)
This is not the case
with non-variable-data print jobs. With a
non-variable-data print job, the code for the text elements
and graphic elements on each page must be sent to the
printer/RIP and rasterized by the printer/RIP only once;
then the printer can
print as many copies as required.
A simple example will illustrate this concept.
Let's say that you run an
automobile dealership, and you are going to
print 300 copies of a single-page marketing
brochure that will be mailed to potential
customers whose names and addresses are
contained in a mailing list. The brochure
has a picture of the latest model of your
manufacturer's SUV; and it also has some
text that gives the name, street address,
phone number, Web-site address, and
business hours for your
dealership.
If you are truly printing "copies"
(i.e., if all the brochures are identical),
the code that describes the brochure's text and
graphic elements will be sent to your
printer/RIP by your computer only once.
The printer/RIP will rasterize this code, and
then it will print the 300
brochures. The computer doesn't need to
download the code for the text and graphics 300 times,
and the printer/RIP doesn't need to rasterize the code
300 times. Instead, the computer
downloads the information once, and the printer/RIP
rasterizes it
once and keeps the raster image
(the result of the rasterization process)
in memory until
the 300 pages have been printed.
Now let's say that you decide to customize
the brochures in some way. For example,
you might decide to
tailor the picture of the car on the brochure
to the anticipated preferences of the person
to whom it will be mailed.
You decide that a person's age might be a
good indicator of the type of car that
he or she might be interested in. Fortunately
for you, your mailing list contains each
person's birth date as well as the person's
name and address. So you decide to put a
photo of an economy
car on the brochure that will be mailed
to people under the age of 25 (these folks
are probably in college or are just starting
out in their careers), you decide to put
a photo of an SUV on the brochures that you
will mail to people between the ages of
25 and 50 (many of these individuals probably
have children and are likely to
want a large, rugged vehicle), and you decide
to put a photo of a luxury sedan on the
brochures to be mailed to people over the age
of 50 (these people are likely to be more
affluent and are likely to place a higher
value on comfort than the other two age groups).
Now - unless you are utilizing special variable-data-printing
technology - when it's time to print the 300
customized brochures, your computer will need to download the code for
300 pages of text and graphics to your
printer/RIP instead of downloading the code for
just one page, and the printer/RIP will need
to rasterize 300 pages of code instead of
rasterizing one page of code. Why? Because
printers/RIPs are generally "page-oriented."
In other words, a page is the smallest printed element
that a printer/RIP deals with. Because of this, if
you are printing multiple pages that are not 100%
identical, your printer/RIP
needs to get the entire description of each
page to be printed.
It's a Problem of Redundancy Problem!
If you think about the situation described above,
it becomes obvious that what's needed is some way
to eliminate redundancy. In this example, only
three different photos are being used (the economy car, the SUV, and the
luxury sedan). Nevertheless, your computer
has to download code for 300 photos,
and your printer/RIP has to process all of
this code.
Furthermore,
your computer has to download the code for the text on the
brochure 300 times, and your printer/RIP has
to process this code 300 times - even though exactly the
same text is being used on all of the brochures.
So now you can understand why print speed
is a major challenge when dealing with
variable-data printing.
Print Optimization
Various hardware and software vendors have
developed proprietary technologies to
address the problem described above and
thus make
variable-data print jobs print faster.
These technologies are sometimes
known as "print-optimization technologies."
Some of the print-optimization technologies
in use currently are:
- Diamond Merge from ColorAge
- Fiery Free Form and Fiery Free Form 2 from EFI
- Optimized PostScript from Atlas Software
- VariScript from Varis
- VIPP from Xerox
- VPS from CreoScitex.
PODi Decides That a Common Technology is Needed
Sometime around 1998, several of the major PODi
member organizations came to understand that the
market potential of
digital-printing
technology had not been realized — even though it
has been possible to print high-quality,
full-color, personalized
documents since the advent of digital printing in 1993.
One reason that the digital-printing market
had not been exploited fully
was the lack of a standardized methodology
for printing color pages with high-quality,
reusable content.
(Color pages with high-quality, reusable content, such
as photos, pose a special challenge for
variable-data-printing projects. That's because
large amounts of data are required to represent
these color elements, and — as you've seen -
the need to transfer data to the printer/RIP multiple times
slows down the printing process.)
Although the print-optimization technologies
listed above had gone a
long way toward meeting the challenge of making
variable-data jobs print faster by reducing
redundancy,
the lack of a common technology made
it difficult for interested developers of
variable-data-printing applications and devices
to anticipate a broad market.
The PODi member organizations knew that
the absence of a common print-optimization
methodology also made it confusing and
risky for printing companies to venture into
the variable-data-printing marketplace.
To address this problem, several major
PODi member organizations voted in 1999 to develop
a new print language for
personalized printing. PPML is the language that
came out
of this development effort.
How Does PPML Work?
PPML makes variable-data jobs print faster by
allowing a printer to store text elements
and graphic elements and re-use them as needed. This
eliminates the need to send the same code to
the printer/RIP multiple times during the same
print job.
PPML accomplishes this in two ways:
- By allowing printers to understand and manipulate
the components (objects) that make up a page.
This concept is referred to as "object-level
granularity."
- By allowing application developers to write code
that attaches names to objects and
re-uses the objects as needed during the
process of printing a variable-data job.
Remember, we said earlier that printers generally
don't understand anything smaller than a page.
This change from "page-level granularity"
to "object-level granularity"
is a major step forward.
PPML Workflow
In a PPML workflow, there is a PPML Producer
and a PPML Consumer.
A PPML Producer is anything that produces PPML code.
Typically,
a PPML Producer is an application or a driver.
A PPML Consumer is a device, process, or system
that reads and interprets PPML code. Typically,
a PPML Consumer is a printer, RIP or Digital Front End (DFE).
How Should I Go About Setting Up a PPML-based Variable-Data-Printing System?
If you are thinking about using PPML technology
in your workflow, your best bet is to go with
a PPML Producer and PPML Consumer that were
designed to work together or were at least
tested together.
Why?
All PPML Producer
implementations are not identical, nor are all
PPML Consumer implementations identical. In some
cases, the differences can be attributed to the
fact that PPML technology is not yet mature.
In other cases, there are differences among
PPML systems from various vendors because
some vendors have chosen not to support
certain parts of the PPML specification. For
example, some PPML Producers and PPML Consumers
support imposition
while others do not.
Bottom line (we've said this once, but we'll
say it again because it bears repeating): to
minimize compatibility problems when creating
a PPML-based variable-data-printing system, invest
in system components that were designed to
work together or at least were tested together.
|
|
|
