Newsgroup: it.lavoro.informatica
Titolo: problemi con qrcode e barcode

Ne scrivo qui, magari e' gia succesos a qualcuno o magari saprete indirizzarmi
verso una soluzione.
 
Ho un'applicazione web di un cliente, l'applicazione produce dts, fatture ecc
ecc in formato pdf.
 
Su ogni stampa prodotta mettiamo un barcode o un qrcode.
 
L'utente potrebbe voler/dover stampare quel pdf.
 
Ora se uso firefox per visualizzare quel pdf (lo visualizzo dentro il browser)
il plugin di default  "storpiera'" l'immagine del codice sfocandola o
storpiandola (difetto gia noto). 
 
Posso capire quindi che il rendering a video risulti sbagliato. 
 
Ma se stampo quel pdf (dal pulsante stampa del plugin del browser) la stampante
dovrebbe ricevere il flusso del file pdf originale (scaricato sul client credo)
e non quello reinterpretato dal browser. 
 
C'e' evidentemente qualcosa che mi sfugge.

 e non quello reinterpretato dal browser. 
 
Se non ho capito male: no, non è così: se stampi dal browswer, questo stampa la "pagina", che in questo caso è il rendering del PDF effettuato dal browser stesso, quindi ti ritrovi gli stessi eventuali problemi. Alla stampante, in ogni caso, non arriva il flusso del PDF ma una sua "reinterpretazione" fatta dal programma che stampa (browser, lettore PDF o altro). Ho solo il dubbio se Acrobat, in caso di stampante Postscript, faccia una traduzione PDF->PS e invii quella, ma non credo che valfa per altri programmi meno sofisticati e meno "dedicati".
 
m.


Tieni conto che la sfocatura del codice invalida o meno la rilettura in relazione alla dimensione dei quadratini o delle barre. In altre parole, puoi sempre stampare un codice abbastanza grande e/o poco denso da rendere ininfluente la sfocatura (può dipendere anche dal mezzo con cui lo rileggi: lettore specifico, webcam, telefonino...).
Un esempio: ho visto che molto spesso i documenti di check-in o biglietti fatti su internet, e poi stampati, hanno questi codici belli sfocati. Ma essendo molto grandi (diversi cm) non ho mai avuto problemi con i controllori.

 storpiandola (difetto gia noto). 
 
L'immagine viene "sfuocata" o "storpiata" in seguito ad un resampling. Quindi (short story) il "difetto" si correggerebbe mettendo al posto del pdf un'immagine a dimensioni originali.
 
