🚀 go-pugleaf

I (Jim DeLaHunt) wrote, in article <1992Aug21.090522.10455@adobe.com>:
>The solutions to [the 1500-vertex path storage limit in PostScript Level 1
>implementations] are unfortunately application-specific.  

Larry Spence replies, in article <1992Aug25.043733.19389@cs.com>:
>Is there some philosophical reason why PS doesn't decompose polygons that
>are too complex?  In an application, the poor developer is stuck with 
>decomposing curved-edge polygons into simpler pieces, which is slow and
>prone to numeric errors.  

Keep in mind that we were talking about avoiding error conditions, and working
around implementation limits.  

The PostScript interpreter *does* decompose polygons.  This is part of its
normal operation.  In particular, it flattens curves and computes 
insidedness for complex polygons.  

However, this takes memory, and all memory is finite.  Every imple-
mentation will have a limit to its memory and therefore a limit to the 
complexity of a path it can render.  Sometimes the limit is low 
and fixed, sometimes it is high and variable.  PostScript Level 2 imple-
mentations take steps to raise the limit by using available memory more
efficiently.

The question is, does your application emit paths that are likely to hit
the limit? What are the consequences of hitting the limit?  Do those con-
sequences make it worthwhile to change your app to avoid the limit?  Do
they justify having the customer buy a printer with a higher limit?

Let me give three examples of apps that could exceed implementation limits:
  1. An application prints pie charts.  It draws pie slices as hundreds of
     line segments, because its PostScript language driver was cloned from
     a plotter driver, and they didn't want to rewrite that part.  [I'm
     not entirely making this up.]  The problem is that the driver is
     using at the PostScript language at a ridiculously low level.
     The solution is to rewrite the driver draw pie slices with Beziers.

  2. An application emits a recursive PostScript language program that 
     draws a fractal path, down to the limits of device resolution, and 
     executes a single 'fill' operation.  The problem is that the app
     is elegant but ignores the realities of the implementation -- a limit
     to path storage, but a frame buffer (more accurately, an opaque imaging
     model) just waiting to be used.  A possible fix is to rewrite the 
     algorithm to exploit the opaque imaging model, by iterating along the
     fractal, drawing a portion of the path, filling it, and going on
     to the next.  

  3. An application emits complex (concave, self-intersecting) paths about
     which it knows little (e.g. a user drew them).  The user is willing
     to upgrade hir printer.  Here the problem is fundamental -- the paths
     can be as complex as the user's whims, and it takes a lot of work for
     the application to determine that.  Here the solution may be to tell 
     the users about the implementation limits, and explain that they can 
     either restrain themselves, or raise the limits by buying a PostScript
     Level 2 printer with lots of memory.     

The PostScript imaging model provides both limits and opportunities.  Be 
intelligent about how you skirt the limits, and exploit the opportunities.

>Larry Spence
>larry@cs.com
>uunet!csccat!larry or sun!texsun!csccat!larry

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