Description of problem: The following LaTeX file: \documentclass{article} \newcommand{\tick}[1]{\vrule height 0pt depth #1pt} \newcommand{\ay}{\hfil\tick{2.5}\hfil\tick{2.5}\hfil\tick{2.5}\hfil\tick{2.5}} \newcommand{\ar}{\hbox to 1cm{\ay\hfil\tick{4}\ay\hfil\tick{8}}} \begin{document} \thispagestyle{empty} \vspace*{3cm} \mbox{\vbox{\hrule\hbox{\tick8\ar\ar\ar\ar\ar\ar\ar\ar\ar\ar}}} 10cm \end{document} has to print a 10 cm "rule" or printing is seriously broken. It does print that way with FC5 and FC6 installations. Why trying this, on the same printer (Samsung ML-2251N), and even the printing from the same machine hardwarewise, an output is scaled down precisely by a factor of 0.8. This happens with print files produced by a run of 'pdflatex' on the input above, or copied to rawhide from FC5 or FC6 - does not matter. I also tried different print drivers (Postscript, pxlmono, one of hpljet) and varying resolution. Does not matter. 10 centimeters becomes 8 on a printout. Adding and removing various "Job Options" also did not change anything. Version-Release number of selected component (if applicable): foomatic-3.0.2-45.fc7 How reproducible: I am trying to find a way not to reproduce and so far without success
In an attempt to figure out why cups decided to scale down my output I compared directories /etc/cups from FC6 installation, where I got what I expected, and from the test one, where I got hit by this bug. I could not find any real differences in files between the two. The only which showed up were in time-stamps. In order to recheck things I decided to deleted my printer and recreate it from scratch again. This turned out to be doable but see bug 226703. After all of this I tried to check differences again and once more they were really only in time-stamps. But wonder of wonders - after this operation my printout showed up in a proper scale. I really despise situations where some mysterious things are happening quietly behind my back. What kind of guarantee I have that the next time this whole contraption will not decide to apply a factor of 0.75, or 1.20, or anything else for that matter? I have not done anything else than yesterday when I created that print queue for the first time. Is anything I can do to prevent events of that sort? The question is far from academic. I am hearing now from a friend with an FC6 installation and a printing setup which again took on itself to print "small".
I very much expect the 'fitplot' option is set in /etc/cups/lpoptions for that printer. Can you, or your friend, attach that file?
The current version of /etc/cups/lpoptions on an installation where I observed this scaling is just empty. The previous content I happen to know as I was trying to change a size of a text printout (see bug 224645) and just copied that from an FC5 system trying to see if I can achieve desired effects. So I had there one line which read: Default lp cpi=9.2 lpi=5.5 page-bottom=36 page-left=18 page-right=18 page-top=36 wrap=true or, on another try, "Default" replaced with "Dest". No 'fitplot' anywhere I would be aware of and this includes printers.conf. I will ask about that other installation but it will take some time. I would be very surprised to find 'fitplot' anywhere there either. In any case we are printing something which obviously fits on a regular page.
I had, at last, an opportunity to go through (over a telephone) through a content of /etc/cups/ on that FC6 installation which was scaling down printouts. There were multiple lines in lpoptions, most of them for queues which do not exits anymore, and there was indeed 'fitplot=true' apparently inherited from one of these old configurations. It appears that 'system-config-printer' currently writes in /etc/cups/printers.conf only, but /etc/cups/lpoptions is still taken into a consideration thus adding to a general confusion. OTOH what shows up under "Job Options" tab of system-config-printer does not reflect a status of /etc/cups/lpoptions at all. To make that even more fun my quick experiments show that in case of conflicting values for the same option, one in /etc/cups/lpoptions and the other written by system-config-print into /etc/cups/printers.conf, the one in /etc/cups/lpoptions, hence "invisible", takes a precedence. To be sure - I ran that particular test only with 'cpi' and text files. Should this go into a separate bug report? After a general cleanup, removal of 'fitplot=true' from lpoptions, and cups restart a printer started to print without scaling Postscript and PDF down. For additional excitement produced pages were clearly fitting on output paper sheets so one would naively think that 'fitplot=true', even if present, should have no effect. Oh, well ... I still have no good explanation for a situation described in comment #1. Tests installations there were not updates from some old distros so inheriting some old 'lpoptions' does not sound like a possibility (and, AFAICT, was always empty).
The /etc/cups/lpoptions 'default options' mechanism is a client-based one. The print client, when it submits a job to a CUPS server, reads the /etc/cups/lpoptions file *on the local machine* and adds in those job options if they are not already set. In 1.2.x, CUPS introduced network default options, which is what the system-config-printer in FC-6 allows you to edit ('Job Options'), and these are stored in printers.conf *on the server*. There are valid use-cases for both mechanisms, but in general since system-config-printer is for configuring the print *server* it makes most sense for it to allow editing of the network default options. Unfortunately, wholesale migration of client default options (/etc/cups/lpoptions) to the new method of having defaults is not really an option -- any way of doing it would cause more problems than it would solve, as far as I can see. The meaning of the 'fitplot' option changed between CUPS 1.1 and CUPS 1.2 -- in 1.2 the page margins are taken into account for the purposes of fitting. That means that, although the PDF may be ready to print full-page, if there are page margins set (for text-to-PS printing), the PDF is shrunk to fit within these margins. In Fedora Core 5, the fitplot option was unfortunately one of the defaults. Knowing this situation was coming, I made an update for system-config-printer (the FC-5 version edited /etc/cups/lpoptions) to remove the fitplot option IFF all the other options were also still the original defaults. Do you have any ideas for specific remedies that can be implemented in Fedora Core 6 to make any of this better?
> In 1.2.x, CUPS introduced network default options, which is what > the system-config-printer in FC-6 allows you to edit ('Job Options'), > and these are stored in printers.conf *on the server*. In cases where a printer is a printer with a network interface (a built in or a variety of various "hardware" boxes which you can get for this purpose) there is no way to store anything *on the server" in the strict sense. Also where you have a printer connected directly to machine from which you are printing then the same one provides really both client and a server. So you are left with a situation when a "full blown" computer with printer attached provides printing services to other clients on a network (even if this "attached" really means also "attached by a network connection and not necessarily some printer cable"). Now we have an immediate question "How do I edit _client_ job options?". Personally I know how to fire 'man lp' and and editor, especially when things were spelled out to me, but an obvious assumption will be that "Job Options" in s-c-p will be the thing to use. > There are valid use-cases for both mechanisms I do not quarrel with that at all; only means and priorities need to be explicit. Actually I would _expect_ that with a modicum of sanity in case of differences client options will override network wide defaults set by a particular server. It looks from my tests that this may be actually the case although in this context I looked only at one option. > The meaning of the 'fitplot' option changed between CUPS 1.1 and CUPS 1.2 Oops! In such case I would expect at least a very clear warning on 'man lp' (of course, taking into account that this is CUPS one does not expect too much, but still ...). It appear to me that this makes 'fitplot=true' almost useless as it will screw up badly most well-formatted outputs. One would need a special print queue with specific parameters to get this option for particular jobs. Likely beyond understanding of a vast majority of users. > In Fedora Core 5, the fitplot option was unfortunately one of the defaults. Curiously enough on an FC5-x86_64 installation, which is in use right beside me, there is no 'fitplot' mentioned in any file from /etc/cups/. > Do you have any ideas for specific remedies that can be implemented > in Fedora Core 6 to make any of this better? I would imagine that making possible in s-c-p to edit 'lpoptions', quite likely in a tab different than "Job Options", while making it absolutely clear there what is for what and which is "more valid", would help a great deal. Among other things "Client Job Options" (say) should inherit, if available, all set "Job Options" and write in 'lpoptions' only those which were modified. Don't you think?
The trouble is that system-config-printer is for configuring a CUPS server, and doesn't touch any configuration files except through CUPS server operations. I think this sort of client options editor belongs more to the GTK+ print dialog. Reassigning appropriately.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hi,
Hi, I'm closing this bug. Original problem is solved in current release of system-config-printer. We will consider the other ideas from the comment #6 in future releases. Marek Kasik