jwz@spice.cs.cmu.edu (Jamie Zawinski) (02/10/89)
I've written a document production system that generates PostScript. The PostScript that it produces is of the form <x> <y> (<text>) word where "word" is a procedure that moves to XY and drops the string in the current font. (Actually, it's more sophisticated than that, but you get the general idea.) Now, for large documents, I get the error "dictfull, flushing job", and I have no idea what dictionary is filling up. Even when a document contains a large number of font changes, I am calling findfont/makefont/scalefont as few times as possible - when I switch to a font for the first time, I stuff the scaled font object into a variable, and when I want to switch to it again, I use the object that I saved. (This was not always the case - I used to call findfont each time, but started caching in an attempt to fix the dictfull error). The function that drops words down on the page sets variables. So the only thing I can think of is that executing "/foo 0 def" over and over again makes the dictionary grow - but that doesn't make a whole lot of sense. Has anyone encountered anything like this? Does anyone have any suggestions as to how I can debug it? Like, how can I tell exactly *which* dictionary is filling up? Maybe then I could write code to print the contents of the dictionary and see what's in it... Jamie Zawinski jwz@spice.cs.cmu.edu sun!sunpitt!eti!jwz --
engelson@cs.yale.edu (Sean Engelson) (02/10/89)
In article <4242@pt.cs.cmu.edu>, jwz@spice (Jamie Zawinski) writes: >I've written a document production system that generates PostScript. ... >Now, for large documents, I get the error "dictfull, flushing job", and I >have no idea what dictionary is filling up. ... >The function that drops words down on the page sets variables. So the only >thing I can think of is that executing "/foo 0 def" over and over again >makes the dictionary grow - but that doesn't make a whole lot of sense. It is your "/fu 0 def"s that are filling up the dictionary. You see, def creates a new binding, rather than setting a variable. What you should do is create one binding somewhere, and use "/fu 0 store" instead. If you want local bindings, do something like: /fuproc { 10 dict begin /fu 0 def /bar (Quux) def ... end } def Which will create a temporary dictionary to hold local bindings. -Sean- ---------------------------------------------------------------------- Sean Philip Engelson, Gradual Student Who is he that desires life, Yale Department of Computer Science Wishing many happy days? Box 2158 Yale Station Curb your tongue from evil, New Haven, CT 06520 And your lips from speaking (203) 432-1239 falsehood. ---------------------------------------------------------------------- I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. -- Albert Einstein
greid@adobe.com (Glenn Reid) (02/11/89)
In article <50250@yale-celray.yale.UUCP> engelson@cs.yale.edu (Sean Engelson) writes: >It is your "/fu 0 def"s that are filling up the dictionary. You see, >def creates a new binding, rather than setting a variable. What you >should do is create one binding somewhere, and use "/fu 0 store" >instead. If you want local bindings, do something like: Although it is a good idea to create local dictionaries, it is not true that "def" will fill up a dictionary. It does not "create a new binding," it essentially just overwrites the old one. A far more likely cause for a "dictfull" error is for something else to accidentally leave a dictionary on the dictionary stack that has very few entries left in it. Look for a "begin" without a matching "end" somewhere. User-defined fonts are famous for this. You might also put in tests with "countdictstack" when entering and leaving various procedures, issuing an error message if they don't match. I haven't had a chance to look at the original posting yet; perhaps I will notice something. Glenn Reid Adobe Systems
cplai@daisy.UUCP (Chung-Pang Lai) (02/14/89)
In article <429@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes:
]
]A far more likely cause for a "dictfull" error is for something else to
]accidentally leave a dictionary on the dictionary stack that has very
]few entries left in it. Look for a "begin" without a matching "end"
]somewhere.
We encounter similar problem. For us, this is a mystery. A perfectly OK
PS file prints fine one time but generates a dictfull the other time.
Our theory is that due to our EOT problem with our QMS PS 800II, the
dictionary was left behind by the previous job. Someone in our company
will hook up a line monitor to see if the problem of losing the EOT is in
the printer or in the unix spooler.
--
.signature under construction ...
{pyramid, osu-cis, uunet, killer}!daisy!cplai C.P. Lai
cplai%daisy.UUCP@uunet.UU.NET cplai%daisy@killer.DALLAS.TX.USA
Daisy Systems Corp, 700B Middlefield Road, Mtn View CA 94039. (415)960-6961