Long story: quando l'immagine e' "sfuocata" in realta' vengono tagliate le alte frequenze nelle trasformate di fourier (lowpass), e questo e' un side-effect dalla maggior parte degli algoritmi di resampling (quelli basati su interpolazione, cioe' la quasi totalita'). Piu' che un "difetto" e' un tipo particolare di "regolarizzazione" e serve (ad esempio) per evitare il partial volume effect (PVE) che porta alla storpiatura dell'immagine, come ad esempio succede col nearest neighbor interpolator. In realta' il termine "sfuocata" e' improprio, perche' un'immagine sfuocata ha un pattern di frequenze diverso dal lowpass dell'interpolator, e non tutti gli algoritmi di resampling possono essere usati per regolarizzare. Il discorso decontestualizzato sarebbe molto piu' lungo, quindi lo fermo qui. Per tagliare la testa al toro, il suggerimento di ispas e' buono: diminuisci il pixel spacing (aumentando le dimensioni dell'imagine in stampa), il PVE diminuisce, e di conseguenza l'immagine risulta meno "storipata" o "smussata". Comunque, se la conversione e' 1:1 senza interpolazione il problema non si pone, per questo sopra suggerivo di mettere l'immagine originale a dimensione fissa, che risolve il problema all'origine.
 
HIH
 

 Long story: quando l'immagine e' "sfuocata" in realta' vengono tagliate le alte frequenze nelle trasformate di fourier (lowpass), e questo e' un side-effect dalla maggior parte degli algoritmi di resampling (quelli basati su interpolazione, cioe' la quasi totalita'). Piu' che un "difetto" e' un tipo particolare di "regolarizzazione" e serve (ad esempio) per evitare il partial volume effect (PVE) che porta alla storpiatura dell'immagine, come ad esempio succede col nearest neighbor interpolator. In realta' il termine "sfuocata" e' improprio, perche' un'immagine sfuocata ha un pattern di frequenze diverso dal lowpass dell'interpolator, e non tutti gli algoritmi di resampling possono essere usati per regolarizzare. Il discorso decontestualizzato sarebbe molto piu' lungo, quindi lo fermo qui. Per tagliare la testa al toro, il suggerimento di ispas e' buono: diminuisci il pixel spacing (aumentando le dimensioni dell'imagine in stampa), il PVE diminuisce, e di conseguenza l'immagine risulta meno "storipata" o "smussata". Comunque, se la conversione e' 1:1 senza interpolazione il problema non si pone, per questo sopra suggerivo di mettere l'immagine originale a dimensione fissa, che risolve il problema all'origine.
 
 
sticazz ;D

 Se non ho capito male: no, non è così: se stampi dal browswer, questo stampa la "pagina", che in questo caso è il rendering del PDF effettuato dal browser stesso, quindi ti ritrovi gli stessi eventuali problemi. 
 
confermo, ho avuto problemi analoghi (con chrome, in verità).

 sticazz ;D
 
In effetti l'espressione romanesca corretta sarebbe "Me cojoni..!!!" :-)
 
m.

 storpiandola (difetto gia noto).
 
[cut]
 
Non sono d'accordo, di "default" non storpia niente, se lo vedi male è un 
problema del generatore del pdf e non del browser.
A parte che il QR lo puoi creare specificando il grado di perdita (utile se lo 
devi stampare su un quotidiano o su un manifesto molto grande), prendi ad es. 
Groupon che genera in pdf tutti gli ordini e mette sia un codice a barre che un 
QR che serve al rivenditore per farsi pagare; ti assicuro che sono 
perfettamente leggibili.
 
Fossi in te indagherei sul modo in cui la applicazione crea il pdf. 
Eventulamente per fare un confronto imposta il web server in modo che non 
faccia aprire nel browser il pdf, ma obblighi a scaricarlo.
 
ciao
Gabriele
 


Ma il plugin di default 90 volte su 100 sarà quello di Acrobat Reader. E quindi che cambia se te lo scarichi, od anche se cambi browser? 
A parte questo, sono d'accordo che il problema comunque starebbe a monte, qualora il codice risulti illeggibile (cosa che invero non si capisce). E' anche facile fare un test, si prende direttamente il pdf, lo si apre e stampa con Acrobat Reader, se è sfocato il problema è nel generatore del pdf, non nel browser.


 
Amen :)
 
G.

 L'immagine viene "sfuocata" o "storpiata" in seguito ad un resampling. Quindi (short story) il "difetto" si correggerebbe mettendo al posto del pdf un'immagine a dimensioni originali.
 
Questo però nel caso in cui il codice  viene generato come immagine a pixel (magari jpg, con ulteriori problemi) e poi inglobato nel pdf. Se viene generato vettorialmente, eventualmente con comandi diretti dello standard pdf di disegno rettangoli e quadrati, il problema non dovrebbe esistere. 
Forse fare nel secondo modo è molto più difficile, chissà.  

 percentuale di mercato. 
 
in ogni caso chrome, per esempio, apre i pdf con un suo renderer. che
perlappunto fa bei troiai proprio in stampa.

 Amen :)
 
E così sia! :-) 
 

>
endobj
2 0 obj
<< /Length 3 0 R
 >>
stream
[] 0 d
0.05 w
0.00 0.00 0.00 RG
0.00 0.00 0.00 rg
63.20 802.10 0.50 -34.50 re
B
[] 0 d
0.05 w
1.00 1.00 1.00 RG
1.00 1.00 1.00 rg
63.70 802.10 0.50 -34.50 re
...............
---------------------------
che sembrano proprio comandi di disegno linee/rettangoli

 di disegno rettangoli e quadrati, il problema non dovrebbe esistere. 
 
Il problema esiste, eccome! ;-)
Perche' comunque l'immagine deve essere rappresentata (stampata o sullo schermo), se la definizione dello schermo o la risoluzione della stampante e' (dico per dire) 0.1 mm e una linea del codice a barre e' larga 0.1 mm, hai un problema perche' lo spessore della linea puo' venire rappresentato tra lo 0 e lo 0.2 mm, quindi e' distorto. Per questo la regolarizzazione e' comunque necessaria, dal momento che le persone hanno piu' abilita' a riconoscere immagini smussate da immagini "pixellate" a parita' di risoluzione (e qui c'e' tutta una letteratura sull'argomento).
 

 Perche' comunque l'immagine deve essere rappresentata (stampata o sullo schermo), se la definizione dello schermo o la risoluzione della stampante e' (dico per dire) 0.1 mm e una linea del codice a barre e' larga 0.1 mm, hai un problema perche' lo spessore della linea puo' venire rappresentato tra lo 0 e lo 0.2 mm, quindi e' distorto. Per questo la regolarizzazione e' comunque necessaria, dal momento che le persone hanno piu' abilita' a riconoscere immagini smussate da immagini "pixellate" a parita' di risoluzione (e qui c'e' tutta una letteratura sull'argomento).
 
