On 10/27/06, Benjamin Hornberger <bho@...> wrote:
> At 05:59 PM 10/27/2006 -0400, you wrote:
> >Benjamin Hornberger wrote:
> > > Hi all,
> > >
> > > after upgrading to MikTeX 2.5, I have trouble processing documents
> > > which worked without problems on MikTeX 2.4. Some (only some) EPS
> > > files cannot be rendered any more in Yap. One such file is
> > > http://www.esnips.com/doc/be4dbe61-8a6a-49c9-8b86-bae7a1f7fdc0/plot.eps.
> > > Included in a test document as shown below and texify'd (from
> > > WinEdt), Yap first sais it can't be rendered properly and asks to
> > > switch to the Dvips render method. When answering "No", no graphics
> > > is displayed. When answering "Yes", Yap doesn't respond any more and
> > > must be killed.
In some cases, this behaviour occurs when the installed Type1 fonts
don't match the corresponding lines in
ghostscript/base/Fontmap.miktex. There have been 2 versions of the
latter file: a) for use with the obsolete URW font package, and b) for
use with the individual URW fonts. If you have gs8.54 installed to
C:\gs, then mgs will use the fonts from gs8.54, thus masking the
problem in Fontmap.miktex.
> > > The EPS file mentioned above has been created in the IDL programming
> > > language (http://ittvis.com/idl/). If I open that file in Adobe
> > > Illustrator and re-save it as EPS (compatibility: Version 7.0, no
> > > preview, no thumbnails included, fonts included (*important*),
> > > PostScript level 2), it works (Yap can render it if the Dvips render
> > > method is chosen).
I use IDL on SGI IRIX64 machines that were upgraded from IRIX5.3 and
still have real Adobe fonts from the DPS system. Helvetica Narrow is
a troublemaker, but there are also problems because renderings of EPS
files often end up using URW Nimbus San L (aka URW Nimbus Sans L) or
Arial. Including font in Illustrator is a way of avoiding
misconfigured Fontmap files. Your file uses Helvetica, which mgs will
render using Nimbus San(s) L.
> >A lot of people have been reporting similar issues lately, but this
> >really sounds like your EPS file contains some cruft that shouldn't be
> >there. Try "converting" it to EPS using eps2eps, a script that should be
> >included in your Ghostscript distribution. It can often clean up
> >problematic EPS files.
My workflow converts EPS to PDF, which will generally work even for
files that are not EPS, and using pdflatex, so I'm not sure what
problems exist in IDL EPS files.
"epstool --test-eps plot.eps" says:
File has %%BoundingBox: 0 0 476 340
Correct is %%BoundingBox: 11 9 428 328
PostScript appears well behaved.
File claims to be EPS.
PASS: File appears to be well behaved EPS.
> eps2eps creates an EPS file which is now only 2.8 kB small (37 kB
> before). GSview can't open it any more (it could open the original
> one), giving the error message below. When texify'ing, Yap sais "The
> page could not be rendered" (but doesn't crash any more).
> Somebody else suggested
> gswin32c -q -sDEVICE=epswrite -sOutputFile=outfile.eps -dNOPAUSE
> -dBATCH -dSAFER infile.eps
> which works, but the font rendering is GSview as well as Yap looks
> worse than for the file created by Illustrator.
This converts fonts to bitmaps. You can try adding "-dNOCACHE", which
converts fonts to outline paths and is yet another way to avoid font
problems, but you loose font hinting, so the quality for screen
viewing will suffer, but the files should be fine on a typesetter.
> Anyway, thanks for the help! Any more ideas?
I doubt there is anything wrong with plot.eps, but I won't be near
Win32 for a couple days to try it. I have tried all sorts of bad eps
files on my
MikTeX-2.5 system and while I get messages for pages with figures that
can't be rendered, it has never hung. Maybe the popup window is
hidden behind something.
In a cmd shell, "set MIKTEX_GS_LIB=<miktex
path>/ghostscript/tools;<miktex path>/fonts" and run "mgs -h" to
verify the search paths, then "mgs file.eps" to see if mgs can render
George N. White III <aa056@...>
Head of St. Margarets Bay, Nova Scotia