↓ Salta al contenuto principale
❯ lineadicomando.it

CUPS: stampante laser che stampa pagine nere, il driver sbagliato

·932 parole·5 minuti
How-To Cups Ricoh Postscript Gutenprint Fedora
❯ lineadicomando.it
Autore
❯ lineadicomando.it
Specs, Bugs and Log Console

Contesto essenziale
#

Una Ricoh Aficio AP610N di rete, laser monocromatica, stampava ogni documento come una pagina quasi interamente nera. La stampante era sana. In CUPS la coda era stata creata con il driver Gutenprint della Ricoh Aficio 3260C, una multifunzione a colori con cui condivide solo il nome commerciale.

Il filtro rastertogutenprint produceva un raster PCL a colori che la AP610N non sa interpretare. Il risultato era toner steso su tutto il foglio.

Il caso è su Fedora 44 con CUPS 2.4, ma la procedura vale per qualsiasi stampante a cui CUPS abbia assegnato il modello sbagliato, cosa che succede facilmente quando la coda viene creata in automatico o si sceglie il driver dall’elenco per somiglianza del nome.

Prerequisiti
#

  • Accesso sudo (i PPD in /etc/cups/ppd/ sono leggibili solo da root)
  • avahi-browse per interrogare la stampante via mDNS

Installazione rapida
#

Fedora / RHEL
# 

sudo dnf install avahi-tools

Debian/Ubuntu
# 

sudo apt install avahi-utils

Arch Linux
# 

sudo pacman -S avahi

Procedura passo-passo
#

1. Identificare la coda e il dispositivo
# 

lpstat -v -p

Output nel caso reale:

dispositivo per Aficio-AP610N: dnssd://RICOH%20Aficio%20AP610N._pdl-datastream._tcp.local/
la stampante Aficio-AP610N è inattiva.  è stata abilitata da mer 14 ott 2026, 09:16:23

Il backend _pdl-datastream indica una connessione raw sulla porta 9100: la stampante riceve i byte così come escono dal filtro, senza alcuna negoziazione del formato.

2. Controllare quale driver usa la coda
# 

lpoptions -p <stampante> | grep -o "printer-make-and-model='[^']*'"

Per i dettagli serve leggere il PPD:

sudo grep -E 'NickName|ModelName|cupsFilter|ColorDevice' /etc/cups/ppd/<stampante>.ppd

Output nel caso reale:

*ModelName:     "Ricoh Aficio 3260C"
*NickName:      "Ricoh Aficio 3260C - CUPS+Gutenprint v5.3.5 Simplified"
*ColorDevice:	True
*cupsFilter:	"application/vnd.cups-raster 100 rastertogutenprint.5.3"

Il modello non corrisponde e il PPD dichiara un dispositivo a colori. Il problema è già evidente a questo punto.

3. Chiedere alla stampante cosa sa fare
#

Le stampanti di rete annunciano via mDNS il proprio modello e i linguaggi supportati:

avahi-browse -rtp _pdl-datastream._tcp | grep '^='

Campi rilevanti dell’output reale (riga accorciata):

=;wlp0s20f3;IPv4;RICOH\032Aficio\032AP610N;_pdl-datastream._tcp;local;RNPEA7E8F.local;10.100.70.96;9100;
... "Color=F" ... "ty=RICOH Aficio AP610N" "product=(RICOH Aficio AP610N PS3)" "pdl=application/postscript" ...

Tre informazioni utili:

  • Color=F: stampante monocromatica
  • product=(... PS3): interprete PostScript 3 integrato
  • pdl=application/postscript: il formato che accetta direttamente

Se la stampante annuncia anche il servizio _ipp._tcp conviene la strada driverless (vedi Note operative). La AP610N non lo fa.

4. Cercare un driver adatto
# 

lpinfo -m | grep -iE '<modello>|generic.*(postscript|pcl)'

Per la AP610N non esiste un PPD specifico tra quelli installati. Ce ne sono due generici, forniti dal pacchetto cups stesso:

drv:///sample.drv/generic.ppd Generic PostScript Printer
drv:///sample.drv/generpcl.ppd Generic PCL Laser Printer

Con una stampante PostScript la scelta è il primo: CUPS le invia PostScript e il rendering lo fa il suo interprete.

5. Salvare il PPD attuale
# 

sudo cp /etc/cups/ppd/<stampante>.ppd /etc/cups/ppd/<stampante>.ppd.bak

6. Cambiare driver alla coda
# 

sudo lpadmin -p <stampante> -m drv:///sample.drv/generic.ppd \
  -o PageSize=A4 -o print-color-mode-default=monochrome

lpadmin mantiene il nome della coda e l’URI del dispositivo, quindi non serve riconfigurare i client che stampano su quella coda.

Il comando mostra questo avviso:

lpadmin: I driver della stampante sono deprecati e smetteranno di funzionare in future versioni di CUPS.

È atteso: riguarda tutti i PPD e non blocca nulla in CUPS 2.4.

7. Verificare e stampare una pagina di prova
# 

lpoptions -p <stampante> | grep -o "printer-make-and-model='[^']*'"
lp -d <stampante> /usr/share/cups/data/testprint

Seguire il job nel journal:

journalctl -u cups --since "-2min" --no-pager | tail

Una riga con total 1 indica che il job è stato consegnato. Il controllo vero resta il foglio: devono uscire riquadri, testo e scala di grigi leggibili.

Errori comuni
#

  • La pagina è nera o piena di righe orizzontali Driver di un modello diverso, spesso a colori o di un altro linguaggio (PCL raster inviato a una stampante che si aspetta altro). Ripetere i passi 2 e 3 e confrontare ModelName con il campo ty annunciato via mDNS

  • Escono decine di pagine piene di codice PostScript in chiaro La stampante non ha l’interprete PostScript (su molti modelli Ricoh è un modulo opzionale) e stampa il sorgente come testo. Usare generpcl.ppd al posto di generic.ppd

  • grep sul PPD restituisce Permission denied In /etc/cups/ppd/ i file sono leggibili solo da root: anteporre sudo

  • avahi-browse non mostra la stampante Il traffico mDNS è bloccato dal firewall locale o la stampante si trova su un’altra sottorete. Su Fedora: sudo firewall-cmd --list-services deve includere mdns

  • La pagina di prova esce corretta ma i PDF no Controllare che il lavoro non venga stampato con un’altra coda: lpstat -d mostra la destinazione predefinita, che spesso non è quella appena corretta

Note operative
#

  • Prima di cambiare driver, conviene sempre provare la strada driverless se la stampante annuncia IPP (avahi-browse -rt _ipp._tcp). In quel caso -m everywhere evita del tutto i PPD: è il metodo che CUPS considera il futuro. Il caso di una HP DeskJet è descritto in questo post
  • generic.ppd dichiara ColorDevice: True. Su una stampante monocromatica non crea problemi, perché la conversione in grigi la fa l’interprete PostScript. L’opzione print-color-mode-default=monochrome serve solo a far proporre il bianco e nero nelle finestre di stampa
  • Il PPD generico non conosce cassetti, fronte-retro e opzioni hardware della stampante. Se servono, cercare il PPD del produttore: Ricoh distribuisce i propri PPD PostScript per Linux, e alcune distribuzioni li impacchettano (su Debian/Ubuntu openprinting-ppds). Su Fedora 44 nei repository ufficiali non c’è un pacchetto equivalente
  • Per tornare al driver precedente basta ripristinare la copia e riavviare CUPS:
sudo cp /etc/cups/ppd/<stampante>.ppd.bak /etc/cups/ppd/<stampante>.ppd
sudo systemctl restart cups

Riferimenti
#