Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!adobe!greid
From: greid@adobe.com (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: Parametric Function
Message-ID: <520@adobe.UUCP>
Date: 23 Feb 89 18:08:32 GMT
References: <7453@batcomputer.tn.cornell.edu>
Sender: news@adobe.COM
Reply-To: greid@adobe.COM (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 51

In article <7453@batcomputer.tn.cornell.edu> fielding@geology.tn.cornell.edu writes:
>In a recent article decouty@irisa.UUCP (Bertrand Decouty) wrote:
> >What a surprise when printing this file: It seems that the max segments
> >number, on a LW II NT, is less than the 1500 announced in the Red Book
> >for a LaserWriter!
>
>I think that our LaserWriter has a limit of 500. The parametric function 
>worked with the inner loop changed to 499 (and the outer loop changed to 99 
>also). It did not work with 1499. I think that someone here found the limit
>by trial and error.

Yes, there are implementation limits.  But no, they have not changed.
[And 500 is the stack limit, not the limit on path space.]

There can be at most 1500 points in path space.  This requires some
elaboration:

	1.  This includes the clipping path AND any paths that may
	    be retained by gsave/grestore or save/restore.  Using
	    "gsave newpath ... grestore" does not gain you any more
	    path space.

	2.  1500 points, not 1500 path elements.  That is, a "curveto"
	    requires more points than a "moveto".

	3.  If you use "flattenpath" or "charpath" or "strokepath"
	    anywhere, you will get an indeterminate amount of extra
	    points in the current path, depending on the current
	    flatness, the device resolution, the existing path,
	    the characters being "charpath"ed, etc.

I imagine that you'll find a "clip" or a "gsave" somewhere, upon closer
inspection of the code.

There is another implementation limit to the size of the operand stack,
namely 500 elements.  Some path building operations that need to leave
data on the stack (perhaps the 'inner loop' mentioned above) may
overflow the stack limit of 500 long before path space is exhausted.
This can be helped by using "lineto" (or whatever) more often and
consuming the data from the stack.

Note that the stack holds 500 PostScript language 'objects', where an
object may be an integer, an array, a procedure body, a mark, etc.
An array takes no more space on the stack than does a real number or a
boolean.

I hope this helps.

Glenn Reid
Adobe Systems
Developer Tools & Strategies