Archive:Novità su stampa e stampanti

Per le ultime novità su stampa e stampanti vedi il Portale di stampa.

Le stampanti su porta parallela non funzionano più in maniera automatica

A partire da openSUSE 11.4 il kernel non carica più il modulo del kernel 'lp', a meno che non venga esplicitamente richiesto di farlo. Più precisamente udev non fornisce più i nodi statici in /dev/. Quando /dev/lp0 viene aperto per inviare i dati attraverso la porta parallela, il modulo del kernel 'lp' non è più caricato in automatico, per cui non è più possibile inviare alcun dato. In sintesi a partire da openSUSE 11.4, non è più possibile usare la porta parallela per una stampante senza un qualche intervento dell'utente.

Se si utilizza openSUSE 12.1 (o versioni più recenti), si può tuttavia installare il pacchetto "parallel-printer-support", che crea un nodo udev statico per la porta parallela. La sua finalità è di caricare il modulo del kernel "lp" in modo automatico la prima volta che vengono inviati dati alla porta parallela. Nel caso in cui quel pacchetto non risulti disponibile quando si sta usando zypper install o il modulo Gestione pacchetti di YaST, assicurarsi di aver fatto l'aggiornamento in linea di openSUSE 12.1 e che il repository ufficiale Aggiornamenti per openSUSE 12.1 12.1-1.4 sia abilitato (dovrebbe esserlo per impostazione predefinita).

Con openSUSE 11.4, al fine di installare il pacchetto "parallel-printer-support", è possibile ottenere quest'ultimo dal repository "Printing", scaricandolo direttamente da http://download.opensuse.org/repositories/Printing/openSUSE_11.4/noarch/ oppure utilizzando il seguente One Click Install: Button-oci.png

Durante l'Installazione One Click si aprirà la finestra di Installazione di YaST in cui verrà chiesto se si desidera sottoscrivere il repository dei programmi "Printing", assieme ad una casella di selezione per confermare oppure rifiutare di "Mantenere la sottoscrizione a questo repository dopo l'installazione". Assicurarsi di non mantenere la sottoscrizione al repository "Printing", altrimenti verranno installati nel proprio sistema i più recenti pacchetti di sviluppo relativi a stampa e stampanti, il che potrebbe creare dei problemi alle funzionalità di stampa del sistema (o comprometterle), si puà leggere al riguardo la descrizione del repository Printing.

Vedere inoltre

Alcuni dispositivi HP non vengono rilevati come al solito

È possibile che il comando, fornito da CUPS, "lpinfo -v" (eseguito come root) o le corrispondenti chiamate alle librerie di CUPS per rilevare i dispositivi non rilevino più i dispositivi HP con una connessione di tipo "hp:/...", specifica di HP, ma - se vengono rilevati - solo con la connessione generica "usb:/...". Per la semplice stampa entrambe le connessioni dovrebbero funzionare, ma per qualunque altra cosa (p.es. stato del dispositivo via "hp-toolbox" di HP, o la scansione nel caso di un dispositivo HP multifunzione) è obbligatorio usare la connessione "hp:/...", si veda http://en.opensuse.org/YaST_Printer#Connection.

La causa di questo inconveniente è che i backend, forniti da HP, "hp" e "hpfax", non possono essere eseguiti contemporaneamente, vedi https://bugs.launchpad.net/hplip/+bug/741073

Una soluzione di ripiego per i dispositivi HP privi di fax è di disabilitare il backend hpfax con il seguente comando (da root):

chmod a-x /usr/lib/cups/backend/hpfax

Numerosi risultati di stampa non andati a buon fine con l'impostazione predefinita di CUPS "RIPCache 8m"

Per default CUPS dispone di soli 8 MB di RIPCache, vedere "RIPCache" alla pagina http://www.cups.org/documentation.php/doc-1.4/ref-cupsd-conf.html.

