This file answers the following questions about installing xdvi: 1. Why do I get the message, ``Caution: overstrike characters may be incorrect'' when running netscape and xdvi simultaneously, and why does the screen output look so grainy? 2. I have font files cmr10.tfm, etc. Why can't xdvi use them? 3. I can't seem to set the font path correctly. Can you help me? 4. Whenever I run xdvi, it prints out things like: - mktexpk --mfmode cx --bdpi 300 --mag 'magstep(0)' --dpi 300 cmr7 '>&3' mktexpk: /var/cache/fonts/pk/cx/public/cm/cmr7.300pk already exists. Why is this? 5. xdvi claims to support virtual fonts, but I can't use PostScript virtual fonts (such as helv.vf or phvr.vf) with xdvi. Why not? 6. Why can't xdvi correctly display metapost files containing text? 7. What does the message "gs: No such file or directory" mean, and why does xdvi need to call ghostscript? 8. Why does the file selection popup look messed up when changing directories? 9. Why do I get the message "dvips: ! couldn't open output pipe" when I try to print, using Red Hat 8.0? as well as the following questions (dependent on some quite old versions of software): 10. Why do I get weird vertical color stripes when using xdvi on my S3 Virge video card? 11. I am using gs 5.50 to render PostScript figures, and I find that sometimes characters appear on the wrong page. Why is that? 12. I am using gs 3.33 to render PostScript figures, but find that it cuts some off below or to the right of a certain point, and others are omitted entirely. 13. I am trying to display PostScript specials with -DPS_GS, but instead I get the message `gs: gs: Malformed ghostview color property.' 14. What is this "_get_wmShellWidgetClass undefined" error? Last modified: 20 June 2003 A current copy of this file can be viewed on the WWW at the URL /~vojta/xdvi_faq.txt ---------- 1. Why do I get the message, ``Caution: overstrike characters may be incorrect'' when running netscape and xdvi simultaneously, and why does the screen output look so grainy? This is because your video setup has only a limited number (typically 256) of different colors that can be displayed at any given time, and netscape is using most of them. There are several ways around this problem: o Start xdvi before netscape. This should eliminate the problem for that copy of xdvi (only). o Invoke netscape via "netscape -ncols 130" This limits netscape's color usage to 130. Other numbers may be used as well. o Invoke netscape via "netscape -install" This causes netscape to run with its own colormap. A disadvantage of this approach is that netscape's colors will be bizarre when the cursor is outside netscape's window, and conversely all other colors on the screen will look funny when the cursor is in the netscape window. The screen output looks so grainy because xdvi is not able to use its anti-aliasing features without enough colors. ---------- 2. I have font files cmr10.tfm, etc. Why can't xdvi use them? tfm files contain only minimal information about the characters in a font: just the height, width, depth, and kerning and ligature information. To obtain information about the shapes of the characters, xdvi needs pk or gf files. (pxl files also contain this information, but are obsolete. There are utilities to convert them to pk files though.) ---------- 3. I can't seem to set the font path correctly. Can you help me? Try xdvi -debug 32 file.dvi to find out where xdvi is looking for the fonts. ---------- 4. Whenever I run xdvi, it prints out things like: - mktexpk --mfmode cx --bdpi 300 --mag 'magstep(0)' --dpi 300 cmr7 '>&3' mktexpk: /var/cache/fonts/pk/cx/public/cm/cmr7.300pk already exists. Why is this? It means either that: (1) Your ls-R database is not up to date (fix this by running mktexlsr), or (2) Your font path is not set correctly (see #3, above). ---------- 5. xdvi claims to support virtual fonts, but I can't use PostScript virtual fonts (such as helv.vf or phvr.vf) with xdvi. Why not? The short answer is to quote the man page: Virtual fonts are also supported, although xdvi does not have any built-in fonts to which they can refer. As further explanation, let me begin by pointing out: VIRTUAL FONTS ARE NOT FONTS. Virtual fonts are recipes for building fonts from other fonts. In the case of PostScript fonts, those other fonts reside on your printer. This is fine for dvi-to-PostScript programs such as dvips, but it presents a problem for xdvi since it cannot access your printer. There are some solutions, however. The first solution is to install gsftopk, which uses ghostscript to approximate the fonts. It is made for sites that use both xdvi and dvips, although if you just use xdvi it should be useful, too. Another solution is to get these fonts pre-made in common sizes. These were made by a program called gsrenderfont (part of the Gnu font utilities). These are all available via anonymous ftp: gsftopk from math.berkeley.edu:pub/TeX/gsftopk.tar.Z pre-made fonts from ftp.cs.umb.edu:pub/tex/psfonts.tar gsrenderfont from prep.ai.mit.edu:pub/gnu/fontutils-0.6.tar.gz ---------- 6. Why can't xdvi correctly display metapost files containing text? The problem is that the PS files created by MP are (normally) not self-contained. xdvi delegates the display of PS files to ghostscript, which fails to handle those files. A solution is to instruct MP to create true EPS files, by including prologues:=2; at the top of the document. If you have the CM postscript fonts installed so that ghostscript can find them, you can continue to use the CM fonts, otherwise you'll have to switch to Times or such for the illustrations. Switching the fonts can be done setting 'defaultfont' to something like "ptmr8r" (for Times). For the TeX material in 'btex .. etex' blocks, it is best to set up the fonts once in a 'verbatimtex .. etex' block. (And same for LaTeX of course.) This answer courtesy of Olaf Weber. ---------- 7. What does the message "gs: No such file or directory" mean, and why does xdvi need to call ghostscript? The message "gs: No such file or directory" means that xdvi needs to call ghostscript, but does not find it on your system. Ghostscript is a program used for rendering PostScript. It is needed by xdvi (1) for displaying PostScript specials in documents, and (2) for rendering PostScript fonts occurring in documents. In the latter case, xdvi calls a script (usually named mktexpk) which in turn calls the program gsftopk to render the font in a form usable by xdvi. ---------- 8. Why does the file selection popup look messed up when changing directories? This is a bug with XFree86 version 4.0.1a (and possibly other versions). Upgrading to version 4.0.3 (or newer) should fix the problem. ---------- 9. Why do I get the message "dvips: ! couldn't open output pipe" when I try to print, using Red Hat 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 the bug report: https://sourceforge.net/tracker/index.php?func=detail&aid=717663&group_id=23164&atid=377580 and the discussion on the tetex mailing list: http://www.mail-archive.com/tetex@informatik.uni-hannover.de/msg01782.html 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: --- begin script --- #!/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: $!"; --- end script --- ---------- 10. Why do I get weird vertical color stripes when using xdvi on my S3 Virge video card? This is a bug in the XF86_S3V X server. It has been reported to XFree86. The response from them is that the XF86_S3V server is being phased out and that users should use the XF86_SVGA server instead (which also, as of XFree86 3.3.3, supports the S3 Virge chipset). ---------- 11. I am using gs 5.50 to render PostScript figures, and I find that sometimes characters appear on the wrong page. Why is that? This is a bug in ghostscript 5.50. The following patch will fix it: *** gdevx.c.orig Fri Jul 17 07:31:27 1998 --- gdevx.c Sat Oct 17 23:42:50 1998 *************** *** 59,65 **** ((gx_device_X *)(dev))->up_area = 0,\ ((gx_device_X *)(dev))->up_count = 0 #define update_flush(dev)\ ! if ( ((gx_device_X *)(dev))->up_area != 0 ) update_do_flush(dev) private void update_do_flush(P1(gx_device *)); #define flush_text(dev)\ --- 59,66 ---- ((gx_device_X *)(dev))->up_area = 0,\ ((gx_device_X *)(dev))->up_count = 0 #define update_flush(dev)\ ! if ( ((gx_device_X *)(dev))->up_area != 0 || IN_TEXT((gx_device_X *)(dev)) )\ ! update_do_flush(dev) private void update_do_flush(P1(gx_device *)); #define flush_text(dev)\ ---------- 12. I am using gs 3.33 to render PostScript figures, but find that it cuts some off below or to the right of a certain point, and others are omitted entirely. You should apply the following patch. This will also fix similar errors with ghostview. This patch supersedes a previous patch I have suggested to some people. *** gdevxini.c.orig Sun Nov 6 13:46:42 1994 --- gdevxini.c Mon Jun 5 15:40:18 1995 *************** *** 319,344 **** /* The following sets the imageable area according to the */ /* bounding box and margins sent by ghostview. */ ! { float m[4]; ! m[0] = (llx - left_margin) / 72.0; /* left */ ! m[1] = (lly - bottom_margin) / 72.0; /* bottom */ ! m[2] = xdev->width / xdev->x_pixels_per_inch - ! (urx + right_margin) / 72.0; /* right */ ! m[3] = xdev->height / xdev->y_pixels_per_inch - ! (ury + top_margin) / 72.0; /* top */ ! ! /****** ! ****** For reasons I don't understand, ! ****** we have to set the margins to zero here ! ****** in order for Ghostview to do landscape display right. ! ******/ ! #if 0 ! m[0] = m[1] = m[2] = m[3] = 0; ! #endif ! ! gx_device_set_margins((gx_device *)xdev, m, false); ! } ! } else if (xdev->pwin == (Window)None) { eprintf("gs: Cannot get ghostview property.\n"); exit(1); --- 319,329 ---- /* The following sets the imageable area according to the */ /* bounding box and margins sent by ghostview. */ ! xdev->ImagingBBox[0] = llx - left_margin; ! xdev->ImagingBBox[1] = lly - bottom_margin; ! xdev->ImagingBBox[2] = urx + right_margin; ! xdev->ImagingBBox[3] = ury + top_margin; ! xdev->ImagingBBox_set = true; } else if (xdev->pwin == (Window)None) { eprintf("gs: Cannot get ghostview property.\n"); exit(1); ---------- 13. I am trying to display PostScript specials with -DPS_GS, but instead I get the message `gs: gs: Malformed ghostview color property.' xdvi needs at least version 2.6.2 of ghostscript. It will also run with ghostscript 2.6.1, provided you have applied fixes 1-4. This particular error message means that you are running gs 2.6.1 without fixes 1-4. Probably you should get a newer version of ghostscript. ---------- 14. What is this "_get_wmShellWidgetClass undefined" error? In SunOS 4.1.2 Sun fixed a shared-library bug in ld which conflicts with the way X builds the shared Xmu library, causing these symbols, notably, to be undefined when building some X11 clients on SunOS 4.1.[23]: _get_wmShellWidgetClass _get_applicationShellWidgetClass Compiling "-Bstatic -lXmu -Bdynamic" is overkill; be sure to set OSTeenyVersion correctly in the config/sun.cf file and rebuild X11R5. To solve the problem if you are using OpenWindows 3.0 (X11R4-based Xt), please contact your local Sun office and request the following patches: Patch i.d. Description 100512-02 4.1.x OpenWindows 3.0 libXt Jumbo patch 100573-04 OpenWindows 3.0: xstdcmap fails to set XStandardColomap for 24-bit machines [this also fixes bug 1087332, "With patched ld and libc, customer is getting undefined symbols"] [Greg Earle, earle@Sun.COM; 7/92] A source patch for use with the X11R4 libraries was developed by Conrad Kimball (cek@sdc.boeing.com); it retrofits into R4 some fixes made in R5 to get around this problem. The patch is on ftp.x.org in [1/93] contrib/X11R4_sunos4.1.2_patch_version3.Z