🚀 go-pugleaf

> 1)  The operand stack will only hold 500 objects, so I am (I think)
> forced to have 100s of K of data broken down into groups of 500.

    True.

> 2)  The virtual memory has only 174 K at most, and thus I must limit
> the amount of data I can print per page to about 13K samples (about a
> second worth of data).

    True, except that you don't really need to use any memory at all.

> Is there any way to get the operand stack to accept a larger number of
> objects, or bypass it altogether (I have not been able to get anything
> else to work)?

    No.

> Is there a way to get the LaserWriter to dump its font dictionarys,
> and thus create more available memory?

    No.

> Are there any other ways you can think of to get around this problem?

    Yes.

What you are currently doing is putting 450 integers on the stack,
allocating an array that can hold 450 numbers (about 3600 bytes),
putting them all into that array, then pulling them out of the array
two by two, putting them back on the operand stack, and calling
"moveto" and "lineto".

The solution is to use them directly from the stack in the first
place and forget the array.  You still have to "do something" every
450 data points or so, but you can go on forever without using any
memory at all, and it isn't very hard:


	%!PS-Adobe-2.0
	%%EndComments
	/chunkdraw { %def
		% assumption: the path can be drawn in either direction.
		% either the points have to be put out in the opposite
		% order, or you need to roll them on the stack.  This
		% program assumes the easiest, but I can supply the
		% other if you need it.
		moveto		% last two numbers on stack
		448 { %repeat
			lineto
		} repeat
		stroke
	} bind def
	%%EndProlog

	450 integers here	% no array
	chunkdraw

	450 integers here	% no array
	chunkdraw

	450 integers here	% no array
	chunkdraw

	% ad infinitum...

	%%Trailer


There are many variations on this theme, but the lesson is that there
is no reason to take anything off the stack, do a "def", then put it
right back onto the stack to use it.  This can be applied to almost
any PostScript programming problem with good success.

A side effect is that it will probably run two or three times faster
than it currently does.

I hope this helps.

Glenn Reid
PostScript Software Support
Adobe Systems Incorporate