From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12 i686)
Description of problem:
When running latex on relatively simple latex files, the resulting (Roswell
2) PostScript file resulting from running dvips -Ppdf on
the file is shifted down on the page about half an inch vs. RedHat 7.1. I
also tried GhostScript 7.0 from the GhostScript site and the
problem still occurs. I will provide the latex file I have if it you
think it might be unique to my file or do not want to bother with
your own latex file. email: firstname.lastname@example.org
On both the 7.1 and roswell, I have changed the file:
so that the one line reads:
The problem could be with ghostscript, but the dvi files
differ on the two systems so I'm not certain.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. latex file.tex
2. dvips -Ppdf file -o
3. view the PostScript file and compare it to the same one on RedHat 7.1
Yes, please attach a small file, so that we know we're looking at the same
Could you also attach the output of 'zcat
Created attachment 28874 [details]
Created attachment 28875 [details]
Created attachment 28876 [details]
We (Red Hat) should really try to fix this before next release.
I think the change is introduced by the time the DVI is created.
On a 7.1 system, a Roswell-produced DVI is converted to PS containing
%%BoundingBox: 0 0 612 792
On a Roswell system, a 7.1-produced DVI is converted to PS containing
%%BoundingBox: 0 0 596 842
This is the same as doing the whole lot on a 7.1 system.
The main change between 7.1 and Roswell in the tetex package is to use a newer
set of LaTeX macros. Perhaps that's where the change has come from.
Interestingly enough, when these PS files are loaded into Ghostscript
(Roswell), the Roswell-produced PS file is shown as 'Letter', while the
7.1-produced PS file is shown as 'BBox'.
Also, gimp (again, on Roswell) shows the Roswell-produced PS to be 11"x8.5",
while the 7.1-produced PS is 8.28"x11.7".
Could it be that the change is in fact a feature rather than a bug? ;-)
It could be a "new feature"; if so, could you please let me know what changes
were made to the Latex macros (or where you got them). We just installed
Latex on a Sparc Solaris system at work about a week ago and it works the same
as RedHat 7.1. This is going to be really annoying if I have to edit the file
everytime I try to print at work vs. home :-(
The updated LaTeX macros came from the Mandrake package (from Guiseppe Ghibr's
Ok, I am willing to admit that the RedHat 7.1 Latex and Solaris Latex are
wrong. Page 85 of the "Latex Companion" by Goossens et al. shows the
page layout and what the margins, etc. set with \setmarginsrb mean. Even
though I requested a top margin of 1 inch, the printout from 7.1 and Solaris
have a margin of less than inch. I'll check the roswell page printout tonight
to see if it appears correct. Looks like I'll have to get Latex compiled for
Solaris from the texmf-gg source archive :-(
Okay, I spoke to Guiseppe about this, and he thinks that it's probably a paper
size bug in the dvips configuration. I'll take a closer look at it, and try
things like 'dvips -t a4' to see if that makes things better.
After measuring the output of the roswell PostScript file and looking at the
Latex Companion, I think the 7.1 output (and the binary Solaris files that
were installed at work) are wrong and that roswell is correct. I'd really
like to know how to make 7.1 produce the same output as roswell so I can
try the same thing on the Solaris machine.
I tried switching from the Latex macro:
and using: dvips -t letter
Then both the RedHat 7.1 system and the Roswell system produce PostScript that
look the same. Unfortunately, trying to print the PostScript file from the 7.1
system hangs the printer. Printing the PostScript file generated on the 7.1
system (or the roswell system) from the roswell system to the HP LaserJet 1100
(connected to the 7.1 system) works fine. This appears to be the 7.1 bug that
has not been fixed yet:
I believe a member of our local Linux User Group (colug) who has contacts at
RedHat talked to someone and they tracked it down to manually processing
the PostScript file for printing vs. letting the filter do it (it worked
when manually processing the filters).
Which roswell src.rpm would I try to rebuild on the 7.1 system? I'm guessing:
I guess, from the sound of it.
Marking this bug closed.
Actually, it's not LPRng (since I recompiled the src RPM on my 7.1 system.
It's somewhere in the printconf RPMS and it's dependencies. There were too
many RPMS that needed updated to install the roswell printconf on a 7.1 system.
Yes, I agree that this bug should be closed for roswell. The 7.1 bug
still exists, although upgrading to RedHat 7.2 whenever it comes out
will solve it.