Bug 65391

Created attachment 58252 [details]
bug.dvi and buf.lj archived

Since dvilj isn't needed for printing a DVI file (dvips works instead since we 
ship ghostscript too), perhaps we shouldn't ship dvilj at all.

Yes, dvips is probably a more general solution.
However, just to prevent a confusion: if I use lpr on a .dvi file, I
am not getting the image at all. Is dvilj involved, or its another bug?

This seems to be another bug.  In the print filter, dvips is used to convert 
DVI to PS ready for ghostscript. (This works for me.) 
 
After you try printing a DVI file with lpr, do 'lpq' and then look in the 
/var/spool/lpd/<queuename> directory---there should be a lpq.0 file.  Does 
that reveal any errors?

> After you try printing a DVI file with lpr, do 'lpq' and then look in the 
> /var/spool/lpd/<queuename> directory---there should be a lpq.0 file.  Does 
> that reveal any errors?
Yep, this does, thanks.

Status: IF filter 'mf_wrapper' filter msg - '/root/.dvipsrc: Permission denied'
at 21:21:30.899
 Status: IF filter 'mf_wrapper' filter msg - '/root/.dvipsrc: Permission denied'
at 21:21:30.899
Hmm, I don't have /root/.dvipsrc. I don't think it is important though. Or is
it?

Status: IF filter 'mf_wrapper' filter msg - '/usr/bin/dvips: Couldn't find
figure file shot1.ps; continuing' at 21:21:32.688
Yes, this is definitely when the things are getting wrong.
I really have a "shot1.ps" in the directory where the .dvi resides
and where the lpr is called. Because in case I don't have one, I won't be
able to compile "bug.tex" - \includegraphics will fail.
Hmm, and I don't remember this problem ever happened to me with
previous RH distros.
Any ideas of what can this be?
The whole directory is attached archived (lpq.0 is also there).
This really seems like not a dvilj bug.

Created attachment 58704 [details]
full directory archived

I see what's going on.  The DVI file just contains a reference to the  
PostScript file, not its contents.  The print spooler only gets to see the  
file you gave it though.  
  
So really you need to use 'dvips -R myfile.dvi' instead of 'lpr myfile.dvi' to  
be sure to get output.

> I see what's going on.  The DVI file just contains a reference to the  
> PostScript file,
...without the full path :(

> The print spooler only gets to see the  
> file you gave it though.
Do you mean that this can't be fixed? Oh my...

> So really you need to use 'dvips -R myfile.dvi' instead of 'lpr myfile.dvi'
to  
> be sure to get output.
Yes, this is how I am getting my docs printed currently.
However this is really not what I expected.
dvilj doesn't work (OK, disregard it), lpr doesn't work either.
But at least lpr must work, isn't it? (yes, I see the problem, but still...)

> ...without the full path :( 
 
Indeed, but even if it _had_ the full path that wouldn't guarantee the printer 
filter (running as user lp) access to the file. 
 
The print spooler can't really be expected to deal with every possible format; 
for DVI it makes a good attempt, but really you need dvips to get all the 
information to the print spooler.

dvilj is gone as of tetex-1.0.7-49.  Long live dvips.

Sorry for bothering you again with that,
but there is some inconvenience.

> The print spooler can't really be expected to deal with every possible format; 
> for DVI it makes a good attempt, but really you need dvips to get all the 
> information to the print spooler.
As far as I know, this was recently
resolved by removing a filter for DVI.
Yes, this solves the problem in some
way, but are there any other alternatives?
Well, I guess this obvious question was
already discussed somewhere, but I am
just wondering, is it possible to make
lpr itself to do a pre-processing? So
in case lpr invokes dvips itself and
sends a ps output to a daemon, then I
guess the problem is solved.
So my question is: can this be done so
that the filtering is performed on a
client-side rather than on a server side?
Sending only a ps format to the spooler
looks good to me.
Well, maybe that's a silly question, just
wondering...