Add 8-up printing support

[Mr-Tao]

Summary

Add support for 8 logical pages per sheet (number-up=8).

• Accept and advertise 8 alongside the existing 1, 2, 4, 6, 9, and 16 values.
• Add 4x2 portrait and 2x4 landscape imposition in pstops, including every number-up-layout ordering and label handling.
• Update command-line help and user documentation.

Testing

• make -j4 all
• make -C scheduler test
• A local 16-case PostScript-to-PDF smoke test covering eight layouts in portrait and landscape; it verified one output sheet, pages 1--8, and order.
• git diff --check

The change was developed with assistance from an LLM; I reviewed the implementation and performed the tests above.

[michaelrsweet]

OK, so I appreciate the PR for this, but 8-up isn't a feature we've ever tried supporting in almost 30 years of CUPS, and isn't something I've ever seen supported on an IPP printer. Moreover, this will need to be supported in many other places, and N-up isn't widely used outside of applications that already apply it to their output...

Deferring this to CUPS future for now...

[Mr-Tao]

Thanks, understood. One practical reason I pursued this is that I have repeatedly needed 8-up printing on ISO A-series paper. The A-series aspect ratio makes a 4-by-2 layout geometrically exact on a landscape sheet.

At present I have to emulate this by first printing 4-up to an intermediate PDF and then printing that PDF 2-up to the physical printer. That works for simple jobs, but it creates a nested imposition workflow and quickly becomes cumbersome and error-prone with duplex printing.

For historical context, I found two earlier requests for the same A-series use case, apple/cups#3187 from 2009 and apple/cups#4046 from 2012. They were declined at the time because the reported demand did not justify the implementation and testing cost, so I understand why this has not been part of CUPS so far.

I also understand the concern that this should be consistent across the future printing stack. The current libcupsfilters PDF transform already has an explicit 8-up layout and documents 8 as a supported number-up value. I have also submitted the corresponding GTK 4 and GTK 3 changes; both currently pass CI.

The future libcups ipptransform implementation currently has no 8-up case. I can prepare a companion change there and an end-to-end driverless test. Would that address the cross-stack concern, or would you prefer this PR to remain deferred for now?

[Mr-Tao]

Following up on the companion work I offered, I have prepared OpenPrinting/libcups#160. It adds number-up=8 to ipptransform and includes both a direct regression test and a hardware-free end-to-end test through a virtual IPP Everywhere printer.

I have left that PR as a draft pending guidance on whether this is the cross-stack coverage you had in mind. If so, I can move it out of draft and address any preferred adjustments.