🚀 go-pugleaf

>delahunt@adobe.com (Jim DeLaHunt) writes:
>
>>In general, write your script in such a way that it the interpreter
>>consumes code as soon as it receives it.  For instance....
>>  % in script
>>  143.2 246.0 l -1.41 -6 r ... (998 more "x y r" sets)

In article <loesch.714382187@hera> loesch@bl.physik.tu-muenchen.de (Andi 
Loesch) writes:
>
>But what happens if the length of the polygon becomes too large? 

We were talking about how to draw big polygons without being limited by
the size of the operand stack.  You are asking about the next obvious
problem, which is about the limit imposed by the PostScript interpreter's
path storage.  The path storage limit depends on the interpreter 
implementation.  For most PostScript Level 1 implementations, this limit
is 1500 vertices.  For PostScript Level 2 implementations, the limit is higher
and more flexible.

The solutions to this problem are unfortunately application-specific.  
If the application knows its polygon doesn't self-intersect and has no holes
in it, it might get away with simply issuing 'fill' operators every 1500
vertices or so.  This will print correctly on most PostScript interpreter
implementations.  If the polygon is more complex, then the application 
must do correspondingly more work to divide it into sub-polygons.

Complex graphics unfortunately can require complex software to manage them.

	--Jim DeLaHunt, Developer Support, Adobe Systems Incorporated	
delahunt@adobe.com	...!{apple,decwrl}!adobe!delahunt      +1-415-962-3790

[For our German-speaking readership:
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ]