Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!birdland!rberlin
From: rberlin@birdlandEng.Sun.COM (Rich Berlin)
Newsgroups: comp.lang.postscript
Subject: Re: clip limitcheck
Message-ID: <11651@exodus.Eng.Sun.COM>
Date: 16 Apr 91 20:14:42 GMT
References: <1991Apr15.182427.16415@morrow.stanford.edu>
Sender: news@exodus.Eng.Sun.COM
Reply-To: rberlin@Eng.Sun.COM
Organization: Sun Microsystems
Lines: 29

In article <1991Apr15.182427.16415@morrow.stanford.edu>, craig@pangea.Stanford.EDU (Craig Jarchow) writes:
|> Netters:
|> 
|> I am running into an earlier than expected limitcheck error when using the
|> 'clip' operator. I am creating a path using initclip, moveto, multiple
|> linetos, and closepath. If the path has between 600 and 700 segments, clip
|> produces a limitcheck error on our laserwriter.  I was expecting a limitcheck
|> error somewhere closer to 1500 path segments, as is suggested in the red
|> book.
|> 
|> What is going on with 'clip' that produces this 'premature' limitcheck?
|> I am not using any curved path segments, so it seems that path flattening
|> shouldn't be a factor. Is this problem dependent on device resolution??
|> 
|> Any wisdom would be appreciated.
|> 
|> Thanks,
|> Craig.

The limit, according to the first edition redbook, is

PATH	1500	maximum number of points specified in _all_ active
		path descriptions, including the current path, clip
		path, and paths saved by SAVE and GSAVE.

Probably you've got save or gsave objects that are eating up some
of your path space.

-- Rich