[cups] turning off fit-to-page
Jörg Thümmler
listen at vordruckleitverlag.de
Mon Jan 8 23:01:50 PST 2024
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...
--
cu
jth
More information about the cups
mailing list