Ciao a tutti, sto implementando un backend cups per la stampa in pdf e
siccome cups minaccia di togliere il supporto ai driver (cosa che mi
sembra alquanto improbabile nel medio periodo) volevo vedere se riuscivo
ad implementarla driverless. Se imposto quindi everywhere come driver al
mio backend arriva uno spool file con mime_type application/octect-stream.

Non c'è modo di convertire quello spool file in postscript o pdf o...?

Grazie

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/28/24 09:18, Diego Zuccato wrote:

octet-stream può essere qualsiasi cosa... Devi salvartelo, analizzarlo
e capire se è un formato che conosci.
Probabilmente la frase chiave di
https://www.cups.org/doc/spec-design.html è questa: "data files are
the original print files that were submitted for printing".
Quello che ricevi dovrebbe essere il data file, quindi il contenuto
dipende da cosa ha generato il driver sul client. Potrebbe già essere
un postscript, e questo ti andrebbe benissimo. Ma potrebbe essere
anche un HPGL o un qualche formato raster :(
Tieni presente che puoi suggerire al client il formato da usare, ma
non puoi costringerlo ad usarlo (quante pagine sprecate dopo un cambio
di stampante...).
Però, se cups è correttamente configurato per la stampa driverless, ti
puoi aspettare uno dei formati specificati (https://wiki.debian.org/CUPSDriverlessPrinting) :
"There is a common PDL that the client can send and that the printer
will accept. The common PDL is based on what is obtained from the
capability information for the selected printer. A driverless-enabled
printer will offer at least one of Apple raster, PWG raster, PDF or
PCLm as a PDL".

Mi ci ero imbattuto anch'io e ora non ricordo più come avevo fatto ma
ero arrivato alla conclusione che fosse un PWG raster... ma poi? Come
fare a convertirlo in qualcosa tipo ps o pdf o... ho cercato,
probabilmente dovrei applicargli qualche filtro ma mi sembra di capire
che anche i filtri siano deprecati? ...devo studiare ancora ma se
qualcuno sa darmi un'imbeccata...

Seguendo l'altro suggerimento di vedere se non fosse un postscript dal
momento che son certo dei driver postscript utilizzati dai clients, come
faccio a convertirlo nuovamente in ps? se lo apro direttamente mi dice:
"File type unknown (application/octet-stream) is not supported" :(

Se la tua "stampante" dice di essere compatibile solo con pdf,
*dovresti* ricevere solo dei pdf pronti da salvare, IIUC :)

questo sarebbe il massimo... anzi, è proprio quello che sto cercando di
fare ;)

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/02/24 14:28, Piviul wrote:

On 2/28/24 09:18, Diego Zuccato wrote:

[snip]

Seguendo l'altro suggerimento di vedere se non fosse un postscript dal momento che son certo dei driver postscript utilizzati dai clients, come faccio a convertirlo nuovamente in ps? se lo apro direttamente mi dice:
"File type unknown (application/octet-stream) is not supported" :(

Se la tua "stampante" dice di essere compatibile solo con pdf,
*dovresti* ricevere solo dei pdf pronti da salvare, IIUC :)

questo sarebbe il massimo... anzi, è proprio quello che sto cercando di
fare ;)

Non credo tu possa farlo usando la modalità driverless. In questa
modalità l'applicazione manda direttamente alla stampante i dati in uno
dei formati supportati (tipo PWG): lo scopo del driverless è proprio
usare un formato unico e ben definito invece di dover convertire da uno all'altro. Tutti i formati driverless sono raster e se vuoi usare il
driverless devi trattarli correttamente.

federico

--
Federico Di Gregorio federico.digregorio@dndg.it
DNDG srl http://dndg.it
La macchina virtuale elabora quindi dati adempiendo le sue funzioni
specifiche senza esistere nella realtà degli oggetti. -- uno studente

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Con cupsfilter in effetti si converte facilmente in ps, pdf... a parte
che dicono di non chiamarlo direttamente ma di impostare i filtri nella
coda di stampa, potrei anche vedere come si fa, ma poi nel man di
cupsfilter leggo sempre la solita minaccia: "CUPS printer drivers,
filters, and backends are deprecated and will no longer be supported in
a future feature release of CUPS."

realizzo solo ora, backends... quindi anche il backend che sto facendo
non sarà più supportato? Allora tanto vale usare un driver postscript e mandare a quel paese la stampa driverless sperando che queste minacce
rimangano nel vuoto!

Mi sfugge qualcosa?

Ma se uno volesse fare una banale stampante virtuale che riceve un ps
come spool e in base a opzioni impostate e all'analisi del contenuto del
file stesso decidere come recapitarlo all'utente che ha inviato la
stampa (via mail o su cartella specifica ricavata dal file stesso...),
che nome dargli, in summa creare una stampante virtuale cups a cui
arriva uno spool che viene dato in pasto ad uno script che fa il lavoro
sporco di convertirlo, rinominarlo e recapitarlo, come deve fare? Se mi
tolgono i backends qual è la strada giusta?

Grazie

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/28/24 15:44, Federico Di Gregorio wrote:

[...]
Non credo tu possa farlo usando la modalità driverless. In questa
modalità l'applicazione manda direttamente alla stampante i dati in
uno dei formati supportati (tipo PWG): lo scopo del driverless è
proprio usare un formato unico e ben definito invece di dover
convertire da uno all'altro. Tutti i formati driverless sono raster e
se vuoi usare il driverless devi trattarli correttamente.

