Bug 65391 - dvilj misplaces images
dvilj misplaces images
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: tetex (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-22 23:19 EDT by Stas Sergeev
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-28 10:13:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bug.dvi and buf.lj archived (15.48 KB, application/octet-stream)
2002-05-22 23:21 EDT, Stas Sergeev
no flags Details
full directory archived (22.12 KB, application/octet-stream)
2002-05-27 13:48 EDT, Stas Sergeev
no flags Details

  None (edit)
Description Stas Sergeev 2002-05-22 23:19:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.19-pre8-ac1 i686)

Description of problem:
The images that are at appropriate places in .dvi, are get either not
printed at all or havily misplaced by dvilj.

Version-Release number of selected component (if applicable):
tetex-dvilj-1.0.7-47 RPM for i386

How reproducible:
Always

Steps to Reproduce:
1. xdvi bug.dvi
2. lpr bug.lj
3. compare the results


Actual Results:  
xdvi shows image correctly, but at the paper there is only a small
part of the image at the bottom of the page.

Expected Results:  
xdvi output and printer output must be identical

Additional info:
Printer is LJ4L.
If I process the bug.dvi via dvips and then `lpr bug.ps`, I get the correct
results (dvilj is not get involved I guess).
bug.dvi and bug.lj are attached.
bug.lj was produced by dvilj4l.
If I do `lpr bug.dvi` without manually running dvilj, I don't get
any signs of image at all.
Comment 1 Stas Sergeev 2002-05-22 23:21:09 EDT
Created attachment 58252 [details]
bug.dvi and buf.lj archived
Comment 2 Tim Waugh 2002-05-24 10:11:25 EDT
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.
Comment 3 Stas Sergeev 2002-05-24 14:28:09 EDT
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?
Comment 4 Tim Waugh 2002-05-27 11:17:26 EDT
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?
Comment 5 Stas Sergeev 2002-05-27 13:45:38 EDT
> 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.
Comment 6 Stas Sergeev 2002-05-27 13:48:43 EDT
Created attachment 58704 [details]
full directory archived
Comment 7 Tim Waugh 2002-05-28 05:49:18 EDT
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.
Comment 8 Stas Sergeev 2002-05-28 10:08:21 EDT
> 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...)
Comment 9 Tim Waugh 2002-05-28 10:13:08 EDT
> ...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.
Comment 10 Tim Waugh 2002-05-30 11:57:53 EDT
dvilj is gone as of tetex-1.0.7-49.  Long live dvips.
Comment 11 Stas Sergeev 2003-02-17 18:50:32 EST
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...

Note You need to log in before you can comment on or make changes to this bug.