please provide an option to make lp handle "page-ranges" before "number-up"

[archenemies]

See #3008, #4837. @michaelrsweet: I noticed that you still haven't replied on #3008, and your explanation for closing #4837 was a bit terse. I'm not sure if I should take these as signs of annoyance or irritation. I hope not, because my goal is not to irritate but to contribute to this useful software by providing some helpful observations.

I estimate that CUPS is used by tens of millions of people. The most common command-line options I pass to CUPS are "-o page-ranges" (or "-P") and "-o number-up". I often use these together, if I'm trying to save paper. I think that many people must be in a similar situation. Thus, getting these options to interact properly is a goal to which we could attach some importance.

Currently, we can summarize the behavior of CUPS by saying that number-up is processed before page-ranges, i.e. that the numbers given in page-ranges are taken to count "impressions" (in the language of RFC 2911) - consisting of pairs or quadruplets of document pages, e.g. when number-up=2 or number-up=4 - rather than document pages. So if I specify -o page-ranges=5-10 -o number-up=2 then CUPS will print document pages 9-20, rather than 5-10.

However,

• I find that it would be more useful to specify document input pages, not "impressions", in page-ranges
• Sanjoy Mahajan found this to be the more obvious usage, in 2008, according to #4837
• Friends I ask respond that this is more correct
• Although you haven't replied to me on #3008, apparently RFC 2911 agrees with us that page-ranges should refer to document pages

Not only is it painful for users to have to recalculate which document pages they should specify based on the argument to number-up, but it is not currently possible to achieve the correct page-layout behavior by changing arguments to lp. For instance, it is not possible to start printing on an even document page, or to print an odd number of pages, if -o number-up=2 is specified. For -o number-up=4, the situation is worse.

I don't know if your opinion to the following can be inferred from your closure of #4837, but it seems to me that lp should provide an option to make -o page-ranges refer to actual document pages. Providing such an option would not break backwards-compatibility with existing usage of CUPS, and it would help users by providing them with a more functional and intuitive interface to use when telling CUPS which pages to print.

I would call the option something like -o paginate-first.

[michaelrsweet]

We cannot change something like this without breaking a lot of software.

We cannot add an option without requiring a lot of support software (outside of cups) to change, which means inconsistent user experience for an extended period of time.

And quite frankly this is simply not a high priority for us, Combining number-up and page-ranges is not a common use case, and we made the decision on this 18 years ago.

I am not frustrated. I am just telling you that, based on the interpretation of the order of processing back in the IPP/1.0 definition days (1998) and what was seen as most useful at the time, CUPS does number up before page ranges. And that is not going to change now.

[archenemies]

We cannot add an option without requiring a lot of support software (outside of cups) to change, which means inconsistent user experience for an extended period of time.

Can you elaborate on that?

[michaelrsweet]

The following "standard" filters process number-up and page-ranges:

pstops (CUPS)
pdftopdf (cups-filters)
cgpdftopdf (macOS)

plus several hundred printer drivers for mid-to-high end laser printers/MFPs that do their own page filtering and imposition.

We might be able to coordinate changes to the standard filters, but we wouldn't be able to get all of the drivers updated.

For some background, we've instrumented prior macOS releases to determine which options are used the most for printing. In the general (anonymized) reporting data of over 1 million users that opted into it, 75% of all printing is to a PDF file (save as PDF) with no options. Of the remaining 25% of print jobs, approximately 1% uses the copies option, maybe 0.5% used the page-ranges option, and less than 0.000001% (1 in 100 million) jobs used the number-up option. (unfortunately we don't have information on the numbers of jobs submitted with both page-ranges and number-up, but the upper bound will be 1 in 100 million print jobs...)

So in the grand scheme of things, we do not see the "number-up" option as being particularly important, and cannot justify the disruption and resources needed to support two different filtering modes for the edge case where page-ranges and number-up are used together. I know this is probably not the answer you are looking for, but that is the reality of the situation.

(For additional reference, IPP Everywhere, Wi-Fi Direct Print Services, and AirPrint do not require support for number-up because it was not need as critical for printing. Copies and page-ranges are, however, required for PDF printers...)

[archenemies]

Well, thank you Michael for the very thorough response. I think it's great that Apple collected those statistics. You have very strong arguments.

I wonder how different the statistics are on Linux. Perhaps the usage of number-up is small but not so extremely small.

Also, it strikes me that new preprocessing functionality could simply trigger an invocation of pstops or pdftopdf before a printer-specific filter is invoked, as necessary if a new option is being used. But I imagine this would be somewhat messy.

You know more about the CUPS architecture (and your development resources) than I do.