Christopher
The complexity or otherwise of the drawn path. The higher the flatness
number the fewer number of straight lines used to draw curves. The
usable range is 0.2 to 100.
My recommendation would be:
Maximum value: 10
average path and/or default setting: 1
very complex path, many subtle curves: 0.3
FWIW we invariably use settings of 0.5 to 1.0 across the board with no
output problems. If you suspect a path or path group is overly
complicated (i.e you are seeing postscript "Limitcheck" errors)
increasing the flatness value can help. But anything above 12 will give
you rather straight curves!
I hope that helps.
--
Del Tree
for years with no problem. As rips have gotten faster and better able to
handle complex files we've lowered the flatness we use to 3. We also output
to inkjets (300 dpi) and laser printers (600 dpi) now so the lower flatness
settings are better suited for the device that print at a lower resolution.
>How does one determine what number to use for the flatness, when doing a
>clipping path?
It's virtually impossible for you to calculate the minimum required
value even by analysis of the curves making up the path. There is no
one value to suit all situations.
Basically, use a bigger value if you need to. If you have a complex
path and a small flatness your RIP can run out of memory. The usual
error is "limitcheck".
----------------------------------------
Aandi Inston qu...@dial.pipex.com
Visit http://www.quite.com/ps/errors.htm to find out
all about PostScript errors, and how to fix them,
> How does one determine what number to use for the flatness, when doing a
> clipping path?
We just leave it blank - but I can't recall why we do it!
We use Scitex Brisque RIPs.
--
+------------+-------------------------------------------------------+
! Kevin Ward ! If nobody else was violent, I could conquer the whole !
! ! stupid planet with just a butter knife - Dogbert !
+------------+-------------------------------------------------------+
Lee, I have to disagree with you on the .5 and 1.0 values for imagesetters
and platemakers. This flatness is overkill. Your RIP will take longer to rip
the jobs and you're asking for trouble with limitcheck errors. The more
concervative value that Skip Gerwin suggested are more efficient IMHO.
Lesta
> Lee, I have to disagree with you on the .5 and 1.0 values for imagesetters
> and platemakers. This flatness is overkill. Your RIP will take longer to rip
> the jobs and you're asking for trouble with limitcheck errors. The more
> concervative value that Skip Gerwin suggested are more efficient IMHO.
Get a better rip. Our rips show no real difference. It would take longer
to open EPS files with clipping paths and reset the value than the
increase (if any) in ripping time.
The last time I saw a limit check error was printing to a Lino 330 with
a rip 40 years ago.
We never see them.
| The last time I saw a limit check error was printing to a Lino 330 with
| a rip 40 years ago.
There were no Lino 330s 40 years ago. Or did you mean a RIP40 <some>
years ago? :-)
In my experience, limitchecks still arise in two fairly frequent
circumstances: illustrations (usually maps) that have very long paths,
and images with clipping paths.
In the case of maps, adjusting the path flatness in the application
that saves the illustration can definitely help. In the case of
clipping paths, it's usually better to remake the clipping path with
a greater pixel tolerance (so that it has fewer segments, eliminating
most limitcheck errors and any need to worry about flatness: most
clipped images that generate limitchecks are clipped way too precisely,
and a simpler clipping path does not make any visible difference, but
does greatly reduce the chance of limitchecks).
--
PMJI,
John Doherty <jdoh...@ix.netcom.com> wrote in message
news:jdoherty-100...@aus-tx46-04.ix.netcom.com...
>
> In my experience, limitchecks still arise in two fairly frequent
> circumstances: illustrations (usually maps) that have very long paths,
> and images with clipping paths.
>
I completely agree with you, John... the whole issue is how to deal with
the complexity of the image. In the case of maps, it is quite easy to
have a very large number of complex paths, and this could overrun the
available memory in an Imagesetter.
The artist needs to become familiar with the issues related to paths,
and the tools used to control their complexity. But, IMHO, it goes
beyond the simple plug-in and push-button mentality. Knowing when to
split long paths or reduce the number of points is something that takes
manual involvement. Understanding Bezier drawing can go a long way to
making better clipping paths and original art. In the end, I think the
problems with vector art are similar in nature to those of layout and
typography -- it's really a problem created by the user/artist's skill
level, and not the tools or output devices.
Regards,
Neil Gould
----------------------------------------------------------------
Terra Tu AV http://www.terratu.com
Technical Graphics & Media
Please send help,
Fearing the worst!
Take a look at the Kodak ColorFlow products.
You can get away with and inexpensive input profile builder or go all
the way.
>There were no Lino 330s 40 years ago. Or did you mean a RIP40 <some>
>years ago? :-)
>
>In my experience, limitchecks still arise in two fairly frequent
>circumstances: illustrations (usually maps) that have very long paths,
>and images with clipping paths.
Yep! Limitchecks are still around. (Although sometimes you'll see the
error listed as "clip" or "clipping.") Still, it's not like it used to be
with limitchecks three times a day.
The flatness question is interesting. I've been able to get along with
Photoshop's default for flatness -- which is '1', I suppose. But sometimes
I do have to up it. It's a rare occasion, but it does happen.
--
O_v - OtakuVidiot
Heir to the Bloody Stump of Profundity
Aspiring Moonie / Dreamcast Lover
"So, then Pikachu says, 'you can't _re-use_
prophylactics, ya dope'."
> Where is the best place to start with our color problems? We have
> customers that have problem scan and need good color. We need to
> set up workstations for sheet fed and web 4 color. We are using UMAX
> flatbed, Polaroid neg/slide scanners. We're looking at purchasing
> Colorblind software? But i'm no expert and and the others in our work
> group know even less.
>
> Please send help,
>
> Fearing the worst!
__________________________
Color Manager are fine for color printer output.
You can match proflies for scanner, monitor and printer.
But if you are taking about offset printing (shettfed or web) you need
more specific data.
Dependig on what ink and paper combination you are using and the press dot gain
you will have to build a specific profile.
This involve the use of a densitometer and spectrophotometer and you must
ask your printer
to give you sheet that were done on his press for you to analyse.
It's a long process and the learning curve is high.
But that's what standardized procedures are.
Pierre
> Where is the best place to start with our color problems? We have
> customers that have problem scan and need good color. We need to
> set up workstations for sheet fed and web 4 color. We are using UMAX
> flatbed, Polaroid neg/slide scanners. We're looking at purchasing
> Colorblind software? But i'm no expert and and the others in our work
> group know even less.
>
> Please send help,
>
> Fearing the worst!
For any question you have about ColorBlind softwares, feel free to ask!
I've been installing and MAKE CMS WORK since five years for clients
like digital photographers, prepress (scan, proof) and as for printing
shop (offset, web, screen print and flexo). We offer training so that
the learning curve is short. Typically, we go on site, install and give
the training in five days for a complete cms system.
For those who says that color management still don't work, its is
simply beacuse of a lack of knowledge about how to set it up. Onec you
konw how, everything goes well!
visit our web site at http://www.tglc.com
Again, feel free to ask all the question you want!
Louis.
> In article <1e44sp3.v5...@dyn067f.egr-ri.ids.net>, le...@ids.net
> (Lee Blevins) wrote:
>
> | The last time I saw a limit check error was printing to a Lino 330 with
> | a rip 40 years ago.
>
> There were no Lino 330s 40 years ago. Or did you mean a RIP40 <some>
> years ago? :-)
>
> In my experience, limitchecks still arise in two fairly frequent
> circumstances: illustrations (usually maps) that have very long paths,
> and images with clipping paths.
>
> In the case of maps, adjusting the path flatness in the application
> that saves the illustration can definitely help. In the case of
> clipping paths, it's usually better to remake the clipping path with
> a greater pixel tolerance (so that it has fewer segments, eliminating
> most limitcheck errors and any need to worry about flatness: most
> clipped images that generate limitchecks are clipped way too precisely,
> and a simpler clipping path does not make any visible difference, but
> does greatly reduce the chance of limitchecks).
>
> --
I have experienced this on several occasions when running PC QXP files via a
Mac server to the RIP. The main problem occured with the EPS files that were
included with the job. The problem appeared to be that the EPS files were
made from .WMF files (an old PC native vector format), and the transition of
code to encapsulated meant that several paths had numerous extra nodes added
that caused the limitcheck problems (from what we could gather). We ended up
asking the client to get someone on PC to convert their .WMF's properly.
They did so, and the problem was solved.
This may not be your case but the above info may help you in some way (I
hope).
Steve
GGDesign
33 Beambridge Place
Chalvedon
Essex
SS13 3LN
T | 44 1268 583568
F | 44 1268 558991
E | in...@ggdesign.co.uk
W | http://www.ggdesign.co.uk
_________________________________
"Great design speaks for itself."
_________________________________