isaac@goanna.oz (Isaac Balbin) (02/17/89)
I feel sure many others have experienced this, I am curious, however, how they deal with it --- under Unix. I use Rokicki's dvi2ps translator from TeX to postscript. Indeed, the same thing happens for dvi2ps (by Holtz and Senn) in the standard distribution of TeX and I recall it also happened in the old days when I had to convert ditroff to postscript. What happens? After a certain amount of processing, something overflows and the rest of the large job does not print and finds its way to the great big bit-bucket in the sky. Normally, I print a large job (>30-40) pages (it also depends how much is in each page) in chunks. Is there a better solution that people use? That is, postscript code which looks after the laserprinter and doesn't let it proverbially dump core. (PS I also have to send a ^C to the printer to stop it processing after lprm'ing the rest of the job) ---------------------------------------------------------------------------- Isaac Balbin, Department of Computer Science, ACSNET: isaac@goanna.oz Royal Melbourne Institute of Technology, JANET: isaac%goanna.oz.au@uk.ac.ukc GPO BOX 2476 V, ARPA: isaac%goanna.oz.au@uunet.uu.net Melbourne, 3001, CSNET: isaac%goanna.oz.au@australia AUSTRALIA UUCP: ...!uunet!goanna.oz.au!isaac Phone: +61 3 660 2803 BITNET: isaac%goanna.oz.au@relay.cs.net Fax : +61 3 663 2764 EARN: isaac%goanna.oz.au@uk.ac.rl.earn
rodgers@maxwell.mmwb.ucsf.edu (Richard Rodgers) (02/18/89)
The original posting complained about the loss of portions of TeX output
when the output from a DVI to PostScript filter is used, and the document is
large. We solve this by using Nelson Beebe's superb filter "dvialw," which
has a -o option which allows the user to specify the page range to process.
A large document can be easily broken up into smaller sections this way,
and there is no loss of output. You can obtain Beebe's excellent DVI library
by ftp; contact Beebe at:
beebe@utah.science.edu
for instructions.
--------------------------------------------------------------------------------
R. P. C. Rodgers, M.D. Telephone:
Statistical Mechanics of Biomolecules (415)476-8910 (work)
Department of Pharmaceutical Chemistry (415)664-0560 (home)
University of California, Box 1204 E-mail:
Laurel Heights Campus, Room 102 ARPA: rodgers@cca.ucsf.edu
3333 California St. rodgers@maxwell.mmwb.ucsf.edu
San Francisco CA 94118 BITNET: rodgers@ucsfcca
USA UUCP:
...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
R. P. C. Rodgers, M.D. Telephone:
Statistical Mechanics of Biomolecules (415)476-8910 (work)
Department of Pharmaceutical Chemistry (415)664-0560 (home)
University of California, Box 1204 E-mail:
Laurel Heights Campus, Room 102 ARPA: rodgers@cca.ucsf.edu
3333 California St. rodgers@maxwell.mmwb.ucsf.edu
San Francisco CA 94118 BITNET: rodgers@ucsfcca
USA UUCP:
...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers
--------------------------------------------------------------------------------hartzell@beagle (George Hartzell) (02/19/89)
In article <11384@cgl.ucsf.EDU>, rodgers@maxwell (Richard Rodgers) writes: > >The original posting complained about the loss of portions of TeX output >when the output from a DVI to PostScript filter is used, and the document is >large. We solve this by using Nelson Beebe's superb filter "dvialw," which We had similar problems, which we solved by upgrading to transcript release 2.1. Apparently there were some problems with flow control between transcript and the printer. g. -- George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
david@torsqnt.UUCP (David Haynes) (02/20/89)
In article <11384@cgl.ucsf.EDU> rodgers@maxwell.mmwb.ucsf.edu (Richard Rodgers) writes: > >The original posting complained about the loss of portions of TeX output >when the output from a DVI to PostScript filter is used, and the document is >large. We solve this by using Nelson Beebe's superb filter "dvialw," which >has a -o option which allows the user to specify the page range to process. My copy of dvi2ps for laserwiters has the flags -t and -f for "to" and "from" page numbers. (it also has a -r for reversing the output). This is a great way to print subsections only. I can mail this to folks if they are interested. -david-
mg@cidam.rmit.oz (Mike A. Gigante) (02/22/89)
In article <1936@goanna.oz>, isaac@goanna.oz (Isaac Balbin) writes: > I feel sure many others have experienced this, I am curious, > however, how they deal with it --- under Unix. > I use Rokicki's dvi2ps translator from TeX to postscript. > Indeed, the same thing happens for dvi2ps (by Holtz and Senn) in the > standard distribution of TeX and I recall it also happened in the old > days when I had to convert ditroff to postscript. > What happens? After a certain amount of processing, something overflows > and the rest of the large job does not print and finds its way to the great > big bit-bucket in the sky. Watching the messages that come back from the Laserwriter shpows that the casuse is a VMerror. I suspect that the dvi*ps programs are not as careful as they might be w.r.t. postscript data space (or code space?) The same documents print flawlessly with MicroTeX's laser package (and spr). I have a single page that I cannot print using dvi2ps! Very frustrating indeed! Mike
piet@ruuinf (Piet van Oostrum) (02/22/89)
In article <1936@goanna.oz>, isaac@goanna (Isaac Balbin) writes:
`I feel sure many others have experienced this, I am curious,
`however, how they deal with it --- under Unix.
`I use Rokicki's dvi2ps translator from TeX to postscript.
`Indeed, the same thing happens for dvi2ps (by Holtz and Senn) in the
`standard distribution of TeX and I recall it also happened in the old
`days when I had to convert ditroff to postscript.
`What happens? After a certain amount of processing, something overflows
`and the rest of the large job does not print and finds its way to the great
`big bit-bucket in the sky.
This is usually caused by the large amount of font bitmaps that get
downloaded. I have a modified version of dvi2ps that (together with several
other nice things) tries to keep track how much VM is left free in the
laserwriter. If the amount is too small, it does not download characters
but it just sends them as a one-time bitmap. Actually this depends also on
the size of the bitmap, so large characters are never downloaded. The
various parameters can be redefined as #define's.
It does also have page selection.
I can even print GNU manuals without any problem :=)
There are a number of sites in the USA that have it for FTP and I could
post it (Where?). It is 130KB compressed/btoa'ed.
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806. piet@cs.ruu.nl (mcvax!hp4nl!ruuinf!piet)chris@softway.oz (Chris Maltby) (02/23/89)
The "bug" is caused by a design problem with garbage collection. Postscript jobs tend to accumulate fonts, and other junk as they execute. The best generic solution is to embed each page of text between a restore/save pair, and save the empty environment at start time. By restoring to the empty saved environment and then saving it again you can cause the VM garbage collection to work much better. Permanent fonts can be stored by restoring (to the backgroun environment) defining the font and then saving. Try it, it works. I have no troble printing huge troff documents with pic's tbl's and eqn's using such a system... -- Chris Maltby - Softway Pty Ltd (chris@softway.oz) PHONE: +61-2-698-2322 UUCP: uunet!softway.oz!chris FAX: +61-2-699-9174 INTERNET: chris@softway.oz.au
day@grand.UUCP (Dave Yost) (02/27/89)
In article <1175@softway.oz> chris@softway.oz (Chris Maltby) writes: >The best generic solution is to embed each page of text between a >restore/save pair, and save the empty environment at start time. By >restoring to the empty saved environment and then saving it again you can >cause the VM garbage collection to work much better. I think this advice should be stated more explicitly. Your advice as given could be construed to support a very bad practice that I have seen used in Pagemaker which should be banished because it is bad news for PostScript postprocessor programs. (I hope someone from Aldus is listening.) I suggest this statement: A PostScript document program should start each page of text with a save and end it with a restore. In addition to guaranteeing total page independence, this practice causes the interpreter's VM garbage collection to work much better. DO THIS: ... %%Page: 1 1 /x save def ... x restore %%Page: 2 2 /x save def ... x restore %%Trailer The bad Pagemaker trick looks like this: DO NOT DO THIS: /x save def %%Page: 1 1 x restore ... x restore ... %%Page: 2 2 x restore ... x restore ... %%Trailer --dave yost
chris@softway.oz (Chris Maltby) (03/01/89)
Thanks to Dave Yost for clarifying my message. My message could
have been interpreted to support the kind of dodgy practices he
mentions.
Here is some code from our ditroff to postscript translator which
deals with the problem. I hope it meets with your approval...
/page {showpage restore save newpage} bind def
/dorestore
{
currentpoint vpgn
4 -1 roll
{ 4 -1 roll restore } repeat
} bind def
/dosave
{
{ save 4 1 roll } repeat
/vpgn exch def
newpage moveto
} bind def
newpath
save save
newpage
%%EndProlog
%%Page: 2 1
720 X
120 Y
1 dorestore
/f.R /Times-Roman findfont def
1 dosave
0.0 0.0 0.0 10 10 f.R ft(page)s
933 X(2)s
page
%%Page: 1 2
720 X
120 Y
0.0 0.0 0.0 10 10 f.R ft(test)s
page
%%Trailer
--
Chris Maltby - Softway Pty Ltd (chris@softway.oz)
PHONE: +61-2-698-2322 UUCP: uunet!softway.oz!chris
FAX: +61-2-699-9174 INTERNET: chris@softway.oz.au