Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`lp` (and other libcups clients) send `print-color-mode=<default>` alongside `ColorModel=Gray`, defeating the b0f1a00 "Don't override ColorModel" fix

Aperta
  • Qualcosa non va?
#1,778 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
backend

Direzione di ricerca

Start in systemv/lp.c at the destination option merge described near lines 150 and 574, then trace how cups/dest.c maps print-color-mode-default into print-color-mode. Reproduce with the held-job lp command and inspect Get-Job-Attributes; done means -o ColorModel=Gray no longer results in a conflicting default print-color-mode=color. The issue leaves the choice between client-side and server-side handling open.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary. Since 2.4.1, libcups turns print-color-mode-default into a destination option. lp merges destination options into the job by exact option name only. So a job with -o ColorModel=Gray is sent with print-color-mode=color (the queue default) as well, and downstream print-color-mode wins. The job prints in color.

The server-side fix for this, b0f1a00 (#417, "Don't override color settings from print dialog"), skips print-color-mode in apply_printer_defaults() when the job has ColorModel. But here the attribute arrives in the request itself, so the fix never applies.

Versions: CUPS 2.4.7 (Ubuntu noble, 2.4.7-1.2ubuntu7.14). The relevant code is unchanged on master and 2.4.x today. The queue is IPP Everywhere / cups-browsed with a PPD that has *DefaultColorModel: RGB, so print-color-mode-default=color.

Repro (held jobs, no paper needed). pj.test:

{ OPERATION Print-Job
  GROUP operation-attributes-tag
  ATTR charset attributes-charset utf-8
  ATTR naturalLanguage attributes-natural-language en
  ATTR uri printer-uri $uri
  ATTR name requesting-user-name $user
  ATTR mimeMediaType document-format text/plain
  GROUP job-attributes-tag
  ATTR keyword job-hold-until indefinite
  ATTR name ColorModel Gray
  FILE $filename
  EXPECT job-id OF-TYPE integer
}

The job attributes were read with ipptool's Get-Job-Attributes (requested-attributes all). Cancel the held jobs afterwards.

# 1. Raw IPP, ColorModel only: the server adds nothing (b0f1a00 works)
ipptool -tv -f t.txt ipp://localhost/printers/QUEUE pj.test
#   Get-Job-Attributes:  ColorModel = Gray        (no print-color-mode)

# 2. lp, same option
lp -d QUEUE -o job-hold-until=indefinite -o ColorModel=Gray t.txt
#   Get-Job-Attributes:  ColorModel = Gray
#                        print-color-mode (keyword) = color

strace of lp shows print-color-mode=color in the Print-Job request, so the client adds it.

Where:

  • cups/dest.c, cups_get_dests(): requests printer-defaults and converts every *-default attribute into an option (print-color-mode-default → print-color-mode).
  • systemv/lp.c (~line 150 and ~line 574 on 2.4.x): if (cupsGetOption(dest->options[j].name, ...) == NULL) cupsAddOption(...). This only checks the same name, not the related legacy option.

Google Chrome jobs from the Black & White setting show the same pair (ColorModel=Gray, print-color-mode=color, the latter as nameWithoutLanguage). So other clients that merge destination options are probably affected too.

Expected. When the job sets ColorModel, the client should not add the default print-color-mode. Or the server should convert ColorModel and let it win when both are present. Either would match the intent of b0f1a00 / #451.

Possible fixes:

  • Skip print-color-mode when merging destination options if ColorModel is set (in lp and in cupsCreateDestJob-style helpers).
  • Or have cupsd treat an explicit ColorModel as authoritative over print-color-mode. This is trickier, because a client could legitimately send both.

Related: #421, #1281 (the monochrome-default variants), #1364 ("adding the print-color-mode attribute to each job"), #1714 (closed PR on the same precedence question).

AI Disclosure: Claude wrote this for me after we spent an hour or so getting black & white printing working for me. One of several issues that made it hard to puzzle out.

Lingua principale
C
Stelle
1.8k
Fork
352
Merge medio
2g 5h
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenPrinting/cups

Tutte le issue di OpenPrinting/cups

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.