cosell@bbn.com (Bernie Cosell) (06/01/90)
I'm going a bit nuts here trying to get 'bbfig' really debugged and
working, and the current anomaly is driving me nuts. Simply put: is it
possible to get a limitcheck on an already flattened 'flattenpath'?
I'm chasing a problem where the apparent flow of things is:
strokepath
flattenpath
...lots of irrelevant stuff
flattenpath
and the second flattenpath fails [I don't actually know why, because it
is in a 'stopped' protected region [in both cases, it turns out], and
what I know is that the stopped is failing, and limitcheck is the only
listed error for flattenpath. I'd have thought that doing a second
flattenpath would be a no-op... is there something obvious I'm missing
or might this be some kind of obscure bug (horrors!) in the PS
interpreter I'm using [UltraScript on an Imagen printer].
Thanks...
/Bernie\
ps, this is kind of irrelevant to this posting, but.... if you cared
about the 'tracing' package I posted yesterday, I've upgraded it some
and so give me a shout if you'd like the improved version. The
improvement is that the tracedump stuff now 'showpage's on its own, so
you can see all of your cached stuff, instead of having it go off the
bottom of the page after 60-odd lines. Stuff added in desperation in
trying to puzzle out a MacDraw mess that spawned eight pages of tracing
diagnostic info.... /b\pf@artcom0.artcom.north.de (Peter Funk) (06/02/90)
cosell@bbn.com (Bernie Cosell) writes: [...] bc> strokepath bc> flattenpath bc> ...lots of irrelevant stuff bc> flattenpath bc> and the second flattenpath fails [I don't actually know why, because it bc> is in a 'stopped' protected region [in both cases, it turns out], and bc> what I know is that the stopped is failing, and limitcheck is the only bc> listed error for flattenpath. I'd have thought that doing a second bc> flattenpath would be a no-op... is there something obvious I'm missing bc> or might this be some kind of obscure bug (horrors!) in the PS bc> interpreter I'm using [UltraScript on an Imagen printer]. [....] 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. May be: I should better add such a boolean "already-flat"-flag to OUR ps-clone... ? ;-) Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1 Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm) >> PLEASE Don't send BIG mails (oversea) ! I've to pay for it : $0.3/kB Don't use the bang path of this news article for mails (They will bounce). Only the address 'pf@artcom0.artcom.north.de' will work. Thank You ! <<
cosell@bbn.com (Bernie Cosell) (06/04/90)
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\
pf@artcom0.artcom.north.de (Peter Funk) (06/05/90)
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> ... I replied : pf> How should the interpreter "know", that the path was previously flattened ? pf> .... So the interpreter tries to create a pf> temporary copy of the path during the second 'flattenpath' and rans out pf> of memory during this attempt. bc> Hmmm... good point. I guess, in my naivete, I had assumed that bc> flattenpath would _replace_ segments in teh current path, segment by bc> segment, and so if the path were already flattened it'd just go one for bc> one and so not be any larger. I guess it hadn't occurred to me that a bc> flattenpath would, in essence, DOUBLE the number of your bc> segments-in-use, since it'd copy from the old to a new one. THIS leads to a very interesting question : Which internal representation should one use for paths when implementing a "100 % adobe compatible" PostScript-interpreter ? If one uses a linear linked list, a implemantation of flattenpath, that will behave as bernie guessed first is trivial. Unfortunately we --and I guess "Imagen UltraScript" also ;-) -- have chosen another approach : We representant a path as a vector (array) of attributed points, where a not yet flattened bezier curve will occupy 4 consecutive points, a straight line segment 2... So we have to copy the path during the flattenpath operation. I wonder, which approach adobe has implemented. Is there someone out there, who is willing to test bernies code causing the limitcheck error on an original adobe ps-machine ? May be that the result will be of some interest to (for ?) other ps-clone developers also... ;-) -- Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1 Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm) >> PLEASE Don't send BIG mails (oversea) ! I've to pay for it : $0.3/kB Don't use the bang path of this news article for mails (They will bounce). Only the address 'pf@artcom0.artcom.north.de' will work. Thank You ! <<
cosell@bbn.com (Bernie Cosell) (06/06/90)
pf@artcom0.artcom.north.de (Peter Funk) writes: }THIS leads to a very interesting question : Which internal representation }should one use for paths when implementing a "100 % adobe compatible" }PostScript-interpreter ? If one uses a linear linked list, a implemantation }of flattenpath, that will behave as bernie guessed first is trivial. } Unfortunately we --and I guess "Imagen UltraScript" also ;-) -- have }chosen another approach : We representant a path as a vector (array) of }attributed points, where a not yet flattened bezier curve will occupy }4 consecutive points, a straight line segment 2... So we have to copy }the path during the flattenpath operation. } I wonder, which approach adobe has implemented. Is there someone out }there, who is willing to test bernies code causing the limitcheck error }on an original adobe ps-machine ? May be that the result will be of }some interest to (for ?) other ps-clone developers also... ;-) I would gladly post my 'test code', except that it wouldn't do at all: it was a badly hacked version of the Apple LaserPrep loaded together with TWO partially broken debugging packages. On the other hand, I can give you a slight data point: an Apple LaserWriter does NOT have this problem. My package with the multiple flattenpaths worked _just_fine_ on the LaserWriter, and only failed when I started running on the big Imagen in the computer room. /Bernie\