TeX-psfig problem: Summary
- To: mathgroup at yoda.physics.unc.edu
- Subject: TeX-psfig problem: Summary
- From: Pekka.Janhunen at fmi.fi
- Date: Wed, 9 Dec 1992 15:09:47 -0800
>I often use the psfig TeX macro package to include (e.g.) Mma-
>produced graphs in my publications. I use Display and psfix
>commands to obtain the PS files. However, more than often I
>encounter the problem that the printer (LaserWriter) refuses
>the print the TeX pages with Mma-produced figures. I use Mma
>kernel on a SGI Iris4D environment. Previewing the publication
>with GhostScript never has any trouble, but I would like to
>have it printed too :) I have also tried a bigger (Digital) printer
>and this sometimes helps, sometimes not. If I print the graphics
>pages alone, that is without psfig, then I usually have no
>problems.
>
>Is anyone else experiencing a similar problem? Does the scaling
>performed by psfig somehow destructively interfere with Mma
>produced PostScript? Since this is a major problem, I have considered
>having GhostScript render the graphics with 300 DPI resolution
>and then sending that as a huge bitmap-PS to the printer...
>
Thanks to everyone who replied -- especially Henning Leidecker. I received
many clues and hints, more or less related to the original problem. The
following were the general trends:
1) LaserWriter & LW NTX have problems with psfig/TeX. They can sometimes
(always?) be cured by cycling the power on the printer (Dan Dill).
2) LaserWriter sometimes has problems with setrgbcolor command. One time I
reportedly got the printer working by replacing Mma-produced '0 0 0.5
setrgbcolor' by '0 0 0 setrgbcolor'. The code sequence was produced from
MeshLines option.
3) Probably unrelated to the above problem, LaserWriter(&NTX) have problems
if the current path contains more than a fixed number (1500, if I remember)
of objects. If the user eg. creates a too long list of Points in Mma and
calls Graphics and Show, the resulting PS may be unprintable.
4) Tony Silva proposed removing unnecessary fonts with the following
script:
BEGIN {p = 1}
$1 == "%%BeginFont:" { p = 0 }
{ if (p==1) print $0 }
$1 == "%%EndFont" { print "bn"; p = 1 }
$1 == "%%EndFont:" { print "bn"; p = 1 }
I appears that this is not related to my problem.
5) At least an HP printer has thus far printed all problematic files with
no extra tricks.
The ultimate solution ?
-----------------------
If a printer cannot render the PS file because of some resource overflow
(dictfull; VM error; etc.) there is not much one can do, except to use
GhostScript (gs) to render the file in the computer to produce a PPM file
using the pstoppm command under gs. The ppm file can then be turned into
bitmap-PostScript, in our system (SGI) the command to do this is pnmtops.
It should not be too difficult to do the filtering from scratch in C. For
example, for 300 dpi B/W printer, the bitmap postscript file will be about
2Megabytes large and it will take 5-10 min. to send and render it on a
LaserWriter NTX. A universal script which takes a PS file and generates
another, usually larger, bitmap-PS file can be written. Pros and cons:
+ absolutely everything you see on GS screen, you see on paper too
+ for complicated pictures, the method can be faster
+ can be adapted to non-PS printers
- rendering everything in a workstations 300dpi takes CPU time
- gs is not completely faithful: for example rounded line endings are not
implemented
Pekka Janhunen