[test case attached] No print image of .eps graphics in .dvi files when path to the .eps file is not the current directory

Submitted by Russell Howell
<email address hidden>

This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at [WWW] https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in kile.

It's doubtful that the bug is in Kile, as the same version of Kile running under SuSE 10.0 does not exhibit the problem described above. I've searched through the https://wiki.ubuntu.com/Bugs/FindRightPackage link, but can't seem to find the package that is obviously at fault.

In that case please provide the output of the printingbug info script for some basic information about your printing setup. The printing bug info script can be found here: https://wiki.ubuntu.com/PrintingBugInfoScript.

UPDATE:

The bug must be in some Ubuntu 7.04 package. I just hooked up my laptop (running Ubuntu 6.06 with the same version of Kile) and successfully printed onto the same printer.

Thank you for such prompt responses. The printingbuginfo file is attached.

Does this happen with both gs-gpl and gs-esp?

Run this command from a terminal to change to gs-gpl:
$ sudo update-alternatives --set gs /usr/bin/gs-gpl

You can return to ESP Ghostscript with this command:
$ sudo update-alternatives --set gs /usr/bin/gs-esp

Yes, the problem occurs with both gs-gpl and gs-esp.

In fiddling around I noticed a bug report where images were not even showing up in someone's .dvi file. I don't know if my printing problem could be related, but just thought I'd mention this observation.

To rule out a driver issue, do you have the same problem with a raw queue printer?

Proceed as following to set up a raw queue printer:
1. Edit /etc/cups/cupsd.conf and activate the FileDevice directive so that it reads FileDevice Yes (without the "#" in the beginning).
2. Then restart the CUPS daemon:
$ sudo /etc/init.d/cupsys restart
3. Set up printer queue:
$ lpadmin -p tofile -E -v file:/tmp/printout
4. Print the problem document from kile using the raw queue printer
5. View /tmp/printout with you favorite PostScript viewer.

First (and I hope this is not an important issue), I am running under Kubuntu and not Ubuntu.

I say this because there was no commented line with the "FileDevice Yes" directive. I edited the /etc/cups/cupsd.conf file and put that line at the end (without the quotes, of course). The file is attached.

Second, after following your instructions there was no /tmp/printout file after I printed. The tofile printer had been created, but nothing showed up in /tmp, not even if I printed as root.

Finally, hoping this will help you sort out the driver question, I offer the following as evidence that the issue is not print driver related:
1. My laptop, running (K)Ubuntu 6.06 successfully printed to the same printer (Canon PIXMA ip4200) using EXACTLY the same driver (i.e., the same file).

2. My laptop also successfully printed to an HP5650 printer, using the driver packaged with (K)Ubuntu 6.06, but my desktop (the one that is having problems) produced the same error when printing to the HP5650. It used the driver packaged with (K)Ubuntu 7.04.

Attached is an .eps file that will help in exhibiting the problem. The .tex file is given below. It is first referenced with a relative location (the current directory), then it is referenced with an absolute address (but to the same directory). Both graphics images appear in the .dvi file that gets generated, but only the first one successfully prints.

This seems like a serious problem, as one would not want to copy graphics files into a current directory just to resolve a printing issue.

Thanks for your help.

===================
\documentclass[letterpaper, 11pt]{article}

\usepackage{graphicx}

\parindent=0in
\parskip 10pt

\begin{document}

Here is an example of the graphics problem.

First, we include a file in the current directory (/home/howell/temp), but do not provide a full path listing to it.

\includegraphics[width=2in]{vector_field.eps}

Next, we reference the same file in the same location with an absolute address.

\includegraphics[width=2in]{/home/howell/temp/vector_field.eps}

Both files show up in a .dvi output, but only the first one appears on printed output. In addition, files that are in a
subdirectory of the current location seem to print out successfully provided a relative path is given.

\end{document}

It is worth noting that the graphics .eps file is not part of the DVI file, it is only referenced; so this can hardly be blamed kile. Kubuntu 7.04 is no longer a supported version; can you please test if the problem still occurs on a later version of kubuntu?

From reporter; so everything looks to be good:
"Thank you for this message. The bug should have been reported as one in
dvipdfm. There is now a patch available for it, and I think the patch has
been incorporated into Ubuntu 8.10 and higher."
And thanks to Russell for getting back quickly.