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!mhuxj!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!laser-lovers From: laser-lovers@uw-beaver Newsgroups: fa.laser-lovers Subject: dvi2ps and memory fill up Message-ID: <1416@uw-beaver> Date: Sun, 21-Jul-85 05:04:20 EDT Article-I.D.: uw-beave.1416 Posted: Sun Jul 21 05:04:20 1985 Date-Received: Wed, 24-Jul-85 21:54:07 EDT Sender: daemon@uw-beaver Organization: U of Washington Computer Science Lines: 33 From: Neal Holtz Then I will also reply to the net: ================== Delivery-date: Friday, July 19, 1985 at 16:09 ADT From: Neal Holtz To: Robert Morris In-Reply-To: dvi2ps:48 Message-ID: dvi2ps:49 Subject: Re: dvi2ps Users? - quick way to increase capacity (# of pages) Your analysis is substantially correct. The context is that dvi2ps is a quick and dirty way to get TeX output on a LaserWriter -- it downloads all the TeX fonts and does not use any of the resident ones. Horrible, I know, but pleasingly effective (3 pages/minute on long documents). The structure of the downloaded PS code for every page in the document is: - start-of-page - down load all new char bitmaps for that page - save - down load all typesetting instructions (strings, etc.) - restore It does reclaim considerable VM after every page, but obviously not the bitmap downloading. That has to be done outside the save/restores (I think), or else you have to download all chars every page (instead of each char only once) -- that would be too expensive. So what happens is that VM eventually fills with downloaded chars and font dictionaries -- so that was why the suggestion of 'note' pagestyle.