Newsgroup: it.comp.appl.access
Titolo: Access e Form Processing

Qualcuno ha esperienza nell'utilizzo di FormsReaders e Access?
L'idea sarebbe di realizzare il seguente sistema:
Su un modulo stampato contenente una serie di articoli l'utente segna
quelli che vuole (in qualunque modo va bene, crocetta, spunto, casella
dove scrivere l'id, etc..)
L'operatore passa il modulo in un formproccesser, tipo quello della
Abby o Scansoft e da lì la gestione passa a quest'ultimo che dovrebbe
(devo dare un'occhiata alle trials) salvarsi i valori in un db
Idee, pareri, insulti?

 ha scritto nel messaggio 
news:1127899415....@g49g2000cwa.googlegroups.com...




Idee, pareri, insulti?
[risposta]
Insulti non credo che tu debba aspettartene, a meno che tu affermi che 
MAssimiliano è della Roma... Allora sì che son dolori!
Certo il progetto che hai in cantiere non è da prendere sotto gamba; l'unica 
idea che mi viene in mente, chiaramente tutta da verificare, è quella di 
sapere se uno dei software che hai indicato (o anche Microsoft Document 
Scanning+OCR) supporti OLE.
Se è così potrebbe essere possibile creare le "zone di scansione" sempre nei 
punti  e con le dimensioni prefissati...
Ora sì che mi aspetto degli insulti...
Ciao.
-- 
Sergio MAZZA 

 MAssimiliano č della Roma... Allora sě che son dolori!
...
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 Info:  
www.donkarl.com/it
Ciao.
-- 
Sergio MAZZA 

Da quel che ho letto sui siti di Scansoft e Abby i loro FormReader
disegnano e stampano i moduli che vuoi e poi li scansionano e li
elaborano; se trovo una trial vorrei verificare se poi è possibile
realizzare l'integrazione con access

 ha scritto nel messaggio news:1127979350....@g44g2000cwa.googlegroups.com...

[risposta]
E quel "...disegnano e stampano..." che non capisco.
Avevo letto da quelche parte che qualche software house aveva immesso sul mercato un "lettore di moduli"; ma le variabili in gioco 
sono molte prima di arrivare ad un risultato vicino al 90%.
Invece sul piano funzionale se questo software prevedesse la creazione, da parte dell'utente, di moduli adatti ai suoi documenti 
sarebbe una quasi rivoluzione per chi fa data-entry in modo massivo; o anche per chi semplicemente deve gestirsi la contabilità 
della sua attività...
Ciao.
-- 
Sergio MAZZA 

della sua attività...
Secondo quanto dichiarato dalla Abby, con la loro versione standard del
FormReader un solo operatore è in grado di processare "up to 3000
(!!!) forms per day", le conclusioni arrivano da sole!
E inoltre permettono di creare dei propri moduli personalizzati da
stampare e successivamente passare all'ocr.
Se ci pensi è un sistema già usato da molti anni, ad esempio nei test
a lettura ottica.
I prezzi della Abby non li trovo, la Scansoft ne ha due versioni, la
entry level costa 99$, la Premium qualche spicciolo in più...699$!

entry level costa 99$, la Premium qualche spicciolo in più...699$!
ho detto una cretinata, il programma della Scansfoft transforma
semplicemente un modulo cartaceo in uno compilabile su pc, non c'entra
un tubo con il form proceesing. Quindi resta solo quello della Abby

 ha scritto nel messaggio news:1127988879....@g43g2000cwa.googlegroups.com...
Secondo quanto dichiarato dalla Abby, con la loro versione standard del
FormReader un solo operatore è in grado di processare "up to 3000
(!!!) forms per day", le conclusioni arrivano da sole!
[risposta]
E chi è la Dea Kalì?
E inoltre permettono di creare dei propri moduli personalizzati da
stampare e successivamente passare all'ocr.
[risposta]
Ecco questa è una funzionalità interessante, ma io con il termine "modulo" non intendo un supporto cartaceo ma un modulo "digitale" 
che corrisponde come grafica ad un documento di tipo fattura (per esempio).
Se ci pensi è un sistema già usato da molti anni, ad esempio nei test
a lettura ottica.
[risposta]
Non so' io mi ricordo che leggevano solo la variazione del bianco (assenza di informazione), non i caratteri inseriti; ma se l'hanno 
implementata con l'OCR non capisco perché non produrre un software "adattabile" (dall'utente è ovvio) ad ogni tipo di documento.
Ciao.
-- 
Sergio MAZZA 

implementata con l'OCR non capisco perché non produrre un software "adattabile" (dall'utente è ovvio) ad ogni tipo di >documento.
Hai ragione, ti ricordi bene. Io non ho bisogno che il programma mi
legga i dati del modulo scritti a mano ma "solo" delle crocette e un
codice stampato
Il modulo lo stampo io dal mio db, il cliente mette le crocette accanto
ai prodotti che vuole, io lo passo allo scanner, l'ocr lo "legge" e mi
esporta il tutto su excel (non ho ancora trovato ocr et similia con
output su access); da excel con transferspreadsheet lo importo e mi
aggiorno i dati che servono.
E' tutto facile tranne il passaggio ocr-excel che conosco per nulla.
Farò delle prove e se vi interessa posto i risultati.
Btw, il giochetto della Abby gestisce fino a 200.000 forms al mese e
non costa nulla, è quasi regalato...solo 3000 euro :-(

 ha scritto nel messaggio news:1127995469.6...@g44g2000cwa.googlegroups.com...
Hai ragione, ti ricordi bene. Io non ho bisogno che il programma mi
legga i dati del modulo scritti a mano ma "solo" delle crocette e un
codice stampato
Il modulo lo stampo io dal mio db, il cliente mette le crocette accanto
ai prodotti che vuole, io lo passo allo scanner, l'ocr lo "legge" e mi
esporta il tutto su excel (non ho ancora trovato ocr et similia con
output su access); da excel con transferspreadsheet lo importo e mi
aggiorno i dati che servono.
E' tutto facile tranne il passaggio ocr-excel che conosco per nulla.
Farò delle prove e se vi interessa posto i risultati.
Btw, il giochetto della Abby gestisce fino a 200.000 forms al mese e
non costa nulla, è quasi regalato...solo 3000 euro :-(
[risposta]
Il problema secondo me non è l'output dell'ocr su access, sul sito comune (se già non lo conosci) ci sono un paio di esempi di 
utilizzo dello scanner per la gestione delle immagini; ma, come ti ho già scritto, delimitare la zona di lettura delle crocette 
escludendo il resto del supporto cartaceo.
Facciamo quindi mente locale sugli strumenti che servono per la realizzazione della tua applicazione (a parte l'HW):
- un activex che ti permette la gestione di scanner;
- un OCR, ma più avanti potrebbe non essere necessario;
- una tabella che riceva i dati letti o dall'OCR o da qualsiasi software.
L'activex c'é o è possibile reperirlo; l'OCR, ora che ci sto' pensando potrebbe non essere necessario, perché se riesci ad ottenere 
la porzione di documento scansionato, salvato su un file immagine in b/n; potresti aprire il file e leggere le variazioni di colore. 
Ogni variazione (in nero) è un valore da scaricare in un campo di tabella...
Ciao.
-- 
Sergio MAZZA 

- una tabella che riceva i dati letti o dall'OCR o da qualsiasi software.
L'OCR mi serve perchè devo leggere anche un codice oltra alla
crocetta; tutti gli ocr possono esportare su excel e alcuni, tipo
Finerader leggono anche strutture tabellari. Farò delle prove con le
trial e vedo che esce fuori.
Magari posterò i risultati se può tornare utile a qualcuno altro del
ng.
Paolo