`number-up=2` applied twice on PostScript PPD queue (pdftopdf + pstops), giving 4-up output

Start by tracing the filter chain described in the report: universal → pdftopdf → ppdFilterPDFToPS (gs and pstops) → hpps. Reproduce the page counts with the supplied cupsfilter commands and inspect how number-up=2 is passed between stages. Done means the chain produces four sheets from the eight-page PDF, with two pages on each sheet.

Summary

On a queue using a PostScript PPD (HP Color LaserJet Pro M252dw, hpps filter), printing a PDF with -o number-up=2 produces 4-up output instead of 2-up. The filter chain runs both pdftopdf and pstops, and both appear to apply the N-up layout, so the effect is 2 × 2 = 4.

System Information

• Distribution: Manjaro Linux
• cups 2:2.4.19-1
• cups-filters 2.0.1-2
• libcupsfilters 2.2.1-2
• libppd 2.1.1-2
• Printer: HP Color LaserJet Pro M252dw
• PPD: /etc/cups/ppd/HP_Color_LaserJet_Pro_M252dw.ppd (shipped by the distribution)
  • *cupsFilter: "application/vnd.cups-postscript 0 hpps"
  • Model: "HP Color LaserJet Pro M252 Postscript (recommended)"

Steps to reproduce

1. Generate a simple 8-page A4 portrait test PDF (no external dependencies beyond Ghostscript):

gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sPAPERSIZE=a4 -sOutputFile=/tmp/test8.pdf \
  -c "/Helvetica findfont 72 scalefont setfont 1 1 8 { /n exch def 200 400 moveto (Page ) show n 3 string cvs show showpage } for"

2. Print it with N-up 2:

lp -d HP_Color_LaserJet_Pro_M252dw -o number-up=2 /tmp/test8.pdf

I first saw this with a real document (an 8-page page range extracted with pdftk), and it reproduces identically with the generated file, so it does not depend on the document's content.

Expected result

4 sheets, each with 2 pages.

Actual result

2 sheets, each with 4 pages.

Additional context

• -o number-up=1 prints 1-up, so the source is not already N-up.
• No number-up default is set in lpoptions, the PPD or the printer.
• Adding sides=two-sided-short-edge makes no difference; the job is 4-up with or without it.
• Pre-building the 2-up PDF (pdfjam --nup 2x1 --landscape) and printing without number-up works correctly.

Debug log excerpt (real job)

The options reach the chain intact, and the chain is universal → pdftopdf → ppdFilterPDFToPS (gs + pstops) → hpps:

argv[5]="finishings=3 number-up=2 print-color-mode=color ..."
cfFilterUniversal: Adding pdftopdf to chain
cfFilterChain: pdftopdf completed with status 0.
ppdFilterPDFToPS: Started filter gs
ppdFilterPDFToPS: Started filter pstops

Offline reproduction, no printer needed

cupsfilter and pdftopdf have to run as root here because the PPD is not readable by normal users.

sudo PPD=/etc/cups/ppd/HP_Color_LaserJet_Pro_M252dw.ppd /usr/lib/cups/filter/pdftopdf 1 me title 1 "number-up=2" /tmp/test8.pdf > /tmp/stage1.pdf
pdfinfo /tmp/stage1.pdf | grep -E 'Pages|Page size'

sudo cupsfilter -p /etc/cups/ppd/HP_Color_LaserJet_Pro_M252dw.ppd -m application/postscript -o number-up=2 /tmp/test8.pdf > /tmp/full.ps
ps2pdf /tmp/full.ps /tmp/full.pdf && pdfinfo /tmp/full.pdf | grep Pages

Results:

Stage	Input pages	Output pages
pdftopdf alone	8	4 (A4 portrait, correct 2-up)
ppdFilterPSToPS (inside ppdFilterPDFToPS)	%%Pages: 4	"Wrote 2 pages"
Whole chain (ps2pdf of full.ps)	8	2

Relevant cupsfilter debug lines:

cfFilterUniversal: Adding pdftopdf to chain
ppdFilterPDFToPS: Running command line for gs: gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=%stderr -sDEVICE=ps2write ... -r600 ... -f /tmp/...
ppdFilterPSToPS: %%Pages: 4
ppdFilterPSToPS: Wrote 2 pages...

Analysis

pdftopdf correctly produces 4 sheets from 8 pages. pstops then receives that 4-page PostScript and combines it again into 2 sheets. The pstops debug output does not log number-up explicitly, so this conclusion rests on the page counts (4 in, 2 out) and on the fact that number-up=1 does not trigger it.

It looks like N-up should be handled by only one of the two stages when universal inserts pdftopdf ahead of ppdFilterPDFToPS. For example, pdftopdf could consume the option and strip it from the options passed on, or pstops could skip its layout when an earlier stage already did it.

I am not sure which component is at fault (libppd, libcupsfilters, or the way the filter chain is assembled). Please move the issue if it belongs elsewhere.

Workarounds

• Pre-generate the 2-up PDF and print without number-up:
  cat /tmp/test8.pdf | pdfjam --nup 2x1 --landscape --outfile /dev/stdout /dev/stdin | lp -o sides=two-sided-short-edge
• Use a driverless IPP queue (lpadmin -m everywhere), which has no pstops stage.