[cups] turning off fit-to-page

[Gary Dale]

On 2024-01-09 02:01, Jörg Thümmler wrote:
> Am 08.01.24 um 22:16 schrieb Gary Dale:
>> 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.
>>
>>
>> _______________________________________________
>> cups mailing list
>> cups at cups.org
>> https://lists.cups.org/mailman/listinfo/cups
>
> Hi,
>
> yes, that's maybe, why opensuse is still at 2.2.7 although OS15.5 is 
> the actual OS version. Interestingly this 2.2.7 differs from the 2.2.7 
> version I use on my old server even in behavior...
> ... so the "slow but steady" comment (which was not sent by me) is for 
> me more...
> I read of more nongood cups changes, so somewheres was spoken about 
> removing the "raw" printer "driver" ... which is highly used on my 
> system...
>
Agreed. Back in the late 80s and early 90s in MS-DOS, I used to rely on 
raw printing for my dBASE programs. The same code could sent output to 
the screen or printer. Then the bright boys behind the various Windows 
versions of dBASE decided that it should embed printer codes in the 
output - that basically killed years of work as text output was no 
longer redirectable.

Raw printing with CUPS was needed when connecting to network printers so 
that the client and server didn't both encode the output. You used to 
install printer drivers on every client when you really only needed the 
server to know how to talk to the printer. Windows used the bizarre idea 
of having the drivers installed from the server while CUPS took the more 
rational approach of sending the raw output to the network printer and 
letting it handle the driving.

If you had previously installed the network printers on your client, you 
could either remove the printer and let CUPS network discovery handle 
printing to it or you could switch the driver to "RAW".

Where this breaks down, of course, is when there is no server involved. 
This brings us to the latest evolution - ipp - where the printer is 
self-driving. No need for drivers anywhere.

Except that there are a huge number of printers out there that don't 
understand ipp. They still need drivers. The CUPS developers have 
deprecated these printers, apparently expecting that we will upgrade all 
of our old, working hardware. From the looks of it, they don't even 
bother testing CUPS against non-ipp printer anymore.