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.
Subject:Re: Graphics Resolution Confusion Once Again From:David Neeley <dbneeley -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Wed, 09 Feb 2011 09:46:10 +0200
The best resolutions for master files that are destined for offset
printing depends upon the resolution of the offset job.
A digital file is ripped by a digital imagesetter, giving an output
image of the target lpi (offset resolution is in "lines per inch" dating
from the old days of silk screens being applied).
Generally, the rip engines work best if the master images are at a
resolution that is an even multiple of the output resolution desired.
That way, it is a straight mathematical transform and nothing needs to
be interpolated in the software.
Thus, if your offset job will be at 150 lpi, you can get reasonably good
results from even multiples (300, 450, 600 for example).
It is usually best to use at least double the output resolution.
Occasionally, you will find jobs run at other resolutions entirely--at
one point, 133 lpi was a fairly popular choice. Thus, any images for
that output res would again be even mulitples of that. (When I say "even
multiples," I am also referring to numbers like 1.5, 2.5, etc.)
Some offset work is higher resolution than the 150 I mentioned
first--although that would likely be fairly rare in documentation
printing. Images printed at higher resolutions can be fairly tricky to
run at times, especially if the press being used requires multiple
passes to lay down all the colors for the job. For example, you may have
a four-color press printing a four color job--but printing both sides at
once. Thus, the first pass would print two colors on each side. The
moisture from the ink can cause the paper to swell slightly, making the
second pass through the press be off registration slightly. This is
especially true with uncoated stock--again, typical for manual
printing--and most especially when printing at high resolution since the
dots are so much smaller.
Nothing substitutes for having a serious chat with the offset company to
get the best advice as to how to get the cleanest master with your
combination of output desires.
These days, it is common for at least some clients to supply a file in
.pdf format. That is fine if you know what you're doing--but I always
preferred to work with a printer who could deal with the original file
where possible, so that any necessary adjustments could be made in the
pre-press phase. Of course, today many tools exist which can make
manipulating the acrobat files themselves relatively trivial in terms of
issues such as signature creep and the like. However, it remains very
good practice if you can produce output files with colors already
separated and crop and registration marks in the file--although this may
be well beyond the comfort zone or software capability in many cases.
Obviously, if you are not offset printing in color, things are much
simpler.
David
>
> From:
> Gene Kim-Eng <techwr -at- genek -dot- com>
> Date:
> Tue, 8 Feb 2011 19:27:00 -0800
>
>
> If you're taking your work to offset printing, anything less than
> 300dpi is going to look dodgy. I prefer at least 600dpi for my offset
> projects.
>
> Gene Kim-Eng
>
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-