TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
John Cornellier has <<... a print job to do locally. I'm meeting the printer
to agree on the job parameters, and I want to get it right the first time.
Have I missed anything from the following checklist?
* File format? PS on CD? Are there different types of PS?>>
We've had good luck simply using native PageMaker files, with the files
prepared using the "Prepare for service provider" plug-in. I'd stay away
from sending them PostScript (PS) files simply because these are far more
difficult to troubleshoot and correct; if an error arises anywhere in the PS
file, the job may not print at all or (rarely) may print inaccurately from
that point onwards, and you'll have to resend the entire file. With the
source files, often they can fix the problem page for minimal cost.
The other nice thing about using the plug-in is that it will also include
both the fonts and your kerning tables, which can make a world of difference
if your fonts don't precisely match those installed on the typesetter
(usually the problem arises from different font metrics) or if you've been
playing with the type. Read the Adobe prepress book that comes with
PageMaker for a variety of other helpful hints. One last thing" make sure
that in the Document setup dialog box, you've selected a compatible (usually
Postscript) printer in the field labeled "Compose to printer". For some
reason, the default is "compose to screen", and we've been burned when we
forgot to change this because PageMaker lays out the document using the PPD
(printer description) you've selected in this field.
<<are there any snags, e.g. with TT fonts or non-US characters?>>
The biggest two are to make sure you send them _your_ fonts, and make them
guarantee in writing that they won't run your Windows file by opening it and
converting it on a Mac. That works about as well as you'd expect: 99% or
better success, but that still means lots of errors in a long document. Font
substitutions are particularly problematic, and small differences between
the PC and Mac versions of software can create all kinds of subtle (or
blatant) problems. I've been burned that way once or twice when a printer or
service bureau ignored (or forgot) my requirements.
Speaking of fonts, switch to PostScript fonts if it's not to late for this.
Modern TT fonts work quite well on current PostScript typesetters, but there
are no guarantees (as there are with standard PS fonts). I've read about
occasional problems with TT fonts, but can't confirm whether these problems
resulted from crossing platforms (PC to Mac), using poorly designed type, or
outdated printer drivers. Me, I'm the conservative type, so I go for PS
fonts wherever I can. Foreign characters should be no problem if you can
print them successfully on your PS printer; if you're printing on a TT
printer, you'll still probably get pretty good output, but you can't
consider your laser prints to provide any proof that you'll get an identical
printout on a PostScript printer. Rule of thumb: If you're outputting to a
typesetter, proof your work first on a PS printer.
Oh yeah... and graphics prepared for TT printers won't necessarily output
identically on PS printers, so if you know you're going to typeset output,
use PS or TIFF files to begin with; stay away from propietary Windows
formats such as WMF and bmp. Again, they're likely to work just fine, but
you're more likely to have problems than if you use graphics compatible with
<<* What page formats, weight, and finish available?>>
Don't forget to spec the cover stock; go for "coated 2 sides" if you can
afford it so that you don't end up with one of those annoying curly covers.
Once you've picked a paper, ask what effects this will have on your graphics
(i.e., dot gain) and choice of inks (if you're printing in color). Dot gain,
screen frequencies, and all those delightful issues now rear their ugly
<<Dummy run possible?>>
Dummy runs (aka "press proofs") are bloody expensive. Don't go there if you
can avoid it. Instead, insist on good proofs. Bluelines should be fine for
most jobs, but if you're printing two colors, make sure you've got two sets
of blues: one of the composites (both colors on the same blueprint) and one
with the colors alone on its own blueprint. (This ensures that all the
components that should print in color will actually print in color.) Provide
a color ID number (usually from the Pantone PMS system, but sometimes Toyo)
for any spot colors you'll use. If you're doing full-color work, insist on
color-key proofs, or matchprints of some sort if you really need true color
fidelity. (If you're only doing a two-color job, you can take a risk and
provide your own color inkjet prints showing the separations, then rely on
the printer to confirm that the separation was done properly. That works
well, but odds are, the printer will miss one or two.)
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer