print a4 documents sensibly by default on command-line about cups-filters HOT 10 CLOSED

Here's another example, it prints fine from Evince or Okular, but crashes my printer when I try to print it with 'lp':

el-cerrito.pdf

(it comes from openstreetmap)

from cups-filters.

I just discovered that there is already an option to 'lp' called 'fit-to-page', which makes at least the first example PDF print acceptably. (Does anyone read these issues?)

It's a pity that '-o fit-to-page' is not the default. Most users have to deal with a mix of A4 and letter documents, and it is difficult to tell which is which just by bringing it up in a PDF viewer. Should everyone with a letter printer have to remember to check whether a document is A4 before passing it to lp, and if so then specify '-o fit-to-page' manually? It would make so much more sense just to have this as the default.

On the other hand, I checked that passing "-o fit-to-page" when letter-printing a PDF document with letter-sized pages causes the whole page to shrink slightly. This is problematic when you are e.g. duplex-printing flashcards and need the front and back to line up; or if you are printing something where exact measurements are important. Not to mention that we would like to respect the margins set by the document.

Evince in fact gives the same output as normal 'lp' when you select "Page Handling > Page Scaling > None" in the Print dialog.

So I am renaming this to "print a4 documents sensibly by default on command-line" since I think that is a better summary of the problem.

It might be nice to see a default option like 'fit-to-page=ask' where if the document size is more than 1% different from the printer page size, and 'lp' is running on the terminal, then it will prompt the user for what to do...

from cups-filters.

In issue #65 and pull request #92 we are working on the scaling, especially adding a new scaling option crop-to-fit. This one would do the right thing if you want to print A4 on Letter paper or vice-versa.
Note that we do not set any of the options by default, so that if one has a document which intendedly has pages with different sizes (book with some fold-out image pages, letter with its envelope) it gets correctly printed on a printer with all the requested sizes loaded in different trays or when one loads the required special size into the manual tray when the printer asks for it.
I will merge the mentioned pull request soon. Please test if it fulfills your needs and comment in Issue #65.

from cups-filters.

I think this may have been closed prematurely.... anyway it's not a big deal, maybe the best thing is for me to use a wrapper script to 'lp' which checks if the input is PDF and if so, whether it is the same dimensions as the printer paper, and if not, queries me. Or to make fit-to-page=true the default, and just remember to pass "-o fit-to-page=false" in cases where I need accuracy. As you point out there are difficult cases, letter-with-envelope documents and so on.

If you wanted to do something for A4 - maybe cropping works for most document margins, it seems to me that fit-to-page would be more sound. However, the important thing about my (evolving) feature request is I think to have a way of configuring default options which does nothing when the input pages are the same size as the printer page, and only scales or crops when this is not the case. Alternatively, a version of fit-to-page which has this idempotency property without any matching of dimensions - in other words, which doesn't insert extra margins when it is asked to fit a letter PDF on letter paper. Then I could make fit-to-page=true the default, without having to worry about turning it off when I need fidelity to document dimensions. I think it would make sense for 'lp -o fit-to-page' to insert margins when I give it a PNG, but not a PDF. Or some option to enable this behavior. I notice that printing to -dVirtual_PDF_Printer -o fit-to-page does not add margins, but when I print to my laser printer, margins get added, as I have noticed by looking at the physical pages. If I were to print something, scan it, print it again, etc. with '-o fit-to-page' turned on, then it would gradually shrink to nothing. That's what I mean by not being idempotent.

from cups-filters.

I did not close this prematurely, I simply linked your report to ongoing work on new scaling options which is discussed in issue #65. The setting you will need is crop-to-fit which centers the content and then crops away at the border what exceeds the destination paper size. With this as default you can for example print Letter-sized documents on A4 without the content getting shrinked.

from cups-filters.

The setting you will need is crop-to-fit

I understand that, as I think I expressed in the first sentence of the second paragraph, where I noted that the document margins may not be compatible with cropping. The rest of the second paragraph talks about some other alternatives which I thought would be better.

I would be happy to test your changes except that the last time I tried to test changes at your request (#67) I ran into a build problem, asked for help, and never received a reply. I'd love to be able to help out productively, in other words, but it looks like I am lacking the ability to do so without overwhelming your bandwidth.

from cups-filters.

Your problem is solved now, by pull request #92 which I have merged now. After updating your cups-filters to the current repository snapshot (or to the upcoming 1.22.2 release) you can print with the options "-o crop-to-fit" to get the desired results.

from cups-filters.

@tillkamppeter - I don't see any indication that you read what I wrote. However, I understand that you added a new feature which may be useful to some people.

from cups-filters.

As crop-to-fit does not scale it is idempotent, applying it twice will lead to the same result. If the input page is A4 and it is a usual document, scanned, and the output page is A4, too. You get it printed in original size and then usually the content falls into the printable area of the printer, and any black strips at the border which occur when scanning usually fall out of the printable area. crop-to-fit does not crop off anything from the input page if the output page is the same size. Naturally the printable area/unprintable margins of the output page apply and there we cannot do anything.
We cannot do anything where it is automatically detected what of the page content is actual content (text, drawings, ...) and what is scanning artifacts to optimize the scaling for the actual content.
So I hoped that having the two choices, one being the fit-to-page to scale the whole input page into the output page's printable area to guarantee not losing any content and the crop-to-fit to conserve the size of the document but center it into a slightly differently sized output page size would cover all needs.
We also cannot add options to the filters which make CUPS ask the user what he wants to do after he has sent the job. The architecture of CUPS does not permit this.

from cups-filters.

Thank you for the explanation and for your work on this.

I think if I had done it, I would have gone for an idempotent (or rather "preserving the scale of already correctly-sized-input", and therefore "usable as a default") version of fit-to-page, since instead of just working OK for most A4->letter documents, that would also produce sensible results for the two example documents I provided in this issue.

However, I will try what you implemented when I figure out how, or when the Arch repos get updated.

Please let me know if you have any questions about what I am saying.

By the way I understand the various limitations of the system design which you described. I have heard "Boomaga" is good for more interactive printing flow, but haven't tried it yet.

from cups-filters.