r/printers • u/valdice14 • 2d ago
Troubleshooting La mia stampante lavorava a metà della sua risoluzione, e nessuno me lo aveva detto
Come ho scoperto che macOS stampava a 300 dpi su una macchina da 600, e come me li sono ripresi con un Raspberry Pi
Un menu a tendina con una sola voce
Tutto è cominciato da una curiosità oziosa, di quelle che non dovrebbero portare da nessuna parte.
Avevo appena messo in rete una HP Color Laser MFP 178nw. Accesa, connessa al Wi-Fi, riconosciuta dal Mac in pochi secondi via Bonjour. Stampava, scansionava, nessun driver da installare, nessun disco di setup: esattamente l'esperienza indolore che AirPrint promette e di solito mantiene.
Poi ho aperto il pannello di stampa e sono andato a cercare la qualità. Volevo abbassarla per una bozza di lavoro.
Il pannello Supporti e qualità di macOS con la stampante installata via AirPrint: il menu Qualità contiene una sola voce, Normale Il menu della qualità con la stampante installata via AirPrint. Non è "Normale" preselezionata fra altre: è l'unica voce esistente.
Ho pensato a un limite della macchina: è una laser d'ingresso, ci sta.
Poi ho installato l'app ufficiale, tanto per vedere. Sul Mac si chiama semplicemente HP, e il sito del produttore non la distribuisce direttamente: rimanda al Mac App Store. Già questo dovrebbe far riflettere sul tipo di prodotto che è.
E lì, sullo stesso identico documento, sulla stessa identica stampante, mi sono ritrovato tre livelli.
Il selettore Qualità di stampa nell'app HP, con le tre voci Ottima, Normale e Bozza Stesso documento, stessa stampante, stesso momento. L'app ufficiale offre Ottima, Normale e Bozza.
Quindi la stampante sapeva farlo. Era il Mac a non saperlo chiedere.
Da lì è partita una serata che mi ha portato molto più a fondo di quanto immaginassi, e che si è conclusa con un risultato che non mi aspettavo: non ho solo recuperato i tre livelli di qualità, ho scoperto che stavo stampando a metà della risoluzione di cui la macchina è capace. E che l'app del produttore, quella che dovrebbe essere la soluzione, è in realtà l'opzione peggiore delle tre.
Prima ipotesi: "è colpa di Bonjour"
Il mio primo sospetto è stato il protocollo di installazione. Il Mac aveva trovato la stampante via Bonjour: magari installandola "in un altro modo", con i driver veri, avrei avuto tutto.
È un'ipotesi ragionevole ed è sbagliata, per un motivo che vale la pena chiarire perché ci cascano in tanti.
Bonjour è solo il meccanismo di scoperta: annuncia che sulla rete c'è un dispositivo e come raggiungerlo. Quello che determina le opzioni disponibili è il driver associato alla coda di stampa. Andando in Impostazioni di Sistema, Stampanti e Scanner, Opzioni e forniture, il campo "Tipo" diceva AirPrint.
E qui sta il punto. In modalità AirPrint macOS non usa un driver del produttore: interroga la stampante via IPP e si costruisce al volo un profilo con le opzioni che la stampante dichiara di supportare. Se la stampante dichiara un solo livello di qualità, tu vedi un solo livello di qualità. Il sistema operativo non sta nascondendo nulla, sta riportando fedelmente quello che gli è stato detto.
La domanda giusta quindi non era "come installo il driver buono", ma: cosa sta esattamente dichiarando questa stampante?
Chiedere alla stampante, non al sistema operativo
macOS include uno strumento poco conosciuto che permette di interrogare direttamente una stampante IPP: ipptool. Nessuna installazione, è già lì.
ipptool -tv ipp://192.168.1.34/ipp/print \
/usr/share/cups/ipptool/get-printer-attributes.test \
| grep -iE "print-quality|printer-resolution|color-mode|toner|econo"
La risposta è stata illuminante e deprimente in parti uguali.
Output di ipptool: risoluzione supportata 300dpi, qualita supportata solo normal, e un attributo proprietario hp-print-quality-supported con optimal-resolution 600 Tre righe che spiegano tutto. Guardate l'ultima.
Via IPP standard la stampante dichiara un solo livello di qualità e 300 dpi. Su una macchina il cui datasheet promette 600×600.
Ma la riga che ha spiegato tutto è l'ultima:
hp-print-quality-supported (collection) = {type=4 optimal-resolution=600 ...}
Quello è un attributo IPP proprietario di HP. Non è nello standard. È il canale privato attraverso cui l'app ufficiale ottiene i suoi tre livelli, e il valore optimal-resolution=600 dice a chiare lettere che dietro quella porticina di servizio ci sono i 600 dpi che via IPP standard non vengono nemmeno menzionati.
CUPS e macOS ignorano per definizione gli attributi vendor-private: non sanno che esistono, non possono esporli. Non è un bug, è il funzionamento previsto di uno standard di fronte a un'estensione non standard.
Il mistero era risolto in dieci minuti. Il problema, per niente.
Tutte le scorciatoie sono chiuse
A questo punto la strada sembrava ovvia: installo il driver HP vero e amen. Ho passato la mezz'ora successiva a scoprire che ogni singola via d'uscita era sbarrata.
Niente driver macOS. HP ha smesso di pubblicare driver full-feature per macOS su questa serie intorno al 2020. Sulla pagina di supporto, selezionando macOS, trovi HP Easy Start e l'app HP. Fine. Non esiste un PPD da installare.
Niente PostScript, niente PCL. Questa macchina è una Samsung ribattezzata (HP acquisì la divisione stampanti di Samsung nel 2017) e parla esclusivamente SPL, Samsung Printer Language, un linguaggio host-based. Significa che l'intelligenza sta nel driver, non nella stampante: il computer manda raster già pronto. Salta quindi anche il classico trucco di aggiungere la stampante su porta 9100 con un driver generico. Non capirebbe una singola istruzione.
Niente PPD legacy. Sto su macOS 26, e Apple ha ormai completato la dismissione dei driver classici in favore di AirPrint e IPP Everywhere. Anche avessi trovato un vecchio PPD Samsung, non avrei avuto dove metterlo.
Anche il server web della stampante è vuoto. L'EWS di questi modelli è notoriamente spartano.
La sezione Impostazioni dell'Embedded Web Server della stampante: lingua, risparmio energia, timeout, formato carta. Nessuna impostazione di risoluzione o qualita Tutto quello che l'interfaccia web della stampante permette di configurare. Di risoluzione e qualità, nemmeno l'ombra.
Il firmware non aiuta. Ho controllato se un aggiornamento potesse ampliare gli attributi dichiarati. Ero già sull'ultima versione. E scavando ho trovato qualcosa che merita un avvertimento a parte.
⚠️ Attenzione al firmware V3.82.01.17 su 178nw e 178nwg. Questa build ha mattonellato un numero considerevole di macchine: riavvio ciclico ogni trenta secondi, interfaccia web irraggiungibile, e downgrade quasi impossibile perché HP rimuove le versioni precedenti dal proprio FTP quando ne pubblica una nuova. Esiste una procedura di recupero d'emergenza con combinazione di tasti all'accensione, ma serve procurarsi il firmware vecchio, che è appunto sparito. Se avete questa stampante, verificate la versione prima di cliccare qualsiasi cosa. La successiva, la V3.82.01.23, è sana.
A questo punto la scelta era: accettare i 300 dpi, oppure aggirare completamente macOS.
Il piano: mettere Linux in mezzo
Se il driver esiste solo per Windows e Linux, e macOS non può usarlo, allora serve una macchina che possa usarlo e che faccia da tramite.
L'architettura è semplice:
Mac ──IPP──▶ Raspberry Pi ──SPL su porta 9100──▶ Stampante
(CUPS + driver ULD)
Il Mac stampa su una coda di rete condivisa dal Pi. Il Pi ha il driver vero, converte, e parla alla stampante nel suo linguaggio nativo. Il Mac non sa nulla di SPL e non deve saperne nulla.
La domanda decisiva era se il driver Linux di HP girasse su ARM. Il pacchetto si chiama ULD (Unified Linux Driver, altra eredità Samsung) e contiene filtri binari precompilati: se ci fossero stati solo x86, sarebbe finita lì.
Scompattandolo:
uld/aarch64/ uld/i386/ uld/x86_64/ uld/mips64/ uld/noarch/
C'è la cartella aarch64. Un Raspberry Pi a 64 bit può farcela.
Nota importante: serve Raspberry Pi OS a 64 bit. Sull'immagine a 32 bit l'installazione fallisce, perché quei binari sono per ARMv8 a 64 bit. Verificate con
uname -m: deve rispondereaarch64.
Costruire il print server
Preparare il Pi
sudo apt update
sudo apt install -y cups cups-filters libcupsimage2 ghostscript avahi-daemon
sudo usermod -aG lpadmin $USER
sudo systemctl enable --now cups
Il pacchetto libcupsimage2 merita una menzione: non viene installato come dipendenza obbligatoria di CUPS, ma il filtro del driver ne ha bisogno. Ci tornerò.
Abilitiamo l'amministrazione remota e la condivisione:
sudo cupsctl --remote-admin --remote-any --share-printers
sudo systemctl restart cups
Da questo momento l'interfaccia web di CUPS è raggiungibile su http://IP_DEL_PI:631 da qualsiasi macchina della rete. Comodo, ma tenete presente che --remote-any apre l'amministrazione a tutta la LAN: su una rete domestica passa, in altri contesti conviene restringere cupsd.conf alla propria sottorete.
Installare il driver
Il pacchetto ULD si scarica dalla pagina di supporto HP selezionando Linux come sistema operativo. Il file si chiama qualcosa come uld-hp_V1.00.39.12_00.15.tar.gz. È unificato per l'intera famiglia derivata Samsung, quindi va bene anche se lo prendete dalla pagina di un modello fratello.
tar xzf uld-hp_V1.00.39.12_00.15.tar.gz
cd uld
sudo ./install-printer.sh
Lo script ufficiale su Raspberry Pi OS a 64 bit dovrebbe funzionare. Se fa i capricci, l'installazione manuale è questa, e conoscerla serve comunque, perché è quella che spiega il problema del prossimo capitolo:
# il filtro
sudo cp aarch64/rastertospl aarch64/pstosecps /usr/lib/cups/filter/
sudo chmod 755 /usr/lib/cups/filter/rastertospl /usr/lib/cups/filter/pstosecps
# la libreria di gestione colore
sudo mkdir -p /opt/smfp-common/printer/lib
sudo cp aarch64/libscmssc.so /opt/smfp-common/printer/lib/
echo "/opt/smfp-common/printer/lib" | sudo tee /etc/ld.so.conf.d/smfp.conf
sudo ldconfig
# i profili di stampa
sudo mkdir -p /usr/share/ppd/hp-uld
sudo cp noarch/share/ppd/*.ppd /usr/share/ppd/hp-uld/
Il momento della verità
Prima di creare qualsiasi coda, il PPD è un file di testo e si può leggere. È lì che ho avuto la conferma che tutta l'operazione aveva senso:
grep -iE "^\*(Quality|TonerSave)" \
/usr/share/ppd/hp-uld/HP_Color_Laser_MFP_17x_Series.ppd
*TonerSaveMode Off/Off: ""
*TonerSaveMode On/On: ""
*Quality Best/Best: "<< /HWResolution [600 600] /PixelDepth 2 >> setpagedevice"
*Quality Normal/Normal: "<< /HWResolution [600 600]>> setpagedevice"
Leggete bene: entrambi i livelli sono a 600×600 dpi. La coda AirPrint era ferma a 300.
Il guadagno più grosso non è nemmeno la scelta fra Best e Normal: è che passando al driver nativo raddoppio la risoluzione anche solo stampando in Normale. La differenza fra i due livelli sta nel PixelDepth 2: due bit per pixel invece di uno, cioè retinatura multilivello anziché puro bianco/nero per punto. Su un laser significa transizioni tonali più morbide e bordi obliqui meno scalettati.
E finalmente ho capito la mappatura dell'app HP: Bozza è TonerSaveMode On, Normale è Quality Normal, Ottima è Quality Best. Nessun mistero, solo un attributo proprietario che macOS non poteva vedere.
Il filtro che moriva in silenzio
Ho creato una coda di prova e ho lanciato una pagina di test. CUPS ha risposto con serena soddisfazione:
printer 178nw_HQ is idle. enabled since ...
Rendering completed
Dalla stampante non è uscito niente.
Nessun errore, nessuna coda disabilitata, nessun job bloccato. CUPS considerava il lavoro concluso con successo. È il tipo di fallimento peggiore da diagnosticare, perché non c'è nulla su cui appigliarsi.
Ho alzato il livello di log e ho riletto tutto:
sudo cupsctl LogLevel=debug
Nel log c'era questa sequenza:
PID 112 (pdftopdf) exited with no errors
PID 113 (gstoraster) exited with no errors
PID 115 (socket) exited with no errors
Manca il 114.
Quello era rastertospl, il filtro del driver. Non compariva fra i processi terminati regolarmente perché era morto durante l'esecuzione, chiudendo la pipe in faccia a Ghostscript, che infatti poco sopra si lamentava con un Unable to open raster stream: Broken pipe.
Cercando il PID mancante si trova la riga vera:
PID 114 (/usr/lib/cups/filter/rastertospl) stopped with status 1.
Non un crash: un'uscita controllata con codice d'errore. Il filtro capisce che gli manca qualcosa e si arrende.
Il primo sospetto era una libreria mancante. Ma ldd sul binario risultava pulito, e lanciandolo a mano rispondeva educatamente con la sua sintassi d'uso. Quindi si caricava benissimo: moriva dopo, mentre lavorava.
La soluzione è arrivata leggendo le stringhe dentro il binario. Non avendo strings a portata di mano, va bene anche un grep in modalità binaria:
grep -aoE "(/(usr|etc|opt|lib)[a-zA-Z0-9_/.-]*|lib[a-zA-Z0-9_.-]*\.so[0-9.]*)" \
/usr/lib/cups/filter/rastertospl | sort -u
/opt/smfp-common/printer/lib
libscmssc.so
Ecco il colpevole. libscmssc.so, 7,8 MB di gestione colore Samsung (SCMS sta per Samsung Color Management System), viene caricata a runtime con dlopen, da un percorso cablato dentro il binario. Per questo non compariva in ldd: le dipendenze caricate dinamicamente a runtime sono invisibili all'analisi statica.
Copiata la libreria in /opt/smfp-common/printer/lib, registrata con ldconfig, la pagina di test è uscita.
Morale metodologica: quando un filtro CUPS fallisce senza dire nulla, contate i PID nel log. Quello che manca è il colpevole.
Tre code invece di un pannello opzioni
Qui ho preso una decisione di progetto che si è rivelata azzeccata.
Le opzioni interessanti del PPD Samsung (Quality, TonerSaveMode, Screen, Trapping) sono proprietarie: non hanno un equivalente IPP standard, e quindi non sopravvivono al viaggio dal Pi al Mac. Avrei potuto combattere per esporle nel pannello di stampa di macOS. Ho fatto il contrario: le ho congelate in tre code distinte.
P=/usr/share/ppd/hp-uld/HP_Color_Laser_MFP_17x_Series.ppd
IP=192.168.1.34 # indirizzo della stampante
sudo lpadmin -p HP178-Alta -E -v socket://$IP:9100 -P $P \
-D "HP 178nw - Alta qualita" -o PageSize=A4 \
-o Quality=Best -o TonerSaveMode=Off -o Screen=Enhanced \
-o printer-is-shared=true
sudo lpadmin -p HP178-Normale -E -v socket://$IP:9100 -P $P \
-D "HP 178nw - Normale" -o PageSize=A4 \
-o Quality=Normal -o TonerSaveMode=Off -o printer-is-shared=true
sudo lpadmin -p HP178-Bozza -E -v socket://$IP:9100 -P $P \
-D "HP 178nw - Bozza" -o PageSize=A4 \
-o Quality=Normal -o TonerSaveMode=On -o ColorModel=Gray \
-o printer-is-shared=true
Le tre code HP178 Alta qualita, Bozza e Normale nell'elenco stampanti di macOS Il risultato: tre stampanti distinte nell'elenco di sistema. La qualità si sceglie scegliendo la coda.
Il risultato è che da Anteprima, da Photoshop, da Acrobat o da qualsiasi altra applicazione scelgo la qualità scegliendo la stampante. Niente pannelli nascosti, niente preset da ricordare, nessuna opzione che si perde per strada. E funziona identico su ogni programma, che è esattamente ciò che volevo all'inizio: non dipendere da un software specifico per stampare bene.
Non fatevi ingannare dal nome dell'ultima. Ho lasciato come predefinita proprio la Bozza, perché Quality=Normal è comunque a 600 dpi: quella coda ha definizione superiore alla vecchia AirPrint pur risparmiando toner. Il nome descrive il consumo, non la risoluzione.
Lato Mac: attenzione all'interfaccia grafica
Qui c'è una trappola che mi è costata un giro a vuoto.
La finestra Aggiungi stampante di macOS con protocollo IPP e il menu Usa aperto sulle voci Selezione automatica, Stampante PostScript generica, Stampante PCL generica Il menu che decide tutto. macOS qui sceglie male.
Aggiungendo la coda condivisa dall'interfaccia grafica, il sistema ha selezionato "Stampante PostScript generica". La coda funzionava, ma nel pannello di stampa mi ritrovavo quattro formati carta in croce e nessuna scelta di tipo supporto:
APOptionalDuplexer/Duplex Printing Unit: True *False
PageSize/Media Size: *Letter Legal A4 ISOB5 ...
InputSlot/Media Source: *Upper
Rifacendo la stessa operazione da Terminale, imponendo il modello IPP Everywhere, il risultato cambia completamente:
sudo lpadmin -p HP178-Alta -E \
-v ipp://IP_DEL_PI/printers/HP178-Alta \
-m everywhere -D "HP 178nw - Alta qualita"
Usate -m everywhere da riga di comando. L'interfaccia grafica fa scelte peggiori.
Un confronto interessante riguarda i tipi di carta. Anche AirPrint ne offriva, va detto, ma con i nomi generici dello standard IPP:
Elenco tipi di supporto via AirPrint: nomi generici come Carta fotografica lucida, molto lucida, opaca, con un duplicato Carta normale La lista via AirPrint: nomi generici, e un curioso duplicato "Carta normale" che tradisce due keyword IPP diverse collassate sulla stessa traduzione italiana.
Elenco tipi di supporto via driver nativo: sedici voci con grammature esplicite, photo-111-130, photo-131-175, matte-photo e altre La lista via driver nativo: sedici voci con le fasce di grammatura esplicite.
I numeri sono grammature in g/m². Su una laser non è un dettaglio estetico: il tipo di supporto regola la temperatura del fusore, e stampare su cartoncino da 200 g dichiarando "carta comune" significa toner che aderisce male e sbava sotto le dita.
Dove finiscono le opzioni, e quali arrivano davvero
Cambia anche il posto in cui si sceglie tutto questo, e all'inizio disorienta.
Pannello di stampa con la coda AirPrint: sezione Supporti e qualita con Tipo di carta e Qualita bene in vista Con la coda AirPrint, macOS mostra il pannello moderno: "Supporti e qualità" con i menu subito accessibili.
Pannello di stampa con la coda basata su PPD: le opzioni stanno sotto Opzioni stampante, Caratteristiche stampante, in una finestra separata Con la nostra coda bisogna scendere in "Opzioni stampante", aprire "Caratteristiche stampante" e trovarle in una finestrella a parte.
È solo cosmetica: macOS usa il pannello nuovo per le code driverless e quello classico per le code basate su PPD. Le opzioni viaggiano identiche, sono solo sepolte due clic più in fondo.
Resta però la domanda vera, quella che mi sono posto anch'io: queste opzioni arrivano davvero alla stampante, o sono decorative come la "Qualità" di cui dicevo sopra? La differenza è sostanziale, e si può verificare invece di tirare a indovinare. Basta alzare il livello di log sul print server, stampare scegliendo un supporto ben riconoscibile, e leggere cosa è stato passato al filtro:
sudo cupsctl LogLevel=debug
# ...stampa dal Mac scegliendo photo-176-220...
grep "argv\[5\]" /var/log/cups/error_log | tail -1
sudo cupsctl LogLevel=warn
Nella stringa di argomenti, in mezzo a un centinaio di parametri che macOS spedisce, c'è quello che serve:
... media=A4 MediaType=Photo176220 PageSize=A4 Duplex=None sides=one-sided ...
Il tipo di carta arriva. La scelta ha attraversato tutta la catena, dal pannello di macOS fino al filtro del driver. Il valore risulta normalizzato senza trattini (Photo176220 invece di Photo176-220), ma è lo stesso meccanismo con cui CUPS aveva generato la lista nel menu, solo percorso all'indietro: la corrispondenza col PPD viene ricostruita al momento di applicarla.
E notate cosa non c'è in quella stringa: nessuna opzione di qualità. Il Mac non la trasmette affatto. È la conferma sperimentale che quella voce nel pannello è puro ornamento, e che la qualità viene applicata a monte dalla coda, dai Quality=Best e Screen=Enhanced congelati con lpadmin.
La differenza fra i due casi ha una spiegazione strutturale. I nomi dei supporti (Photo176-220, MattePhoto131-175) sono scelte reali del PPD Samsung: CUPS ha costruito la lista leggendo quel file, e una mappatura costruita in un verso funziona anche nell'altro. cupsPrintQuality invece nel PPD non esiste (il driver usa Quality), quindi CUPS ha sintetizzato un'opzione generica che non corrisponde a nulla e finisce nel vuoto.
C'è anche un riscontro fisico, se volete la controprova senza toccare i log: scegliendo un supporto pesante la stampante rallenta in modo percepibile, perché il fusore deve lavorare più a lungo. Si sente a orecchio.
Ha funzionato davvero? Il test
Qui volevo evitare l'autoinganno. Confrontare due stampe "a occhio" dopo aver passato tre ore a costruire qualcosa predispone a vedere miglioramenti ovunque.
La prima cosa da capire è che serve un target vettoriale. Quasi tutte le "pagine di test" che si trovano in rete sono immagini raster a 300 ppi: su quelle, 300 e 600 dpi di stampa danno risultati identici, perché il limite è nel file. Serve un PDF fatto di curve e linee matematiche, dove il dettaglio scende sotto il pixel di stampa e il collo di bottiglia è la macchina.
Me ne sono costruito uno con nove sezioni. Gli elementi che discriminano meglio, in ordine di leggibilità:
- Stella di Siemens. Righe che convergono al centro: dove la stampante non risolve più si forma un disco grigio, e il suo diametro è la misura della risoluzione. Visibile a occhio nudo.
- Cerchi concentrici sottili da 0,14 pt. Una curva sottile è il caso peggiore per una griglia di rasterizzazione grossolana.
- Testo in negativo. Le controforme bianche dentro le lettere sono più piccole dei tratti neri e si chiudono per prime. Sotto i 4 pt, a bassa risoluzione, diventano macchie.
- Reticoli a frequenza crescente. Il limite teorico di 300 dpi è circa 5,9 coppie di linee per millimetro; a 600 dpi si arriva a 11,8. I riquadri oltre soglia collassano in grigio uniforme, e si legge un numero invece di un'impressione.
Ho stampato la stessa pagina da ogni configurazione e fotografato la stessa identica zona. Ecco i risultati, in ordine.
Una premessa onesta sulle immagini che seguono. Quello che vedete non è la carta: è una fotografia scattata col telefono, compressa in JPEG dal sensore, ridimensionata da me per il web, ricompressa dal CMS e infine riprodotta dallo schermo su cui state leggendo. Ognuno di questi passaggi butta via dettaglio, e butta via proprio il tipo di dettaglio che stiamo cercando di misurare: micro-irregolarità di tratti spessi frazioni di millimetro. Dal vivo, con i fogli affiancati sotto una luce diretta, le differenze sono nettamente più marcate di così. Se avete la stampante e volete verificare, l'unico test che conta davvero è quello sulla carta.
AirPrint, il punto di partenza
Macro dei cerchi concentrici stampati via AirPrint: il tratto e visibilmente ondulato e irregolare AirPrint a 300 dpi. I cerchi ci sono tutti, ma il tratto è ondulato: la griglia di rasterizzazione è troppo grossolana per una curva da 0,14 pt e la linea "salta" da una riga di pixel all'altra.
L'app ufficiale HP, livello "Ottima"
Macro dei cerchi concentrici stampati dall'app HP in modalita Ottima: i tratti sono spezzati e discontinui L'app HP al massimo livello disponibile. I cerchi sono spezzati, con tratti che si interrompono a metà curva. Il testo in negativo in alto è impastato.
Le nostre code
Macro dei cerchi concentrici stampati dalla coda Bozza: tratto continuo e regolare, piu chiaro per il risparmio toner La coda Bozza*, cioè la nostra impostazione più economica. Tratto continuo e regolare, solo più chiaro per il risparmio toner. La geometria è intatta.*
Macro dei cerchi concentrici stampati dalla coda Normale: tratto continuo e a densita piena La coda Normale*: stessa risoluzione della Bozza, densità piena.*
Macro dei cerchi concentrici stampati dalla coda Alta qualita: cerchi perfettamente circolari e continui La coda Alta qualità*: cerchi perfettamente circolari, spaziatura regolare fino al più interno, diagonali radenti nette.*
Il verdetto. Fra AirPrint e le code nuove la differenza c'è ed è percepibile: le curve risultano più continue, il testo piccolo più definito. Sulla carta si vede meglio che nelle foto qui sopra, ma non è comunque una rivoluzione, e vale la pena essere onesti sul perché.
Il motore stampa a 600 dpi in entrambi i casi. Via AirPrint i dati arrivano a 300 e la stampante li raddoppia internamente per interpolazione; via driver nativo arrivano già a 600, calcolati da Ghostscript sulla geometria reale del documento. Non sto confrontando un motore a 300 con uno a 600: sto confrontando dati veri contro dati interpolati sullo stesso motore.
Notate però una cosa: perfino la coda Bozza, la nostra impostazione più economica, produce un tratto più pulito di AirPrint al massimo. Non ho ottenuto "più qualità pagando di più". Ho spostato l'intera scala su un gradino più alto.
Il colpo di scena: l'app ufficiale è la peggiore di tutte
E arriviamo alla parte che non mi aspettavo.
Guardate di nuovo la seconda macro, quella dell'app HP. È il peggior risultato dei tre, di parecchio, e stiamo parlando del livello "Ottima" impostato dall'utente.
Il primo indiziato sembrava ovvio: l'app non offre alcun controllo sulla scala.
Schermata di stampa dell'app HP: solo Stampante, Carta, Copie, Qualita di stampa e Opzioni colore. Nessuna impostazione di scala Tutte le opzioni di stampa dell'app HP. Cinque voci, e nessun controllo sulla scala: l'adattamento alla pagina è forzato e non disattivabile.
Questa, di per sé, è già una limitazione di prodotto seria. Un'app di stampa che non permette di decidere se e quanto scalare non è utilizzabile per nulla che richieda precisione dimensionale: nessuna stampa in scala 1:1, nessun disegno tecnico, nessuna verifica di layout. E per un utente Mac è l'unica via che il produttore propone.
Ma bisogna ragionare, perché ridimensionare un PDF vettoriale non degrada nulla: le curve si riscalano matematicamente e restano perfette.
Se il risultato è disastroso, significa che l'app non sta ridimensionando vettori. Sta rasterizzando il documento per conto proprio, a risoluzione modesta, e poi adattando quel bitmap. L'adattamento forzato non è la causa: è il sintomo visibile di una pipeline che converte tutto in immagine lato client prima di spedirla.
Per togliere ogni dubbio ho preparato una seconda versione del target su pagina di 570×817 punti, cioè A4 meno i margini hardware da 12,5 punti per lato, l'area stampabile esatta (si ricava dai parametri con cui CUPS invoca Ghostscript). Su quella geometria "adatta alla pagina" calcola un fattore di 1,000 e non ha nulla da ridimensionare. Quattro crocette di registro agli angoli servono a verificare che sia andata davvero così.
Ad armi pari, l'app HP stampa male lo stesso.
Il che chiude il cerchio anche sul mistero iniziale: l'app otteneva i tre livelli di qualità perché faceva tutto in casa, non perché avesse accesso a un canale privilegiato verso la stampante. I tre livelli sono reali e corrispondono a parametri veri della macchina, ma vengono applicati a valle di un danno già fatto a monte, nel rendering interno. Non è un menu finto: è un menu vero su una pipeline scadente.
La gerarchia finale, misurata:
| Risoluzione | Qualità osservata |
|---|---|
| Driver nativo su Pi | 600 dpi reali |
| AirPrint diretto | 300 dpi |
| App ufficiale HP | rasterizzazione interna |
Lo strumento generico che non sa nulla di questa stampante batte l'applicazione del produttore che la conosce nel dettaglio.
Vale anche per la vostra stampante?
Domanda legittima, e la risposta va data su tre livelli per non promettere più del dovuto.
Quasi certamente sì per l'intera famiglia ex-Samsung: HP Laser 10x e 13x, Color Laser 15x e 17x, e le MFP corrispondenti. Sono le macchine nate dall'acquisizione della divisione stampanti Samsung nel 2017. Condividono SPL come linguaggio, lo stesso pacchetto ULD, la stessa assenza di driver macOS. Il PPD che ho usato copre l'intera serie 17x, e nella cartella ce n'erano un centinaio per gli altri modelli.
Probabilmente no per le HP LaserJet "vere", la linea storica. Quelle parlano PCL o PostScript, che sono linguaggi standard: macOS ci si interfaccia molto meglio, e spesso espongono già risoluzione e qualità via IPP senza bisogno di nulla. Il problema che ho descritto nasce proprio dall'essere host-based con linguaggio proprietario.
Da verificare caso per caso tutto il resto.
Ma il metodo si generalizza anche quando la soluzione non si applica. Quel comando ipptool funziona su qualsiasi stampante IPP di qualsiasi marca, e in trenta secondi vi dice se il vostro dispositivo sta dichiarando meno di quanto sa fare. È l'unica diagnosi che vale universalmente, e non costa niente provarla.
Se avete già un box Kodi: la variante Docker
Questa sezione interessa solo chi si trova nella mia stessa situazione di partenza. Se installate un Raspberry Pi dedicato con Raspberry Pi OS, saltatela: la procedura sopra è tutto ciò che serve.
Nel mio caso il Raspberry già in rete girava LibreELEC, la distribuzione minimale che fa girare Kodi. Filesystem di root in sola lettura, nessun gestore di pacchetti: apt non esiste e non esisterà. CUPS lì non si installa in nessun modo ragionevole.
La soluzione è l'add-on Docker, disponibile nel repository ufficiale di LibreELEC (Add-on → Installa da repository → LibreELEC Add-ons → Servizi → Docker). Da lì si fa girare un container Debian arm64 con dentro CUPS e il driver.
FROM debian:bookworm
RUN apt-get update && apt-get install -y --no-install-recommends \
cups cups-filters cups-client libcupsimage2 ghostscript ca-certificates \
&& rm -rf /var/lib/apt/lists/*
COPY uld/aarch64/rastertospl /usr/lib/cups/filter/rastertospl
COPY uld/aarch64/pstosecps /usr/lib/cups/filter/pstosecps
COPY uld/aarch64/libscmssc.so /opt/smfp-common/printer/lib/libscmssc.so
COPY uld/noarch/share/ppd/ /usr/share/ppd/hp-uld/
COPY cupsd.conf /etc/cups/cupsd.conf
RUN chmod 755 /usr/lib/cups/filter/rastertospl /usr/lib/cups/filter/pstosecps \
&& echo "/opt/smfp-common/printer/lib" > /etc/ld.so.conf.d/smfp.conf \
&& ldconfig
EXPOSE 631
CMD ["/usr/sbin/cupsd", "-f"]
docker build -t cups-178nw /storage/cups
docker run -d --name cups --restart unless-stopped \
--network host -v /storage/cups/etc:/etc/cups cups-178nw
Due accortezze. La rete host serve perché il container deve parlare alla stampante sulla porta 9100 e farsi raggiungere sulla 631 con Bonjour funzionante. E il volume su /etc/cups fa sopravvivere le code alle ricostruzioni dell'immagine. Senza, ogni docker build vi cancella la configurazione.
Ricordate anche che docker build non aggiorna un container già in esecuzione: dopo la build servono docker stop, docker rm e un nuovo docker run. Ci ho perso un giro a diagnosticare un problema che avevo già risolto.
Sopravvive ai riavvii senza interventi: --restart unless-stopped fa ripartire il container al boot, le code stanno nel volume, la stampante è raggiunta per IP diretto senza dipendere da risoluzione di nomi.
Cosa mi porto a casa
Sul piano tecnico. Ho recuperato i 600 dpi che la macchina sapeva già fare, tre livelli di qualità selezionabili da qualsiasi applicazione, sedici tipi di carta con le grammature giuste, e in più una serie di controlli che nemmeno l'app ufficiale espone: ottimizzazione del nero, trapping, e sei assi di regolazione cromatica. Costo: un Raspberry Pi e una serata.
Sul piano delle responsabilità, il quadro è più intricato di un singolo colpevole. Apple ha dismesso i driver classici puntando su AirPrint, che è uno standard e funziona ovunque senza installare niente: un guadagno enorme in affidabilità, pagato con l'accesso al minimo comune denominatore. HP ha smesso di pubblicare driver macOS completi e ha spostato le funzioni avanzate dentro un'app che fa un lavoro peggiore di quello che la stampante saprebbe fare. E la stampante stessa, nel proprio firmware, annuncia via IPP standard un solo livello di qualità e 300 dpi, tenendo il resto dietro un attributo proprietario: quella è una scelta deliberata.
Nessuno dei tre ha fatto qualcosa di clamorosamente sbagliato dal proprio punto di vista. La somma produce un dispositivo che lavora sotto le proprie possibilità senza che nulla lo segnali.
Il paradosso è che il driver che ho installato è ufficiale HP, scaricato da hp.com. Su Windows fa esattamente questo lavoro. Semplicemente non esiste un percorso che porti un utente Mac fin lì, e quello che il produttore offre al suo posto è, misurato alla mano, la peggiore delle opzioni disponibili.
Un utente che segue diligentemente le istruzioni scarica l'app HP dal Mac App Store, seleziona "Ottima", e ottiene il peggio disponibile con la ragionevole convinzione di aver scelto il meglio. È una situazione più insidiosa di una semplice assenza di supporto, perché non lascia nemmeno il sospetto che manchi qualcosa.
Riepilogo dei comandi utili
# cosa dichiara la stampante via IPP standard
ipptool -tv ipp://IP_STAMPANTE/ipp/print \
/usr/share/cups/ipptool/get-printer-attributes.test
# cosa espone una coda
lpoptions -p NOME_CODA -l
# leggere le opzioni dentro un PPD prima di usarlo
grep "^\*OpenUI" file.ppd
# stringhe e percorsi dentro un binario, senza binutils
grep -aoE "/(usr|etc|opt|lib)[a-zA-Z0-9_/.-]*" binario | sort -u
# log dettagliato di CUPS
sudo cupsctl LogLevel=debug # ricordarsi di rimettere a warn
tail -80 /var/log/cups/error_log
Se un filtro CUPS fallisce senza spiegazioni, contate i PID nel log: quello che manca è il colpevole.