laser-lovers@uw-beaver (07/20/85)
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.
laser-lovers@uw-beaver (07/24/85)
From: Bruce Baker <bwb@textset>
"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)."
By way of contrast to the public domain "dvi2ps" program, Textset's
DVILASER/PS produces average printed pages at the rate of 20 seconds
per page on an Apple LaserWriter.
Processing TeX pages through DVILASER/PS on the host operating system
averages approximately twice as fast as the best optimized version of TeX
for a given operating system, except on the IBM PC AT where it runs
just slightly faster than TeX.
The only real bottleneck is PostScript processing on the printer itself.
Part of the speed of DVILASER/PS is accomplished by "permanently" downloading
a set of most commonly used fonts as designated by the user.
DVILASER/PS is now installed on Sun/Unix, Apollo/Aegis, VAX/VMS, and IBM
PC AT/MSDOS with excellent performance on all systems.
DVILASER/PS includes spooler support, has no known limitations on the number
of pages in a document, includes support for integrating PostScript graphics
in TeX documents, includes support for both downloaded and resident LaserWriter
fonts, allows designation of multiple xy origins on landscape or portrait pages,
supports typesetting at any designated angle from the horizontal, includes
support for an extended version of LaTeX that directly emits PostScript code
enhancing LaTeX's picture environment capabilities, etc.
We hope to have benchmarks available relatively soon for two other PostScript
printers---the QMS Lasergrafix 1200A and the Apollo DOMAIN/LASER-26.
Bruce Baker
Textset, Inc.
(313) 996-3566
[[Editor's note---parts of this message seem to come a little closer
than I'd like to sounding like a marketing fact sheet, but I'm
inclined to pass the message through because it may be of interest to
readers of the list. I hope that Textset will feel free to speak up
in the future when they can help the rest of us with technical issues
associated with the LaserWriter! And as a note to Bruce, I can't
figure out what your uucp path might be, based on the header
information. Would you please send me a path relative to some well
known uucp node, such as ihnp4? --Rick ]]laser-lovers@uw-beaver (07/27/85)
From: Robert Morris <ram%umass-boston.csnet@csnet-relay.arpa>
_______________
"By way of contrast to the public domain "dvi2ps" program, Textset's
DVILASER/PS produces average printed pages at the rate of 20 seconds
per page on an Apple LaserWriter."
____________________
20 secondsPerPage 3 pagesPerMinute ne
{(amazing!) print} {(hype!) print } ifelse
In any case, people should not be proud of getting 3 pages
per minute out of an 8 page per minute engine, especially for
text.....(in fairness, the authors of dvi2ps have here
observed that they have not tried to optimize). For TeX a
nice measure might be the time to print the entire TeX manual
as a single job. In all likelyhood, as per discussion here, to
make this work with downloaded fonts will end up requiring
characters to be loaded more than once when the printer runs out
of VM.laser-lovers@uw-beaver (08/30/85)
From: Scott Jones <saj@MIT-PREP.arpa> 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 ]]