Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uw-beaver Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!laser-lovers From: laser-lovers@uw-beaver Newsgroups: fa.laser-lovers Subject: dvi2ps Message-ID: <1521@uw-beaver> Date: Thu, 29-Aug-85 16:46:08 EDT Article-I.D.: uw-beave.1521 Posted: Thu Aug 29 16:46:08 1985 Date-Received: Sat, 31-Aug-85 06:20:12 EDT Sender: daemon@uw-beaver Organization: U of Washington Computer Science Lines: 33 From: Scott Jones I've hacked up the version of dvi2ps which was posted here a few weeks ago. New features: 1) It makes reasonably intelligent font substitutions when the requested font does not exist at the requested size. 2) It can be called as a standard filter from lpr (the standard UNIX 4.2 print spooler). I'm about to fix it so that hairy DVI files (e.g. long LaTeX documents) can be printed, but I can't decide the best way to do it. For one thing, I don't understand how to implement an LRU font management algorithm because the only way I know how to reclaim storage is by using nested save/restores which means I have to free the most recently used fonts. Yes? So does anybody out there know how to do reasonable storage management in postscript? Seems like there should be a way... My current plan of attack is to wrap a save/restore around every 10 pages (i.e. throw out EVERYTHING after every 10 pages). This is inefficient and is not guaranteed to work in all cases (e.g. if someone uses several megafonts on a single page). Has anyone hacked dvi2ps to check the result of a vmstatus? I can't seem to make that work reliably either. --Scott Jones MIT AI Lab [[Editor's note: I've asked Scott to coordinate his changes with Neal Holtz's and with luck we'll get one amazingly great version out of the combination. --Rick ]]