Description of problem: Contrary to e.g. xdvi, ghostscript uses U.S. Letter as default paper size instead of A4. Unless "-sPAPERSIZE=a4" is specified with ps2pdf, the PDF is built in Letter format, even though the LaTeX specification uses A4. This can have potentially disastrous results if a PDF is sent to printing with the top of every page cut off, an error easily missed when looking at a document with xpdf. I've changed gs_init.ps according to http://www.cs.wisc.edu/~ghost/doc/gnu/7.05/Use.htm#Change_default_size now. However, it seems to me that the fact that this needs to be changed is a serious problem when using Red Hat/Fedora for publishing. In Debian the problem has already been solved and there's no need to change gs_init.ps. It should (IMHO) be configurable during installation, with the default set to Letter if the computer is in the U.S. or Canada, and A4 in all other cases. Debian uses /etc/papersize for this purpose. Perhaps Fedora could have a similar /etc/sysconfig/papersize, or include it in /etc/sysconfig/i18n?
I don't think we need 'papersize', since i18n already includes the locale, and the locale includes LC_PAPER information. My question is: at what stage does /etc/papersize have an effect in Debian? Is it at gs runtime?
> I don't think we need 'papersize', since i18n already includes the > locale, and the locale includes LC_PAPER information. Alright. It might be worth noting that LC_PAPER is not standardized, but that works for me. It's in the locale files at least. > My question is: at what stage does /etc/papersize have an effect in > Debian? Is it at gs runtime? Hmm. That was a little more complicated than I thought. As far as I can tell ghostscript has been patched to use the Debian-specific libpaper.so.1, which reads /etc/papersize.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
It has not been resolved in current FC3 updates.
Let's push this all the way to "devel" -- I think solving this is too sweeping in scope to be likely for the current release. Also, although this is important and I want it addressed, I think "severity high" is overstating -- it's not like you can't change the setting, or that it totally corrupts your data irreparably. Let's do our part to fight Bug Severity Inflation.
I agree. Did I really set it to "high"? Well, it was a while ago.
If this bug is still occuring, does it occur if you boot into runlevel 3 and run startx? If so, it is probably caused by bug #372151
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp