Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,778 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
1.8k
Forks
352
Merge medio
2 d 5 h
PR fusionados (30 d)
14

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenPrinting/cups

Todos los issues de OpenPrinting/cups

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.