At some point in my learning to live (and sometimes love) the business, art and science of personal computing, I
got fascinated in the area of file formats—both text, graphic
and related interchange formats—and their role in quality
output, interapplication compatibility and cross-platform support.
In other words, making what you wanted to use work, even if
things had to move to a different application on a different
operating system. ...My digital orientations and proclivities
Perhaps because of the default exposure granted the JPEG file format by its common use in Web browsers, a disturbingly significant number of people are now delivering graphic files for print as JPEGs. This grieves most seasoned print-industry professionals, as they are receiving so much less than they had grown accustomed to.
Original worked saved as RAW, TIFF or native
PSD (if you're working in Photoshop®, for example) will
store a file with much greater detail. Although most digital
cameras save photos you take in various resolutions of JPEG,
those that provide the option to save as RAW store all the
information captured by the lens. A 3MB RAW file, for example,
would generally save into a JPEG of lesser size, usually 1MB
or less (and each resaved JPEG file would lose a little more
detail with each save, given JPEG's lossy nature). Save that
same RAW file as a TIFF, it actually balloons to about 9MB.
Although such monstrous sizes are an encumbrance of magnitude
for the Web, they are quite desirable in the print world. ...TIFFs like it RAW
A classic example are graphic files I prepare
for my wife's editorial work with agronomic publishing. The
agrons (better known as agronomists) she does freelance editorial
work for will submit graphic files that, 90% of the time,
are less than optimal—either in terms of image quality
(resolution) or by the file form in which they arrive (e.g.,
a poor scan of a data graphic embedded in a Word PC file).
I understand why they can't all be
beautifully executed graphs that result from data worked within
Adobe Illustrator® (that's almost a vertical-market
specialty); but why can't I at least receive the data and
chart within MS Excel?®
In any event, what I'm often
left to deal with is a process that is more involved than
necessary. Sometimes I can get by with copying the embedded
image from Word or even PowerPoint® (you'd
be amazed at how many people submit graphics for print in
an application meant for screen presentation). In worse-case scenarios, I need to employ up to four applications
to convert and improve each submitted file. Were this not
America, some agrons could have landed before a firing squad
for such atrocities. (See below for
details.)
In a none-too-rare instance, as many as four
distinct steps...or should I say, separate applications, must
be summoned to make a graphic file press-ready.
My workflow to produce a decent resolution
image file for import into QuarkXpress® can be as convoluted
as the following: 1) Launch Virtual
PC with Windows 2000® onboard, and open the file in
Word XP; 2) Locate each of the
requisite figures embedded within and, one at a time, print
them to file (yielding a .prn file [which
stands for printer file, not porn file, by the way] that
can be distilled if I output it via a PostScript driver); 3)
Using print or press-level (as needed) output settings,
distill the Postscript-impregnated .prn file in Acrobat®
Distiller to yield what's at least an adequate-resolution .PDF
file; and, finally 4) Open
a rasterized version of the PDF in Photoshop and adjust its
color space and resolution (the latter
via resizing and resampling as needed) until we have
a technically adequate graphic file—and save as a flattened
TIFF.
Fortunately, not all files are this
involved. But none are ever one-step, pass-through simple. If that were routine, or the default...
Most folks in the print-publishing business
appreciate — even rely on—a PostScript-based workflow.
Yet, I know some who do not, and I can only guess that they
don't because 1) they don't understand
why PostScript is so valuable to high-end output, or 2)
they think that because avoiding it costs less up front, it
will cost less in the long run (not necessarily true), or
perhaps 3) they believe that
because complex, magnificently scalable PostScript output
can take longer than a less complex page-description technology
that their workflow will be faster if they avoid PostScipt
altogether.
As some wise sage told me long
ago, "Nothing that is truly worthwhile doing will come
with ease. But once you have so endeavored, you shall be forever
grateful that you rose to the challenge."
Most publishing workflows in today's academic and corporate
worlds involve, to lesser or greater extents, the proverbial
PDF document. With the freely downloadable Acrobat Reader
available in multiple languages for multiples operating systems
throughout the planet, Acrobat and its PDF format may well
be the universal "tongue."
Guess what technology PDF is a subset of, indeed,
has its own specialized interpreter for built within it?
PostScript. That's right: PostScript. ...So what is this marvelous mystery known as PostScript?
