Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!bbn.com!cosell
From: cosell@bbn.com (Bernie Cosell)
Newsgroups: comp.lang.postscript
Subject: Re: Multiple flattenpaths
Message-ID: <56899@bbn.BBN.COM>
Date: 4 Jun 90 11:13:43 GMT
References: <56864@bbn.BBN.COM> <2064@artcom0.artcom.north.de>
Sender: news@bbn.com
Distribution: comp,world
Lines: 35

pf@artcom0.artcom.north.de (Peter Funk) writes:

}cosell@bbn.com (Bernie Cosell) writes:

}[...]
}bc>        strokepath
}bc>        flattenpath
}bc>        ...lots of irrelevant stuff
}bc>        flattenpath
}bc> and the second flattenpath fails ...
}bc> ... I'd have thought that doing a second
}bc> flattenpath would be a no-op... is there something obvious I'm missing
}bc> ... 

}How should the interpreter "know", that the path was previously flattened ?
}Indeed the interpreter-writer may have added a boolean flag to the path...
}obviously he has missed that.  So the interpreter tries to create a 
}temporary copy of the path during the second 'flattenpath' and rans out 
}of memory during this attempt.

Hmmm... good point.  I guess, in my naivete, I had assumed that
flattenpath would _replace_ segments in teh current path, segment by
segment, and so if the path were already flattened it'd just go one for
one and so not be any larger.  I guess it hadn't occurred to me that a
flattenpath would, in essence, DOUBLE the number of your
segments-in-use, since it'd copy from the old to a new one.  I wonder
if gsave has the same problem: that that limitcheck is for ALL 'saved'
paths, and not just for the one that is currently active.  Oh well,
doesn't much matter: a carefully placed "stopped" and a little fiddling
with what you do when you DO hit the limitcheck and it got better [and
another chunk of 'bbfig' started working better!  :-)].

  /Bernie\