Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Clipping Path flatness?

1,592 views
Skip to first unread message

Christopher

unread,
Jan 6, 2000, 3:00:00โ€ฏAM1/6/00
to
How does one determine what number to use for the flatness, when doing a
clipping path?


Christopher

Del Tree

unread,
Jan 6, 2000, 3:00:00โ€ฏAM1/6/00
to
In article <tnphoto-0601...@204.186.122.130>, Christopher
<tnp...@ptd.net> writes

>How does one determine what number to use for the flatness, when doing a
>clipping path?
>
>
>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

Skip Gerwin

unread,
Jan 6, 2000, 3:00:00โ€ฏAM1/6/00
to
If I understand it correctly a flatness of 1 will create a straight line
for each device pixel. If you out put a file to an imagesetter @ 2400 dpi
(2400 device pixels) it will create a straight line for each device pixel,
so we're talking at least 2400 lines for a straight line. A flatness of 3
will create a straight line for every 3 device pixels, 8 pixels for a
flatness of 8 and so on. I've used a flatness of 8 to our rips-imagesetters

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.

Aandi Inston

unread,
Jan 6, 2000, 3:00:00โ€ฏAM1/6/00
to
tnp...@ptd.net (Christopher) wrote:

>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,

Kevin Ward

unread,
Jan 6, 2000, 3:00:00โ€ฏAM1/6/00
to
Christopher <tnp...@ptd.net> wrote:

> 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 !
+------------+-------------------------------------------------------+

Lesta

unread,
Jan 8, 2000, 3:00:00โ€ฏAM1/8/00
to
I have to agree with you on this. This reason I was told was that the RIP or
printer will set the flatness to what it needs without overloading it and
give you the best result he can give you.

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 Blevins

unread,
Jan 9, 2000, 3:00:00โ€ฏAM1/9/00
to
Lesta <Le...@videotron.ca> wrote:

> 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.

John Doherty

unread,
Jan 10, 2000, 3:00:00โ€ฏAM1/10/00
to
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).

--

Neil Gould

unread,
Jan 10, 2000, 3:00:00โ€ฏAM1/10/00
to
Hi all,

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

Christopher

unread,
Jan 10, 2000, 3:00:00โ€ฏAM1/10/00
to
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!

Lee Blevins

unread,
Jan 11, 2000, 3:00:00โ€ฏAM1/11/00
to
Christopher <tnp...@ptd.net> wrote:

Take a look at the Kodak ColorFlow products.

You can get away with and inexpensive input profile builder or go all
the way.

OtakuVidiot

unread,
Jan 11, 2000, 3:00:00โ€ฏAM1/11/00
to
Whilst reliving childhood traumas, OtakuVidiot spied
jdoh...@ix.netcom.com (John Doherty)'s post in comp.publish.prepress:

>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'."

Pierre Grรฉgoire

unread,
Jan 11, 2000, 3:00:00โ€ฏAM1/11/00
to
In article <tnphoto-1001...@204.186.122.130>, tnp...@ptd.net
(Christopher) wrote:

> 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

Louis Dery

unread,
Jan 11, 2000, 3:00:00โ€ฏAM1/11/00
to
In article <tnphoto-1001...@204.186.122.130>, Christopher
<tnp...@ptd.net> wrote:

> 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.

GGDesign

unread,
Jan 23, 2000, 3:00:00โ€ฏAM1/23/00
to
in article jdoherty-100...@aus-tx46-04.ix.netcom.com, John Doherty
at jdoh...@ix.netcom.com wrote on 10/1/00 6:12 am:

> 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."
_________________________________


Jesell Marya

unread,
Oct 6, 2023, 5:07:49โ€ฏAM10/6/23
to
> They did so, and the problem was solved.https://path-clipping.com/

Jesell Marya

unread,
Oct 6, 2023, 5:10:32โ€ฏAM10/6/23
to
๐Ÿ“ฃ ๐๐จ๐จ๐ฌ๐ญ ๐˜๐จ๐ฎ๐ซ ๐’๐š๐ฅ๐ž๐ฌ ๐ฐ๐ข๐ญ๐ก ๐Ž๐ฎ๐ซ ๐„-๐‚๐จ๐ฆ๐ฆ๐ž๐ซ๐œ๐ž ๐๐ก๐จ๐ญ๐จ ๐„๐๐ข๐ญ๐ข๐ง๐  ๐’๐ž๐ซ๐ฏ๐ข๐œ๐ž!
Our expert editors can enhance your product images, remove backgrounds, and more. Try us today!

๐Ÿ”— ๐•๐ข๐ฌ๐ข๐ญ ๐Ž๐ฎ๐ซ ๐–๐ž๐›๐ฌ๐ข๐ญ๐ž - https://path-clipping.com/

โžก๏ธ ๐—ข๐—จ๐—ฅ ๐—ฆ๐—˜๐—ฅ๐—ฉ๐—œ๐—–๐—˜๐—ฆ
โœ” Clipping Path
โœ” E-Commerce Photo Editing
โœ” Background Removal
โœ” Color Change
โœ” Ghost Mannequin
โœ” Photo Retouching
โœ” Drop Shadow Etc.

โŒ› ๐Ÿ ๐ข๐ฆ๐š๐ ๐ž ๐Ÿ๐ซ๐ž๐ž ๐ญ๐ซ๐ข๐š๐ฅ - https://path-clipping.com/trial-now/

๐Ÿ’ฐ ๐—ข๐˜‚๐—ฟ ๐—ฃ๐—ฟ๐—ถ๐—ฐ๐—ถ๐—ป๐—ด
โœ… Clipping Path - $0.49
โœ… Background Removal - $0.45
โœ… Product Photo Edit - $0.79
โœ… Drop Shadow - $0.39
โœ… Color Change - $0.99
โœ… Ghost Mannequin - $0.89
โœ… Image Masking - $1.19
โœ… Photo Retouching - $0.69
โœ… Vector conversion - $3.99

โ„น๏ธ ๐‚๐จ๐ง๐ญ๐š๐œ๐ญ ๐”๐ฌ
๐Ÿ“ฒ WhatsApp: +8801306242973
๐Ÿ“ง Email - unpho...@yahoo.com
0 new messages