Leggendo qua e la mi sembra di aver capito che ippeveprinter fa al caso
mio. In questo post[¹] ci sono buoni spunti di riflessione sull'utilità
di ippeverprinter e come possa essere una base per una printer application..

Ora mi tocca studiare un po', nei ritagli di tempo... se qualcuno fosse interessato poi mando un feedback.

Piviul

[¹] https://stackoverflow.com/questions/69883878/setting-up-a-print-to-disk-system-with-ippeveprinter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mandi! Piviul
In chel di` si favelave...

tolgono i backends qual è la strada giusta?

Non lo so, ma sono curiosissimo. Se alla fine riescia far funzionare tutto, riesci a docuentare la cosa a pro di tutti?


Poi, 'Driverless' e MOPRIA sono la stessa cosa? Che relazione c'è?

--
Internet it's the largest equivalence class in the reflexive
transitive symmetric closure of the relationship:
``can be reached by an IP packet from''. (Seth Breidbart)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/29/24 12:41, Marco Gaiarin wrote:

Mandi! Piviul
In chel di` si favelave...

tolgono i backends qual è la strada giusta?

Non lo so, ma sono curiosissimo. Se alla fine riescia far funzionare tutto, riesci a docuentare la cosa a pro di tutti?

Ciao Marco, avrei voluto ma mi sono arreso, la possibilità di costruire
una print application con driverless è naufragata. Tieni conto che avrei voluto costruirla soltanto con script nel senso che un buon
programmatore C potrebbe anche costruirsela magari prendendo spunto dal
codice della ippeveprinter...; ma andiamo per gradi. Da quel che ho
capito esiste un software (ippeveprinter) che quando avviato dovrebbe
generare contemporaneamente un servizio ipp e uno http, il primo per
permettere il discovery e stampa ai client della rete e l'altro dovrebbe
essere utilizzato dagli amministratori per configurare via web le
opzioni presenti nel PPD. In altre parole dovrebbe creare a tutti gli
effetti una stampante virtuale IPP everywhere. Fra le varie opzioni c'è
anche la possibilità che venga eseguito uno script per ogni job
stampato... tutto sembra perfetto a parte che non sono riuscito ad
accedere via web alla stampante virtuale (ma di quello se ne può fare a
meno e magari sono solo io che non ci sono riuscito!) ma soprattutto non
si sa nulla del documento stampato ad esempio l'host o l'utente da cui
proviene il documento stampato. Come puntualizzava qualcuno la
ippeveprinter è lo stesso software che c'è su una stampante hp di cui
non ricordo il nome solo che invece di spedirlo alla stampante lo salva
su file... non sufficiente però per costruire una printer application.

Ora la mia 'printer application' utilizza l'emulazione bsd di samba ma
da samba 4.16 non funziona più :( Ho aperto anche un bug report[¹] ma
chissà se verrà mai preso in considerazione.

Comunque per un po' sono coperto, sono riuscito a creare un backend cups
che dovrebbe funzionare almeno finché cups supporterà i backends... ma
se qualcuno volesse suggerire qualche altra strada da percorrere lo
ringrazio fin d'ora! E dimenticavo: se qualcuno fosse interessato a
sapere come si fa un backend cups per la generazione di files di stampa condivido il mio lavoro volentieri!

Poi, 'Driverless' e MOPRIA sono la stessa cosa? Che relazione c'è?

Non conosco MOPRIA... da quel che ho letto in giro apple spinge molto
cups per abbandonare la stampa tradizionale con driver ed utilizzare
soltanto sistemi di stampa driverless. Molti utenti sono preoccupati per
questo passo nel buio ma noi contiamo poco... ci sono anche molti
produttori di hardware che sono dubbiosi: le motivazioni si possono
capire... Tani modi, tutto questo è per dire che mi sono fatto l'idea
che MOPRIA sia solo un consorzio di aziende che cerca di pilotare la transizione driverless e non lasciarla solo in mano ad apple. Ma forse
mi sbaglio

Piviul

[¹] https://bugzilla.samba.org/show_bug.cgi?id=15576

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/1/24 15:59, Piviul wrote:

Non conosco MOPRIA... da quel che ho letto in giro apple spinge molto
cups per abbandonare la stampa tradizionale con driver ed utilizzare
soltanto sistemi di stampa driverless. Molti utenti sono preoccupati
per questo passo nel buio ma noi contiamo poco... ci sono anche molti produttori di hardware che sono dubbiosi: le motivazioni si possono
capire... Tani modi, tutto questo è per dire che mi sono fatto l'idea
che MOPRIA sia solo un consorzio di aziende che cerca di pilotare la transizione driverless e non lasciarla solo in mano ad apple. Ma forse
mi sbaglio

Qualcosa di più su Mopria e driverless printing:

AirPrint(released in 2010), IPP Everywhere, Mopria, Wi-Fi Direct Print.
These standards are practically all the same, the printer advertises its presence, its network address, and basic capabilities via DNS-SD (aka
BonJour, mDNS, zero-conf, implemented with Avahi in Linux), accepts communication and jobs from clients via IPP (Internet Printing
Protocol), from the Printer Working Group, supplies complete capability
info to clients via IPP and uses only common Page Description Languages
(PDLs) for jobs: PDF, Apple Raster, PWG Raster, PCLm.

fonte: https://openprinting.github.io/documentation/01-printer-application/

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)