Ok, esiste sempre un livello a cui compare la pixel-izzazione ed entrano in gioco le tolleranze, sia a video che in stampa. Tuttavia compare molto prima ridimensionando i formati a pixel che quelli vettoriali.
Poi in pratica non credo che nel caso specifico si abbia l'esigenza di stampare barre larghe 0.1 mm, od al contrario la risoluzione della stampante sia uno squallido 5 mm (ma anche 3-2-1).... :-) 
Poi non capisco: che c'entra l'abilità di riconoscimento delle persone con i codici a barre o qr? Stai dicendo che, poniamo, il formato PDF deliberatamente sfuma qualunque linea per facilitarne la visione umana? Non mi pare proprio.
 

 Non mi pare proprio.
 
no no, era una digressione mia, giusto per giustificare ulteriormente il fatto che smussare l'immagine serve quando la risoluzione e' ai limiti. Tutto qui.
 


http://www.keepcalm-o-matic.co.uk/p/keep-calm-and-me-cojoni-5/
 
 
LOL :-)

 deformazione professionale, ho qui davanti a me un migliaio di immagini con risoluzione 0.1x0.1x0.3mm :-)
 
Bè, di certo ci sono anche tanti casi di barcode minuscoli, tipo quelli su certi apparecchi, od anche su certe bollette. Quelli possono anche avere barre da pochi decimi di mm. Ma non credo proprio che li stampino dal browser con la stampantina da 50 euro, e lo stesso per le tue immagini :-)
 
 

 barre da pochi decimi di mm.
 
Quelle che ho davanti sono scansioni di pazienti, magari avessero la ridondanza dei barcode: il problema e' che alcune strutture anatomiche sono piu' piccole della risoluzione spaziale delle immagini ;-)
 
 

 yep. Prova a disegnare una linea retta obliqua con programmi di grafica antiquati, vedrai che esce pixellata. Se la larghezza della linea e' di un pixel, l'unico modo per non farla pixellata e' sfocarla.
 
Ma sì, siamo d'accordo che se lavori in prossimità del limite di risoluzione hai problemi di scalettamento con qualunque formato. Ma se non sei così vicino al limite, non c'è dubbio che il formato vettoriale dà meno imperfezioni. 
Certo, se poi mi paragoni le strutture anatomiche submillimetriche con il codice ottico sulla fattura fiscale, "mi arendo"! :-))
 

 dà meno imperfezioni. 
 
qui il discorso si fa vastissimo, a tenerlo generale non la si finisce piu'. La risposta e' sempre la stessa: dipende dalle applicazioni. E non e' affatto detto che il formato vettoriale sia sempre da preferire. Nel caso del barcode probabilmente e' da preferire quello vettoriale, in problemi di computer vision piu' complessi, in cui hai da risolvere l'"inverse" e il "forward problem", trasformare e ritrasfromare da discreto a continuo e viceversa crea piu' problemi che altro. Tutto qui.
 
 

 qui il discorso si fa vastissimo, a tenerlo generale non la si finisce piu'. La risposta e' sempre la stessa: dipende dalle applicazioni. 
 
Non c'è dubbio.
 

Fossi in te indagherei sul modo in cui la applicazione crea il pdf. 
 
i nostri qr hanno due dimensioni standard a secondo della tipologia di modulo in
cui sono inseriti, vanno da 1,5 cm di lato a 3 cm di lato. Per generare il pdf
viene utilizzatoa la libreria i-text (credo l'ultima versione stable)
 
C'e� pero' un dato di fatto, se il pdf lo visualizzo dentro firefox il qr code
risulta sfocato, lo stesso problema non si presenta usando IE e l'ultima
versione di Chrome. Se lo stesso pdf lo scarico (a fianco del riquadro di
visualizzazione c'e' il pulsante "Scarica questo file", lo salvo in locale e lo
apro con Adobe Reader va tutto bene.
 
Cmq sul forum di Mozilla avevavo gia segnalato questo problema che affliggeva la
versione 28.x si era risolto con la versione 29.1 e si ripropone ora alla 30.0