Bug 225537 - foomatic configured printer scales output down to 80%
foomatic configured printer scales output down to 80%
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: Marek Kašík
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 02:23 EST by Michal Jaegermann
Modified: 2008-05-14 12:28 EDT (History)
0 users

See Also:
Fixed In Version: system-config-printer 0.7.63.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-14 12:28:06 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)

  None (edit)
Description Michal Jaegermann 2007-01-31 02:23:53 EST
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
Comment 1 Michal Jaegermann 2007-01-31 20:02:41 EST
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".
Comment 2 Tim Waugh 2007-02-08 12:40:59 EST
I very much expect the 'fitplot' option is set in /etc/cups/lpoptions for that
printer.  Can you, or your friend, attach that file?
Comment 3 Michal Jaegermann 2007-02-08 13:46:37 EST
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.
Comment 4 Michal Jaegermann 2007-02-11 16:57:42 EST
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).
Comment 5 Tim Waugh 2007-02-12 13:54:50 EST
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?
Comment 6 Michal Jaegermann 2007-02-12 18:37:23 EST
> 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?
Comment 7 Tim Waugh 2008-01-10 07:28:47 EST
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.
Comment 8 Bug Zapper 2008-05-13 22:34:58 EDT
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
Comment 9 Marek Kašík 2008-05-14 12:08:21 EDT
Hi,
Comment 10 Marek Kašík 2008-05-14 12:28:06 EDT
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

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