ib@apolling (Ivan N. Bach) (02/21/89)
Here is a PostScript program that draws a very nice parametric function in
landscape orientation. This function was described in the section
"Computer Recreations" of the August 1988 issue of "Scientific American."
It would be faster to calculate all values of the x(t) and y(t) functions
in a different programming language, such as C, and then generate
PostScript code to connect the points at calculated coordinates, but I
wanted to write the whole program in PostScript.
------------------------------ cut here ----------------------------------
%!
% A parametric function based on an article printed in the August 1988
% issue of "Scientific American":
%
% x(t) = 800(sin(.99t)-.7cos(3.01t))+1653 (at 300 dpi)
% y(t) = 800(cos(1.01t)+.1sin(15.03t))+1275 (at 300 dpi)
% t = 0, 1, 2, ..., 50000
%
% The parameter t reaches the value of only 49435 in this program.
% specify the number of copies
userdict begin /#copies 1 def end
% define the x(t) function
/x {
.99 t mul sin 3.01 t mul cos .7 mul sub
800 mul 1653 add 300 div 72 mul
} bind def
% define the y(t) function
/y {
1.01 t mul cos 15.03 t mul sin .1 mul add
800 mul 1275 add 300 div 72 mul
} bind def
% use the thinnest line
0 setlinewidth
% use the landscape orientation
-90 rotate
-11 72 mul 0 translate
/t 0 def
x y moveto
33 {
% do not exceed the maximum number of path segments (1500)
1499 {
x y lineto
t 1 add /t exch def
} repeat
stroke
t 1 sub /t exch def
x y moveto
} repeat
showpagedecouty@irisa.UUCP (Bertrand Decouty) (02/22/89)
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!
What's the point? How can anybody know these implementation limits (they are
not in PPD files from Adobe)?
Thanks for any reply.
PS: Is GETapd.ps, the prog used by Adobe for producing PPD files, Adobe proprie-
tary or freely available? Not all PS-printers have a PPD file at Adobe ps-file-
server, ex: Agfa P400 ps, DEC ps printer...
----- Bertrand DECOUTY @ INRIA-IRISA (Centre de Rennes) -----
+------------------------------+----------------------------------------------+
| IRISA - INRIA | EMAIL : decouty@irisa.fr |
| Campus de Beaulieu | |
| F-35042 Rennes Cedex | UUCP : {uunet,mcvax,inria}!irisa!decouty |
| FRANCE | decouty@irisa.UUCP |
+--------------------------+---+--------------------+-------------------------+
| PHONE : +33 99 36 20 00 | TELEX : 950473 UNIRISA | FAX : +33 99 38 38 32 |
+--------------------------+------------------------+-------------------------+eric@batcomputer.tn.cornell.edu (Eric Fielding) (02/23/89)
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. >What's the point? How can anybody know these implementation limits (they are > ----- Bertrand DECOUTY @ INRIA-IRISA (Centre de Rennes) -----
greid@adobe.com (Glenn Reid) (02/24/89)
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