Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
problemi con qrcode e barcode
1,249 views
Skip to first unread message
Suarez
Jul 11, 2014, 3:28:27 AM7/11/14
to
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.
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.
mr
Jul 11, 2014, 3:47:50 AM7/11/14
to
On Friday, July 11, 2014 9:28:27 AM UTC+2, Suarez wrote:
> 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.
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".
> 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.
m.
ispas
Jul 11, 2014, 4:02:59 AM7/11/14
to
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.
askaholik
Jul 11, 2014, 5:54:55 AM7/11/14
to
On Friday, July 11, 2014 5:28:27 PM UTC+10, Suarez wrote:
> 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).
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.
> 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).
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
Diego
Jul 11, 2014, 6:04:07 AM7/11/14
to
On Friday, 11 July 2014 11:54:55 UTC+2, askaholik wrote:
> 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
> 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.
rootkit
Jul 11, 2014, 6:17:03 AM7/11/14
to
Il giorno venerdì 11 luglio 2014 09:47:50 UTC+2, mr ha scritto:
> 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à).
> 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.
mr
Jul 11, 2014, 6:18:01 AM7/11/14
to
On Friday, July 11, 2014 12:04:07 PM UTC+2, Diego wrote:
> On Friday, 11 July 2014 11:54:55 UTC+2, askaholik wrote:
>
>
>
> > Long story: quando l'immagine e' "sfuocata" in realta' vengono tagliate le
> > alte frequenze nelle trasformate di fourier (lowpass), e questo e' un side
> > (CUT...)
> On Friday, 11 July 2014 11:54:55 UTC+2, askaholik wrote:
>
>
>
> > Long story: quando l'immagine e' "sfuocata" in realta' vengono tagliate le
> > alte frequenze nelle trasformate di fourier (lowpass), e questo e' un side
> sticazz ;D
In effetti l'espressione romanesca corretta sarebbe "Me cojoni..!!!" :-)
m.
Gabriele
Jul 11, 2014, 6:08:54 AM7/11/14
to
Suarez wrote, On 11/07/14 09.28:
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
> 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).
[cut]
> 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).
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
ispas
Jul 11, 2014, 6:33:14 AM7/11/14
to
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.
Gabriele
Jul 11, 2014, 6:46:01 AM7/11/14
to
ispas wrote, On 11/07/14 12.33:
percentuale di mercato. Comunque cambia perché può darsi che le impostazioni
del plugin siano diverse dall'applicazione stand-alone e può darsi che il
rendering del browser influisca, ma non credo comunque che provochi una
storpiatura.
Ad ogni modo, io ad es. non ho Acrobat sull'iMac e su ogni PC che mi capita a
tiro lo tolgo e ci metto Foxit Reader.
> 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.
> Il giorno venerdì 11 luglio 2014 12:08:54 UTC+2, Gabriele ha scritto:
>> 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.
>
> 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?
Sai che non sono mica convinto che Adobe Reader abbia ancora una così alta
>> 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.
>
> 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?
percentuale di mercato. Comunque cambia perché può darsi che le impostazioni
del plugin siano diverse dall'applicazione stand-alone e può darsi che il
rendering del browser influisca, ma non credo comunque che provochi una
storpiatura.
Ad ogni modo, io ad es. non ho Acrobat sull'iMac e su ogni PC che mi capita a
tiro lo tolgo e ci metto Foxit Reader.
> 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.
>
G.
ispas
Jul 11, 2014, 6:49:18 AM7/11/14
to
Il giorno venerdì 11 luglio 2014 11:54:55 UTC+2, askaholik ha scritto:
> On Friday, July 11, 2014 5:28:27 PM UTC+10, Suarez wrote:
>
>
>
> > 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).
>
>
>
> 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.
> On Friday, July 11, 2014 5:28:27 PM UTC+10, Suarez wrote:
>
>
>
> > 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).
>
>
>
> 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.
Forse fare nel secondo modo è molto più difficile, chissà.
rootkit
Jul 11, 2014, 7:03:00 AM7/11/14
to
Il giorno venerdì 11 luglio 2014 12:46:01 UTC+2, Gabriele ha scritto:
> Sai che non sono mica convinto che Adobe Reader abbia ancora una così alta
> percentuale di mercato.
in ogni caso chrome, per esempio, apre i pdf con un suo renderer. che
> Sai che non sono mica convinto che Adobe Reader abbia ancora una così alta
> percentuale di mercato.
perlappunto fa bei troiai proprio in stampa.
ispas
Jul 11, 2014, 7:03:21 AM7/11/14
to
Il giorno venerdì 11 luglio 2014 12:46:01 UTC+2, Gabriele ha scritto:
> ispas wrote, On 11/07/14 12.33:
>
> > Il giorno venerdì 11 luglio 2014 12:08:54 UTC+2, Gabriele ha scritto:
>
> >> 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.
>
> >
>
> > 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?
>
>
>
> Sai che non sono mica convinto che Adobe Reader abbia ancora una così alta
>
> percentuale di mercato. Comunque cambia perché può darsi che le impostazioni
>
> del plugin siano diverse dall'applicazione stand-alone e può darsi che il
>
> rendering del browser influisca, ma non credo comunque che provochi una
>
> storpiatura.
Su Windows il plugin Acrobat è un normale componente ActiveX, che puoi richiamare anche dai programmi applicativi, quindi non vedo che differenza ci dovrebbe essere e cosa c'entrerebbe il browser. Ma le sorprese non finiscono mai :-)
>
> > Il giorno venerdì 11 luglio 2014 12:08:54 UTC+2, Gabriele ha scritto:
>
> >> 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.
>
> >
>
> > 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?
>
>
>
> Sai che non sono mica convinto che Adobe Reader abbia ancora una così alta
>
> percentuale di mercato. Comunque cambia perché può darsi che le impostazioni
>
> del plugin siano diverse dall'applicazione stand-alone e può darsi che il
>
> rendering del browser influisca, ma non credo comunque che provochi una
>
> storpiatura.
In altri sistemi non so.
>
> Ad ogni modo, io ad es. non ho Acrobat sull'iMac e su ogni PC che mi capita a
>
> tiro lo tolgo e ci metto Foxit Reader.
> > 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 :)
ispas
Jul 11, 2014, 7:15:45 AM7/11/14
to
--------------------
%PDF-1.4
1 0 obj
<<
/Producer ()
/Author ()
/CreationDate (D:20140711123641)
/Creator ()
/Keywords ()
/Subject ()
/Title ()
/ModDate ()
>>
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
askaholik
Jul 11, 2014, 7:24:33 AM7/11/14
to
On Friday, July 11, 2014 8:49:18 PM UTC+10, ispas wrote:
> 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.
Il problema esiste, eccome! ;-)
> 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.
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).
ispas
Jul 11, 2014, 7:39:42 AM7/11/14
to
Il giorno venerdì 11 luglio 2014 13:24:33 UTC+2, askaholik ha scritto:
> 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).
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.
> 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).
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.
askaholik
Jul 11, 2014, 7:58:45 AM7/11/14
to
On Friday, July 11, 2014 9:39:42 PM UTC+10, ispas wrote:
> 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.
con i formati vettoriali puoi zoomare all'infinito, ma quando lo vai a stampare o lo visualizzi sul monitor, sempre coi pixel finiti hai a che fare ;-)
> 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.
askaholik
Jul 11, 2014, 8:17:07 AM7/11/14
to
ispas
Jul 11, 2014, 1:10:35 PM7/11/14
to
Il giorno venerdì 11 luglio 2014 13:58:45 UTC+2, askaholik ha scritto:
> con i formati vettoriali puoi zoomare all'infinito, ma quando lo vai a stampare o lo visualizzi sul monitor, sempre coi pixel finiti hai a che fare ;-)
Vuoi dire che scalare un formato vettoriale o raster è di fatto la stessa cosa, con gli stessi problemi?
> con i formati vettoriali puoi zoomare all'infinito, ma quando lo vai a stampare o lo visualizzi sul monitor, sempre coi pixel finiti hai a che fare ;-)
> deformazione professionale, ho qui davanti a me un migliaio di immagini con risoluzione 0.1x0.1x0.3mm :-)
askaholik
Jul 11, 2014, 1:59:54 PM7/11/14
to
On Saturday, July 12, 2014 3:10:35 AM UTC+10, ispas wrote:
> Vuoi dire che scalare un formato vettoriale o raster è di fatto la
> stessa cosa, con gli stessi problemi?
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.
> Vuoi dire che scalare un formato vettoriale o raster è di fatto la
> stessa cosa, con gli stessi problemi?
> > 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.
ispas
Jul 11, 2014, 3:07:37 PM7/11/14
to
Il giorno venerdì 11 luglio 2014 19:59:54 UTC+2, askaholik ha scritto:
> On Saturday, July 12, 2014 3:10:35 AM UTC+10, ispas wrote:
>
>
>
> > Vuoi dire che scalare un formato vettoriale o raster è di fatto la
>
> > stessa cosa, con gli stessi problemi?
>
>
>
> 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.
> On Saturday, July 12, 2014 3:10:35 AM UTC+10, ispas wrote:
>
>
>
> > Vuoi dire che scalare un formato vettoriale o raster è di fatto la
>
> > stessa cosa, con gli stessi problemi?
>
>
>
> 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.
Certo, se poi mi paragoni le strutture anatomiche submillimetriche con il codice ottico sulla fattura fiscale, "mi arendo"! :-))
askaholik
Jul 12, 2014, 3:27:21 AM7/12/14
to
On Saturday, July 12, 2014 5:07:37 AM UTC+10, ispas wrote:
> Ma sì, siamo d'accordo che se lavori in prossimità del limite di risoluzione
> hai problemi di scalettamento con qualunque formato.
"scalettamento" e' solo un esempio, il processo di discretizzazione di una funzione continua non e' per nulla banale, e gli approcci da seguire variano molto a seconda dell'applicazione.
> 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.
ispas
Jul 14, 2014, 12:26:59 PM7/14/14
to
Il giorno sabato 12 luglio 2014 09:27:21 UTC+2, askaholik ha scritto:
> 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.
> qui il discorso si fa vastissimo, a tenerlo generale non la si finisce piu'. La risposta e' sempre la stessa: dipende dalle applicazioni.
Suarez
Jul 16, 2014, 3:26:19 AM7/16/14
to
On Fri, 11 Jul 2014 12:08:54 +0200, Gabriele wrote:
>
>Non sono d'accordo, di "default" non storpia niente, se lo vedi male � un
>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.
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
>
>Non sono d'accordo, di "default" non storpia niente, se lo vedi male � un
>problema del generatore del pdf e non del browser.
interessante...
>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.
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
0 new messages