Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#93 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
c
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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"
  1. 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.
Vorherrschende Sprache
C
Sterne
5
Forks
31
Ø Merge
6 T. 10 Std.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus OpenPrinting/libppd

Alle Issues in OpenPrinting/libppd

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.