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

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
>>>>> [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

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...

-- 
cu

jth

_______________________________________________
cups mailing list
[email protected]
https://lists.cups.org/mailman/listinfo/cups