Re: [cups] turning off fit-to-page

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
>>>> [email protected]
>>>> 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
[email protected]
https://lists.cups.org/mailman/listinfo/cups