Xdvi(k) FAQ: Common problems, tips & hints

As reported by William McCallum here (scroll down to the entry dated `2002-10-11 04:32'), versions >= xdvik-22.40n should compile on Mac OS X. The --with-system-wwwlib configure option is no longer needed for versions >= xdvik-22.71.

2. Updating to ghostscript 7.x/8.x broke the display of EPS files in xdvi!

Unfortunately there have been two incompatible changes in ghostscript which both broke xdvi's passing of EPS files to ghostscript:

In ghostscript 7.04, the file access options were changed to implement a better security scheme, breaking the `gsSafer' option in xdvik. For more information on this, see e.g. here and here.
A fix for this incompatibility was implemented in xdvik-22.40j.
Ghostscript 8.00 changed the handling of EPS files, inserting an explicit showpage command. This makes xdvi hang forever when it tries to display an EPS file (it will still respond to keystrokes like `Q', but it won't display anything). See also this bug report on the xdvik bug reporting page.
A workaround is to change the first line in EPS files from e.g.
```
	 %!PS-Adobe-2.0 EPSF-2.0
	 
```
to
```
	 %!PS-Adobe-2.0
	 
```
A fix has been included in xdvik-22.40s, released on 2002-11-30.

3. None of the shrink factors really fits. Why can't I use in-between values, like 3.5? Or maybe 0.5 to make the fonts even larger?

Unfortunately, the maximum resolution is fixed to the Metafont mode used, and all other factors are integer fractions of that; e.g. the shrink factor 1 corresponds to a real size of 300dpi for a 300dpi Metafont mode.

(The reason for fixing the maximum resolution is that generating PK fonts for a certain resolution is time and space intensive, especially on older computers, so it's linked to the resolution used when printing. Allowing for non-integer shrink factors would be possible in theory, but it would require major changes in the way xdvi computes anti-aliasing etc. and probably won't be implemented soon.)

A workaround is to use a different Metafont mode. If you're using mainly Type1 fonts (and have xdvi configured properly - see the section T1LIB in the xdvi(1) man page) no additional PK fonts will be generated. Only for Metafont fonts, PK generation will be neccessary, but on today's systems, the time and space requirements shouldn't be a real problem. E.g. if you're currently using a 300dpi mode like `cx', use a 600dpi mode instead, e.g.:

      xdvi -mfmode ljfour:600

(or `xdvi.mfMode: ljfour:600' in ~/.Xdefaults). Then all fonts will have twice the size, and shrink factor 7 will correspond to what 3.5 would have been for 300dpi. This will also improve the anti-aliasing of the fonts in xdvi. On modern displays which typically have around 100dpi, a Metafont mode >= 600dpi will yield the best display quality.

4. Printing via dvips doesn't work with RedHat 8.0!

When trying to print a file, the log window shows the following output:

This is dvips(k) 5.86 Copyright 1999 Radical Eye
Software (www.radicaleye.com)
' TeX output 2003.04.08:1919' -> !lpr
dvips: ! couldn't open output pipe

This is a known bug in (RedHat's customized version of) dvips' `secure mode', forbidding dvips to open pipes for printing (see also this bug report and this discussion on the tetex mailing list).

A possible workaround is to set the xdvi command-line option `-dvipspath' or the `.dvipsPath' X resource to a wrapper script that invokes dvips in a way that avoids the problem. An example for such a script (in Perl) is shown here:

#!/usr/bin/perl -w
#
# Wrapper for xdvi to launch dvips and avoid its secure feature that disallows
# piping to lpr (dvips 5.92b / RH 8.0; 4/2003). Specify with -dvipspath option
# (or .dvipsPath X11 resource) in xdvi. Written by S. Ulrich and P. Vojta.

my @dvips_args = ("dvips");
my $lpr_cmd;

# Extract lpr command from the dvips args given in implicit pipe, if any
foreach (@ARGV) {
  if (/^-o[!\|](.*)/) {
    $lpr_cmd = '|' . $1;
  } else {
    push (@dvips_args, $_);
  }
}

# Construct explicit pipe with given lpr command
if (defined $lpr_cmd) {
  open(STDOUT, $lpr_cmd)
    or die "Couldn't open output pipe $lpr_cmd: $!";
}

# Exec over to dvips
exec @dvips_args
  or die "Couldn't exec dvips: $!";

Last updated on Sun, 10 May 2009 22:14:13 +0200 by Stefan Ulrich