[cups] turning off fit-to-page
Gary Dale
gary at extremeground.com
Mon Jan 8 13:16:51 PST 2024
On 2024-01-08 07:25, Jörg Thümmler wrote:
> Am 07.01.24 um 02:23 schrieb Gary Dale:
>> On 2024-01-05 04:59, Jörg Thümmler wrote:
>>> Am 04.01.24 um 15:32 schrieb Gary Dale:
>>>> I'm running Debian/Bookworm on an AMD64 server. I'm usually trying
>>>> to print to a HP CP1215 colour laser printer.
>>>>
>>>> CUPS has been a nightmare for the past year, but I get around it a
>>>> little by printing from the command line. My workstation can't seem
>>>> to print to the server's printers anymore so I have been working
>>>> around it by creating a PDF or image file and using lp to print
>>>> from the server.
>>>>
>>>> However this doesn't work when I have a document that extends into
>>>> the printer margins. Then lp shrinks the document to fit the
>>>> margins, which is not what I want. I want the printer to crop at
>>>> the margins so I get as much of the document as the printer allows
>>>> without any alterations and without having to create a separate
>>>> document for each printer I might use.
>>>>
>>>> This brought me to the barely documented option "fit-to-page" which
>>>> (apparently) is turned on by default so that iOS users can air
>>>> print their photos. I supposedly should be able to override this by
>>>> setting fit-to-page=off. I supposed to be able to do this using the
>>>> lpoptions command or specifying it on the lp command using "-o
>>>> fit-to-page=off".
>>>>
>>>> Neither worked.
>>>>
>>>> If I use lpoptions as either my regular user or as root, it has no
>>>> impact - using loptions -p <queue name> -o fit-to-page=off or
>>>> omitting the -p <queue name> - all 4 variants fail. However I did
>>>> note some odd behaviour setting the lpoptions. When I list the
>>>> options, fit-to-page never shows. However if I look at the
>>>> lpoptions file, the global one only contains the default queue name
>>>> while the local user one appends "fit-to-page-off=true" to the
>>>> default line.
>>>>
>>>> If I put the -o fit-to-page=off in the lp command, the jpeg file
>>>> ends up printing over 4 pages, with about 1/4 of the image centred
>>>> on each page - possibly full size but not what I expected or wanted
>>>> or can use.
>>>>
>>>> I will also note that running "lpoptions -l" never shows the
>>>> "fit-to-page" setting but it does confirm that my default paper
>>>> size is "letter". Nor is there a "fit to page" setting through the
>>>> CUPS printer management page (<servername>:631). However, I used to
>>>> print unscaled documents to this printer (just not through Gwenview
>>>> which doesn't have a print full size & crop option, which was why I
>>>> originally started trying to use lp).
>>>>
>>>> Is there a way I can get this to work?
>>>>
>>>> _______________________________________________
>>>> cups mailing list
>>>> cups at cups.org
>>>> https://lists.cups.org/mailman/listinfo/cups
>>>
>>> Hi
>>>
>>> what kind of printer you are printing on? I assume only ps and pdf
>>> printers will understand this (to me until now unknown) option.
>>> On the other hand it's possible only special content, as pdf, may be
>>> printed using this option succsessfully.
>>> I would install a pdf output printer and test the effect of the
>>> option in the outputted pdf.
>>>
>> It's an under-documented option but graphical programs have for
>> decades offered the option of fit-to-page (scaling up or down), crop,
>> or even tile across multiple pages.
>>
>
> Hi again,
>
> I'm not sure these graphical programs used any cups page fitting,
> tiling ... whatever machanism. I believe, they simply produced
> postscript pages for output and it is not that complicated to make a
> scaling, tiling, cropping on them afterwards. I'm using ps programming
> myself sometimes and even for me as a beginner this is no magic. So
> they simply sended the correct generated pages to the printer and cups
> just putted out, I assume.
>
>> Clearly lp understands its own options. What is bizarre is that it
>> doesn't act on them properly. Again, setting the printer option
>> globally results in no modification to the global lpoptions file
>> while setting the option for a regular use does modify their
>> lpoptions file. This is not how the lpotions command is supposed to
>> work.
>>
>> Moreover, the option seems to be ignored except when it is specified
>> on the command line. Again, the lp command should be taking direction
>> from the global file, the local user file and the command line but
>> doesn't seem to be.
>
> I tested then on my good old running opensuse server (11.4, kernel
> 4.12.14) with cups 2.2.7:
> I had no "/etc/cups/lpoptions" file at all until testing your command.
> But when I tested, it worked as expected:
> lpoptions -p lp -o fit-to-page=off
> generated a /etc/cups/lpotions file with
> "Default lp fit-to-page=off" as the only line (lp is my default
> printer), interesting was, giving the "lpotions" command for any other
> printer ended in 2 lines in the created lpoptins file:
> default lp
> <printer> fit-to-page=off
> ...
> but anyway, it worked: sending an a3 pdf to the a4 printer ("lpr -Plp
> a3.pdf")
> ended in printing the a3 image unscaled, so only partially on one a4
> sheet.
> with "lpoptions -p lp -o fit-to-page=on" the lpoptions file was
> changed to on and next lpr command gave a downscaled page with the
> full image on one sheet.
> Deleting the lpoptions file (and restarting cups to be sure this is
> registered by cups) lead the result of "fit-to-page=off" - unscaled
> and not fitting image.
>
> then I tested the same on my new test install (opensuse 15.5, kernel
> 5.14.21-150500.55.39-default) cups is 2.2.7 as well but seems to be
> builded last in september 2023 and wow: it's the same as on your
> debian, but vice versa - no fitting into page, not over lpoptions nor
> with option in the lpr command!
>
> Then I added a new printer here ... a HP 401dne driverless over port
> 9100. After that I found in the dir /etc/cups/ppd a ppd file called
> like the printer: Test.ppd And now:
>
> lpr -PTest -o fitplot a3.pdf scaled the page, other options, -o mirror
> mirrored the page ... without any options - unscaled and cropped.
>
> So, what I think is - the formatting options need a ppd-file. If you
> copy your printers from last install the maybe don't have, because you
> didn't copy them; maybe the content isn't compatible as well. Newer
> cups generates one (even for "driverless" printers) so every new
> installed printer should have one and this ppd is the base for usage
> of options in lpr or lpotions command. There are defined the default
> pagesize, the other page sizes, resolutions etc.
> Maybe it's a good idea to look for this ppd, if not existing, try to
> add a new printer for your device and check the values in the file;
> they shall fit for your printer...
> ...
>
> When a
>> company makes a durable printer, it shouldn't be made obsolete
>> because someone thinks it will simplify their programming to insist
>> that we use a standard they don't support.
>>
>> If lp defaults to fit-to-page to make it easier for AirPrint users,
>> the option to turn that off should also work.
>>
>>
>
> fully agree with this!
>
> regards
>
That explains why your testing produced different results from mine. You
are running antique versions of CUPS that work, while I am running a
more up-to-date version. Debian/Stable (12) brought me CUPS v2.4.2 while
my Debian/Testing (13) workstation is running CUPS v2.4.7.
As I reported, I wasn't having these issues with the Debian/Buster (10)
(now oldoldstable) CUPS server but after upgrading to Bullseye (11) in
late 2021, printing became problematic. Bookworm (12), which I upgraded
to in late 2023, made things worse as printer classes stopped working. I
mainly use printer classes on my laptop but that laptop requires
Bookworm (12) to run properly.
Printer classes still worked on Bullseye (11). I know that because I was
using the same printers back then with my laptop limping along with a
Bullseye install. However I was able to get it really working when I did
a clean install from a release-candidate Bookworm (12) installer. It was
s few months later that I discovered the problem with print classes.
I agree with your slow but steady comment but Debian/Stable has
generally been just that - stable. These CUPS issues are a disturbing
anomaly.
More information about the cups
mailing list