Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#93 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
c
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
C
Estrelas
5
Forks
31
Merge médio
6d 10h
PRs com merge (30d)
1

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de OpenPrinting/libppd

Todas as issues de OpenPrinting/libppd

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.