craig@pangea.Stanford.EDU (Craig Jarchow) (04/16/91)
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.
rberlin@birdlandEng.Sun.COM (Rich Berlin) (04/17/91)
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
andrew@visix.com (Andrew Bernard) (04/18/91)
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