Questa impostazione predefinita è presente da parecchio tempo e non aveva (fin'ora) causato problemi. Ma da qualche tempo si presentano sempre più errori, riguardanti risultati di stampa non riusciti, che sono legati a questo basso valore predefinito. La radice del problema è che le versioni recenti di Ghostscript hanno modificato le interfacce API interne per la renderizzazione a bande dell'immagine (banding), ma il driver raster per CUPS non è stato aggiornato di conseguenza in Ghostscript.

Per esempio potrebbe non esserci alcun risultato di stampa per via di un filtro di CUPS ("/usr/lib/cups/filter/pstoraster failed") o la stampa finale potrebbe essere corrotta come nell'allegato 380232 nel sito Bugzilla di Novell/openSUSE.

Se i tentativi di stampa non riusciti dipendo veramente dal basso valore di RIPCache preimpostato, sarà d'aiuto aggiungere a /etc/cups/cupsd.conf una stringa come:

RIPCache 128m

dopodiché riavviare il demone cupsd. Di conseguenza il driver raster per CUPS otterrà più memoria disponibile in Ghostscript in modo tale che la costruzione (il rendering) dell'immagine avverrà in modalità pagina intera (full page) e non in modalità a bande (banding, o clist), il che permette di aggirare il problema dovuto alla modifica delle API per il banding.

In alcuni casi (probabilmente solo per la stampa a colori ad alta risoluzione con il driver di Gutenprint) può essere necessario impostare un valore più alto della cache, per esempio 1GB con

RIPCache 1024m

dando naturalmente per scontato che si disponga di almeno 2GB di memoria principale sul computer.

Collegamenti alle pagine di openSUSE e Novell sull'argomento:

Collegamenti esterni:

Sostituzione del pacchetto cups-drivers

Fino ad openSUSE 11.3 il pacchetto cups-drivers era un grosso pacchetto onnicomprensivo che includeva numerosi driver per le stampanti, in effetti indipendenti, e numerosi blocchi di file PPD.

A partire da openSUSE 11.4 i seguenti pacchetti di driver e file PPD sono separati dal pacchetto cups-drivers ed il pacchetto cups-drivers stesso è stato eliminato:

  • gutenprint: il driver Gutenprint ed i file PPD corrispondenti
  • splix: il driver SpliX ed i file PPD corrispondenti
  • m2300w: il driver m2300w ed i file PPD corrispondenti
  • OpenPrintingPPDs-ghostscript: i PPD per i driver en:Ghostscript built-in
  • OpenPrintingPPDs-hpijs: i PPD per i driver HPIJS, per stampanti non-HP
  • OpenPrintingPPDs-postscript: i PPDs per stampanti en:PostScript

Conformità con CUPS upstream

openSUSE 11.3 ha introdotto una versione epurata di CUPS. Quasi tutte le nostre patch sono stare rimosse per rendere effettivo un ripristino quasi conforme al 100% con la versione upstream. La modifica più importante è che la directory "/usr/lib/cups/" è usata su tutte le piattaforme (in particolare non è più "/usr/lib64/cups" sulle piattaforme a 64-bit x86_64). Per le informazioni che accompagnano il passaggio vedere, al sito en:Bugzilla di Novell/openSUSE, il Commento n.2 al bug 575544: "adapt other printing packages to work with upstream compliant cups-1.4 on 64 bit platform" che in particolare riporta:

Upstream CUPS installs executables
(in particular backends and filters)
into /usr/lib/ in any case which is
the right place. Compare /usr/bin/
there is nothing like /usr/bin64/ because
for executables special ...64 directories
do not make sense.
In contrast libraries like libcups.so
and libcupsimage.so must be installed
into /usr/lib/ and /usr/lib64/
...
A positive side effect of this clean-up
is that then it works much better to
install third-party printer drivers (which
usually install only into /usr/lib/cups/)

Trad.: "CUPS Upstream installa in ogni caso gli eseguibili (in particolare i backend e i filtri) in /usr/lib, che è la posizione corretta. Se pensiamo a /usr/bin non esiste /usr/bin64 perché per gli eseguibili [..] cartelle speciali con suffisso 64 non hanno senso. Di contro librerie come libcups e libcupsimage devono essere installare sia in /usr/lib che /usr/lib64 [..]. Un effetto positivo di questa ripulita è che ora è più facile installare i driver di terze parti per la stampante (di solito installati solo in /usr/lin/cups)".

Modulo Stampante di YaST rivisitato

A partire da openSUSE 11.1 il Modulo Stampante di YaST è stato completamente rinnovato, vedi en:Archive:YaST Printer redesign, in particolare le sezioni "Basic Design Ideas" e "Basic Implementation Principles", in cui la seconda parla anche di "Strict Compliance With CUPS".