Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!visix!andrew
From: andrew@visix.com (Andrew Bernard)
Newsgroups: comp.lang.postscript
Subject: Re: clip limitcheck
Message-ID: <1991Apr17.192525.23788@visix.com>
Date: 17 Apr 91 19:25:25 GMT
References: <1991Apr15.182427.16415@morrow.stanford.edu> <11651@exodus.Eng.Sun.COM>
Organization: Visix Software Inc., Reston, VA
Lines: 32

In article <11651@exodus.Eng.Sun.COM> rberlin@Eng.Sun.COM writes:
>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.  ...
>
>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.
>

Since _clip_ doesn't reset the current path, you'll need space for both
the current path AND your clip path in the gstate.  I suspect this is the
problem.  A smarter interpreter might be able to share path segments
between the two paths until the current path is reset, but it seems this
is too much to expect. )-:



-- 
     andrew bernard              ring the doorbell on your mind  
    software engineer            but it's locked from the outside
     visix software                                 -dinosaur jr.
    andrew@visix.com