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!linus!decvax!tektronix!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver
Newsgroups: fa.laser-lovers
Subject: dvi2ps
Message-ID: <1411@uw-beaver>
Date: Sat, 20-Jul-85 05:45:12 EDT
Article-I.D.: uw-beave.1411
Posted: Sat Jul 20 05:45:12 1985
Date-Received: Sun, 21-Jul-85 23:37:48 EDT
Sender: daemon@uw-beaver
Organization: U of Washington Computer Science
Lines: 54

From: Robert Morris <ram%umass-boston.csnet@csnet-relay.arpa>

I meant to send this to the list:
__________
	From ram Fri Jul 19 09:49:00 1985
	Received: by umb.csnet (4.12/4.7)
		id AA01641; Fri, 19 Jul 85 09:48:50 edt
	Date: Fri, 19 Jul 85 09:48:50 edt
	From: Robert Morris <ram>
	Message-Id: <8507191348.AA01641@umb.csnet>
	To: holtz%cascade.carleton.cdn%ubc.csnet@CSNET-RELAY
	Subject: Re:  dvi2ps Users?  - quick way to increase capacity (# of pages)
	Cc: ram
	
	I missed the context of capacity problems in dvi2ps, but if it is
	the LaserWriter silently dying on long documents, I can report a 
	similar problem and what I am relatively certain(after consulting
	with Adobe) will prove the cause and solution. PS, or at least
	the LaserWriter implementation is not too clever about garbage
	collection. In particular, I suspect that the string space
	allocated to local variables in procedures is not reclaimed on exit, just the
	name of the string. This is probably true of all variable size
	resources. A big document probably causes PS to run out of memory if
	one ignores this issue.
	
	It is suggested in Sec. 3.4.11 of the PS manual
	(``Virtual Memory Operators''), that you are 
	``encouraged'' to use the save and restore operators to 
	reclaim VM. In my application, which is similar to dvi2ps,
	I expect the problem to dissappear if at the beginning of each
	page PS is restored to the state of the beginning of the
	first page. This means, though, that you must re-send any data
	which implies a change of PS global state 
	(e.g. what is the current font, pathwidth, etc.) 
	if it has changed from what you are willing to call the
	typical state before your initial save. My implementation so far
	has been with native fonts. I don't yet appreciate the
	subtleties of downloading one's own fonts - something one may argue is 
	anathema to PS -  but if the restore wipes out your font cache also
	the approach suggested here might have horrible performance implications
	(indeed, this might be true even with PS native fonts. You could be
	forcing a lot of repetition of the scan conversion of fonts).
	>From the documentation, it appears that this solution must be very carefully
	implemented with close attention to what state is actually managed by 
	save and restore manage (e.g. the values of strings are NOT saved).
	
	I will report my success or failure with this problem here, but meanwhile
	PS wizards might comment in this forum on the issue and my analysis.
	
	bob morris
	umass/boston and
	interleaf, inc.