Una stampante laser perfettamente funzionante può trasformarsi in un dispositivo quasi inutilizzabile semplicemente perché manca il driver adatto al sistema operativo. È ciò che accade con alcune HP Laser 1003, 1006 e 1008, modelli economici derivati dalla tecnologia Samsung che non supportano AirPrint, PostScript o PCL e per i quali HP non ha distribuito un driver macOS utilizzabile.
Un progetto pubblicato su GitHub ad agosto 2026 mostra però che il limite non risiede nell’hardware: con un’analisi del protocollo di stampa, CUPS, un piccolo ambiente Linux e accesso USB diretto, una HP Laser 1008a può stampare normalmente anche da un Mac Apple Silicon.
HP completò a novembre 2017 l’acquisizione della divisione stampanti di Samsung Electronics, operazione da 1,05 miliardi di dollari che trasferì al gruppo statunitense prodotti, tecnologie e proprietà intellettuale. Alcune laser HP successive conservarono quindi una parentela tecnica molto stretta con modelli Samsung e con i loro linguaggi proprietari di stampa.

Perché la HP Laser 1008a non funziona come una comune stampante su Mac
Il progetto appena pubblicato su GitHub, affronta il problema da un’angolazione insolita: invece di riscrivere completamente il codec proprietario, riutilizza il vero convertitore HP per Linux, lo esegue all’interno di un container e costruisce attorno ad esso il percorso necessario affinché macOS possa consegnargli i dati provenienti da una normale finestra di stampa. Il risultato, testato su macOS 26 con Apple Silicon, permette di usare la HP Laser 1008a come una normale stampante di sistema: compare nella finestra di stampa del sistema Apple e può ricevere i documenti direttamente dalle applicazioni, senza dover eseguire comandi manuali dal Terminale.
Molte laser professionali accettano direttamente PCL o PostScript; numerosi modelli moderni possono invece utilizzare IPP (Internet Printing Protocol) e AirPrint, riducendo fortemente la dipendenza da driver specifici. La Laser 1008a appartiene a una categoria differente: il dispositivo si aspetta un flusso raster codificato secondo una variante della famiglia Samsung Printer Language, indicata nel progetto come SPL3.
In pratica, non basta trasformare un documento in un’immagine bitmap e spedirla sulla porta USB: il raster deve essere suddiviso e confezionato esattamente secondo il formato che il firmware della stampante si aspetta: intestazioni, record di pagina, bande, dimensioni, compressione e marcatori di fine pagina devono corrispondere.
Apple e OpenPrinting spingono sulle stampanti senza driver
È interessante ricordare che Apple e OpenPrinting (progetto della Linux Foundation che sviluppa e mantiene tecnologie open source per la stampa su Linux e sistemi Unix-like) spingono da tempo verso la stampa senza driver tradizionali. AirPrint esiste dal 2010 e OpenPrinting ha iniziato con CUPS 2.2 a scoraggiare le tradizionali code raw, nelle quali i dati arrivano alla stampante senza elaborazione. CUPS, il sistema open source che gestisce le operazioni di stampa su Linux, macOS e altri sistemi Unix-like, dalla versione 2.3 ha poi avviato il superamento graduale del vecchio modello basato su driver specifici e file PPD. Una stampante che richiede un formato proprietario e non parla IPP finisce quindi proprio nella zona più difficile da gestire sui Mac di oggi.
Claude Code entra nell’indagine: prima bisogna capire “la lingua” della stampante
La parte più interessante del lavoro di Kuber Mehta è senza dubbio il metodo seguito per arrivare alla soluzione. Il ricercatore ha lavorato per circa quattro ore insieme a Claude Code, l’agente di programmazione di Anthropic capace non soltanto di suggerire codice, ma anche di esplorare un progetto, leggere sorgenti, eseguire comandi, compilare software e modificare file.
La trascrizione della sessione che ha portato alla realizzazione di un driver funzionante è consultabile online, con poche parti oscurate per privacy: si possono quindi leggere anche i prompt impartiti dal ricercatore e osservare come ipotesi, errori e prove sull’hardware reale abbiano guidato il lavoro.
Il primo candidato era SpliX, un vecchio ma interessante progetto open source nato per permettere a CUPS di pilotare numerose stampanti laser Samsung e modelli derivati che utilizzano linguaggi proprietari come SPL e QPDL. Il suo compito, semplificando, è prendere il raster prodotto dal sistema di stampa – cioè la rappresentazione della pagina già trasformata in pixel – e convertirlo nella sequenza binaria che il firmware della stampante sa interpretare.
Il problema emerso con SpliX
Claude Code ha aiutato a compilare SpliX 2.0.2 su macOS, ad esaminare il codice e verificare alcuni parametri delicati, compresa la larghezza delle bande raster: anziché trasmettere necessariamente una pagina intera in un solo blocco, questi protocolli possono descriverla come una successione di strisce compresse, accompagnate da header, dimensioni e comandi di controllo. Basta interpretare diversamente uno di questi campi perché tutti i pixel successivi finiscano nella posizione sbagliata.
La stampante riceveva i dati e reagiva, ma sul foglio compariva soltanto una zona di strisce nell’angolo superiore sinistro; poi la pagina usciva e la macchina sembrava attendere altro contenuto. La comunicazione USB funzionava: era il flusso SPL3 prodotto da SpliX a non corrispondere esattamente alla variante attesa dalla HP Laser 1008a.
Qui Claude Code è diventato particolarmente utile come strumento di indagine. Il ricercatore poteva descrivere ciò che accadeva fisicamente – foglio espulso, pattern corrotto, LED, comportamento della coda – mentre l’agente controllava sorgenti e output, proponeva test e restringeva progressivamente il campo.
La svolta: invece di riscrivere SPL3, usare il codec originale HP
A quel punto l’indagine ha preso una strada molto più concreta. Nel pacchetto Unified Linux Driver di HP esiste rastertospl, convertitore proprietario che riceve il raster e genera proprio il formato SPL utilizzato da queste stampanti. Se l’implementazione open source non produceva ancora byte compatibili con la 1008a, perché non utilizzare il componente HP che quei byte sa già generarli correttamente?

C’era però un ostacolo: rastertospl è un programma Linux. Anche disponendo della versione ARM64, un Mac con Apple Silicon non può eseguire direttamente un binario compilato per Linux, perché condividere l’architettura della CPU non significa condividere kernel, ABI e librerie di sistema. La soluzione costruita con Claude Code usa quindi Colima e Docker per creare un piccolo ambiente Linux nel quale far girare il codec HP originale.
Il resto del progetto serve a collegare quel componente alla normale finestra di stampa di macOS. CUPS riceve il documento dall’applicazione e produce il raster; lo inoltra attraverso un socket locale a un daemon, che passa i dati al container Linux. rastertospl restituisce il flusso SPL3 corretto e il daemon lo consegna infine alla stampante tramite libusb, evitando anche il backend USB di CUPS che durante i test considerava la Laser 1008a permanentemente offline.
È una costruzione decisamente più elaborata di un normale driver, ma l’utente non deve conoscerne i passaggi: completata l’installazione, la Laser 1008a compare tra le stampanti di macOS e può essere utilizzata dalla comune finestra aperta con Cmd-P.
Le immagini pubblicate nell’articolo sono di Kuber Mehta.