[tex-k] xdvi with gs 7.0.4, and a test for making good pdf

M. Shell mshell@ece.gatech.edu
Mon, 18 Feb 2002 02:47:20 -0500

Stefan Ulrich wrote:

> Thanks for pointing this out. Actually xdvik (which version are you
> using?) doesn't pass the relative path to gs, but it prepends
> the current DVI file path, so that
> \includegraphics{../eps/fig.eps} in a file /home/usr/tex/test.dvi
> will yield
> /home/usr/tex/../eps/fig.eps
> (and if that fails, it will try a kpathsearch on the PS file).
> (You can test by looking at the output of `xdvi -debug 32').
> So it seems that gs doesn't allow `..' in path names. (Is this in
> secure mode only? `-nogssafer' will turn off the `-dSAFER' option
> of gs).

The problem will happen with gs 7.04 and xdvi(k) version 22.05d-k
as well as xdvi(k) version 22.40h. gs 7.03 and earlier work
just fine, so that last 0.01 is a doosy. ;) 

22.05d-k does not appear to prepend the current dvi path, 22.40h does.

When called by xdvi, gs does have the -dSAFER option. It is probably
best to leave gs in the secure mode.

I do not understand why they would consider /../ to be a security
risk - I mean gs is running under my user ID and cannot read 
anything that I cannot from a shell prompt. With web servers I can
understand because they run with another UID.

In other news, I am preparing the next release of the IEEEtran.cls
which I maintain:
A few of my beta testers ran into some trouble with pdf files. More than
a few IEEEtran users tend to be inexperienced LaTeX users - many are
using it for the first time with their research papers.

At any rate, I decided to look into the problems with generating good
pdf files using LaTeX so that I can include some tips in the formal
documentation I am writing. What I found on the newsgroups was just
appalling - it seems that there is an enormous amount of confusion about
what a user needs to do to get good pdf. Especially when going the 
dvi > ps > pdf route (and I like the dvips way because I can't live without
psfrag). Compounding the problem is that IEEEtran.cls users have to use 
Times Roman for text and Computer Modern for math.

It is important that any generated pdf files work reliably with
Acrobat reader (at least the versions >= 4.0.5; 4.0 and before is
pure junk IMHO) because lots of people rely on this bug ridden 

To help them out, I have developed a "testflow.tex" based on the standard
LaTeX testpage.tex, but with a battery of tests that are designed to
trip up on all the common bugs I could identify from reading the 
newsgroups. This is to help them ensure that their print work flow is in
good shape before they actually start printing their paper.

Formal documentation is not ready yet (some notes are in the source
comments), but if anyone wants to try out my "super ps/pdf trip test"
you can download my testflow files from:


See if you can recreate my testflow_ctl.pdf and get good print outs
under Acrobat 5.0.

Any advice you guys can give me about it would be much appreciated.

Some of the more interesting tid bits is the discovery that Acrobat reader
will display Times Roman as Times New Roman. (This is the result of another 
"Microsoft thing".) When printing, the PostScript engine of the printer
will restore things to Times Roman (I _think_ that's where the final Times
Roman fonts come from), but Acrobat will have sent the printer the Times
New Roman metrics! So, you can end up having little problems like quote
marks getting too close to letters. The only way out of this is to subset
and embed ALL the fonts used including the base 14 ones. Recent versions
of Ghostscript allow this, I don't know yet if recent versions of pdftex do.

A good thread on this was in the pdftex mailing list in October 2000,
but the archives on TUG seem to have lost a lot of months including
this one. I emailed Sebastian about the missing months, but haven't
heard back yet. For now, the thread exists only in Google's cache:






 Thanks again,
 Mike Shell