Riconoscimento Posizionale Di Testo All'interno Di Un PDF (Report)

Università degli studi di Padova
Facoltà di Scienze MM.FF.NN.

Corso di Lurea Triennale in Informatica
RICONOSCIMENTO POSIZIONALE DI TESTO

ALL'INTERNO DI UN PDF
Relatore: Laureando:
Tullio Vardanega Marco Tessarotto
Anno Accademico 2009-2010

Indice
1 Dominio applicativo 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Tecnologie e processi aziendali . . . . . . . . . . . . . . . . . . 1
1.2.1 Il framework .NET . . . . . . . . . . . . . . . . . . . . 2
1.2.2 C♯ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Windows Presentation Foundation . . . . . . . . . . . 2
1.3 Ciclo attivo e passivo di un’azienda . . . . . . . . . . . . . . . 3
1.4 Plain R Documentale . . . . . . . . . . . . . . . . . . . . . . . 3
2 Progetto aziendale 4
2.1 Problematiche del ciclo passivo . . . . . . . . . . . . . . . . . 4
2.1.1 Modelli di mappatura . . . . . . . . . . . . . . . . . . 6
2.2 Problematiche dei PDF . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Estrazione del testo e dei suoi attributi . . . . . . . . 7
2.2.2 L’assenza di un layout fidato . . . . . . . . . . . . . . 8
2.2.3 L’assenza di una struttura logica . . . . . . . . . . . . 9
2.3 L’estrazione posizionale fidata . . . . . . . . . . . . . . . . . . 11
3 Attività di stage 12
3.1 Studio del dominio applicativo . . . . . . . . . . . . . . . . . 12
3.2 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Individuazione di una libreria . . . . . . . . . . . . . . 15
3.3.2 L’analisi dello stream . . . . . . . . . . . . . . . . . . 18
3.3.3 La definizione della grammatica . . . . . . . . . . . . . 19
3.3.4 Estrazione posizionale di testo . . . . . . . . . . . . . 21
3.3.5 PdfAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.6 PdfFont, PdfChar e PdfText . . . . . . . . . . . . . . 24
3.3.7 Lexer e Parser . . . . . . . . . . . . . . . . . . . . . . 24
3.3.8 PdfPage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
I
Indice
3.3.9 Affidabilità del dato estratto . . . . . . . . . . . . . . 25

3.3.10 Limiti dell’applicazione . . . . . . . . . . . . . . . . . 27
3.4 Codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Preventivo e consuntivo . . . . . . . . . . . . . . . . . . . . . 30
4 Valutazione retrospettiva 33
4.1 Conseguimento degli obiettivi fissati . . . . . . . . . . . . . . 33
4.2 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 ISO 32000 . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 PDF/UA e PDF/A . . . . . . . . . . . . . . . . . . . 36
4.3 Valutazione del corso di studi . . . . . . . . . . . . . . . . . . 37
A Glossario 38
II
Elenco delle figure
2.1 Ciclo attivo e passivo in un’azienda . . . . . . . . . . . . . . . 4

2.2 Produzione e acquisizione di un documento . . . . . . . . . . 5
2.3 Layout e modello di mappatura . . . . . . . . . . . . . . . . . 6
2.4 Affidabilità dell’estrazione . . . . . . . . . . . . . . . . . . . . 8
2.5 Differenza tra HTML e PDF . . . . . . . . . . . . . . . . . . 9
3.1 Diagramma generale delle componenti . . . . . . . . . . . . . 14

3.2 Struttura interna di un file PDF . . . . . . . . . . . . . . . . 18
3.3 Diagramma della struttura principale della grammatica . . . 20
3.4 Diagramma della struttura di un oggetto di testo. . . . . . . . 21
3.5 Diagramma delle classi in Plain.File.Extraction . . . . . . . . 22
3.6 Come garantire l’esattezza del dato estratto . . . . . . . . . . 25
3.7 Misura d’affidabilità per il dato estratto . . . . . . . . . . . . 26
3.8 Dettaglio delle fasi . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Preventivo e consuntivo a confronto . . . . . . . . . . . . . . 31
III
Capitolo 1
Dominio applicativo
1.1 L’azienda
ASI srl (www.plain.it) offre assistenza ad altre aziende fornendo loro soft-
ware di tipo gestionale, software ERP , e la realizzazione/gestione di portali
aziendali. I pacchetti software offerti dalla ASI sono rivolti principalmente
alla gestione delle risorse umane e alla gestione della contabilità e dei do-
cumenti aziendali. ASI srl offre inoltre una serie di pacchetti software ERP
specifici per diverse tipologie di aziende manifatturiere.
ASI è Business Partner di IBM relativamente all’hardware e al software, è

inoltre Gold Certified Partner di Microsoft, fa parte quindi di un gruppo
selezionato di Business Partners Microsoft. A ricevere questa certifica-
zione sono solo le aziende che rispettano tutti i requisiti più rigidi richiesti
da Microsoft, ed hanno certificato su campo (attraverso testimonianze di
clienti o verifiche dirette di Microsoft) la capacità di implementare soluzioni
affidabili, efficienti e scalabili, basate su tecnologie Microsoft.
1.2 Tecnologie e processi aziendali

ASI sviluppa software specifico per fornitori di carta e cancelleria, azien-
de produttrici di articoli da regalo e oggettistica, aziende che si occupano
del noleggio e della vendita di macchine per l’ufficio. Le soluzioni ERP di
ASI sono sistemi software flessibili, capaci di supportare un gran numero di
processi gestionali, riducendo i tempi di acquisizione e di verifica delle or-
dinazioni. I software ASI offrono una piattaforma completa, le cui funzioni
modulari ottimizzano le attività amministrative, finanziarie, commerciali, e
logistiche dell’azienda. ASI utilizza inoltre applicazioni e tecnologie Micro-
soft all’interno dei propri processi di sviluppo, come Visual Studio, Visual
SourceSafe ed SQL Server.
1
1.2. Tecnologie e processi aziendali
1.2.1 Il framework .NET

ASI si appoggia a .NET 3.5 per la realizzazione dei suoi prodotti. Il fra-
mework .NET di Microsoft include: una estesa libreria di classi in grado di
offrire diverse funzionalità; una macchina virtuale che gestisce l’esecuzione
dei programmi scritti in C♯1 . L’utilizzo di una macchina virtuale permette
ai progettisti dell’azienda di concentrarsi sulla risoluzione del problema e
sulle caratteristiche del software, potendo usufruire di tutte le funzionalità
messe a disposizione dalle classi del framework.
1.2.2 C♯
L’utilizzo di C♯ nell’azienda è dovuto principalmente alla sua versatilità.
C♯ infatti si presta bene alla risoluzione di diverse tipologie di problemi
software, grazie anche alla libreria .NET. L’utilizzo di una macchina virtuale
poi offre un maggior livello di astrazione nella fase di progettazione, nonché
una migliore garanzia di sicurezza nelle applicazioni.
1.2.3 Windows Presentation Foundation

Windows Presentation Foundation (da qui in poi WPF) è un sistema per
lo sviluppo di interfacce grafiche in ambiente Windows, ideato per sostitui-
re il vecchio sistema grafico Windows Forms (WinForms) basato su GDI.
WPF è basato su DirectX, che permette, grazie all’accelerazione hardware,
di utilizzare funzionalità avanzate nelle interfacce, come la trasparenza e le
animazioni2 . WPF integra delle primitive vettoriali per la definizione del-
le componenti grafiche, garantendo un’interfaccia scalabile senza perdita di
qualità.
WPF utilizza XAML per la definizione delle interfacce grafiche in C♯. XAML
permette ad un’applicazione WPF di essere distribuita sia come applicazio-
ne desktop che come applicazione web3 . Con XAML, WPF rende esplicita
la separazione tra l’interfaccia grafica e la logica del programma, pur per-
mettendo (tramite data binding) una veloce ed efficace integrazione tra le
due. XAML rende inoltre più semplice ed intuittiva la definizione della GUI
e le modifiche alla stessa.
1
La macchina virtuale gestisce l’esecuzione di tutte le applicazioni sviluppate
all’interno del framework .NET
2
L’utilizzo dell’accelerazione hardware è uno dei punti di forza di WPF, in questo modo
infatti è possibile utilizzare le GPU presenti nell’hardware delle schede video, alleggerendo
il carico di calcolo imposto alla CPU, e in definitiva ottenendo una maggiore reattività e
fluidità nell’interfaccia grafica.
3
XAML è infatti alla base della tecnologia Silverlight, framework per la fruizione di
contenuti interattivi nelle pagine web con funzionalità simili a quelle di Adobe Flash.
2
1.3. Ciclo attivo e passivo di un’azienda
ASI srl ha adottato di recente questa tecnologia nello sviluppo delle nuo-
ve applicazioni (motivata dai vantaggi offerti) e stà attualmente cercando di
portare anche le vecchie applicazioni da Windows Forms a WPF.
1.3 Ciclo attivo e passivo di un’azienda

Il ciclo attivo di un’azienda rappresenta l’insieme delle operazioni che un’a-
zienda intrattiene con i suoi clienti e che determinano dei guadagni per
l’azienda. Il ciclo passivo rappresenta invece l’insieme delle operazioni che
un’azienda intrattiene con i suoi fornitori, e che determinano quindi delle
uscite per la stessa.
Nella gestione dei documenti i due termini indicano rispettivamente: l’insie-

me dei documenti prodotti dall’azienda e l’insieme dei documenti che riceve
invece l’azienda a fronte dei servizi offerti.
1.4 Plain
R Documentale
Plain R Documentale (da qui in poi solo Documentale) è il pacchetto soft-

ware prodotto da ASI per la gestione del ciclo attivo e passivo dei documen-
ti aziendali. Documentale agevola la gestione dei documenti, riducendo lo
sforzo necessario alla produzione e all’archiviazione degli stessi all’interno di
un’azienda. Documentale interviene in quelle aree dove una gestione delle
informazioni è tanto possibile quanto necessaria, senza però sconvolgere le
abitudini operative degli utenti aziendali.
Documentale offre tra le altre le seguenti funzionalità:
• ricerca, consultazione, trasmissione e condivisione dei documenti e dei

loro contenuti;
• sicurezza nell’accesso alle informazioni;
• unificazione dei diversi database documentali presenti in azienda;
• gestione del ciclo attivo nei documenti (definizione del layout, stampa,
archiviazione, trasmissione via fax ed e-mail);
• gestione del ciclo attivo e passivo della posta elettronica e dei docu-
menti trattati via fax automatico;
• gestione del ciclo passivo dei documenti cartacei.
Documentale offre inoltre il supporto alla firma digitale nei documenti e

all’archiviazione sostitutiva a norma.
3
Capitolo 2
Progetto aziendale
2.1 Problematiche del ciclo passivo

Come descritto nel capitolo precedente la gestione dei documenti aziendali
è suddivisibile in due parti. Il ciclo attivo dei documenti rappresenta l’insie-
me dei documenti prodotti dall’azienda. All’interno del ciclo attivo i dati in
possesso dall’azienda vengono concretizzati in documenti, ognuno dei quali
prodotto secondo un preciso layout. Per cui nel ciclo attivo l’azienda non
solo è in possesso del documento nel suo formato principale (PDF Searcha-
ble), ma possiede anche tutti i sorgenti dal quale è stato prodotto (dati del
database aziendale, layout, formati intermedi e interni come DOC, XPS,
XML).
Aziende Aziende
PDF
Layout
Documenti Dati
Documenti
PDF
PDF PDF
Ciclo Passivo
Ciclo Attivo
PDF
Figura 2.1: Ciclo attivo e passivo in un’azienda
4
2.1. Problematiche del ciclo passivo
Il ciclo passivo dei documenti riguarda invece l’insieme dei documenti ac-
quisiti dall’azienda. All’interno del ciclo passivo l’azienda possiede (nella
maggior parte dei casi) la sola copia cartacea dei documenti, la quale rap-
presenta una perdita d’informazione e d’usabilità rispetto alla versione di-
gitale. Il possesso di documenti in formato cartaceo rende estremamente
problematica l’acquisizione e l’archiviazione dei dati da parte dell’azienda.
Nel grafico in figura 2.1, come pure nel grafico in figura 2.2, le frecce in-
dicano dei processi. Alcune di esse sono tratteggiate proprio a sottolineare
una difficoltà nell’avanzamento del processo.
Dati Dati
Documento PDF
intermedio Searchable
Layout
PDF ?
Generatore PDF Immagine

di PDF Searchable raster OCR
PDF
Stampa Scanner
Documento
cartaceo
Figura 2.2: Produzione e acquisizione di un documento
5
2.1. Problematiche del ciclo passivo
Come è possibile vedere in figura 2.2, il processo di acquisizione dei dati

(che ha come input i documenti cartacei e come output i dati valorizzati)
utilizza strumenti inaffidabili (scanner e scanner OCR) che non permettono
di riottenere un sorgente pulito, ma anzi hanno una probabilità non indif-
ferente di introdurre ulteriori errori e perdita di qualità all’interno del do-
cumento. Documentale offre funzionalità per la conversione dei documenti
cartacei in PDF Searchable, affidando però all’utente il compito di associare
manualmente i dati a un PDF.
2.1.1 Modelli di mappatura

Per ovviare alla diversificazione nei layout (l’attività contrassegnata da un
punto di domanda in figura 2.2) ASI ha pensato di definire dei modelli di
mappatura. Un modello di mappatura è una struttura ricavata a partire dal
layout di un documento. Serve ad accomunare documenti simili fra loro, in
modo da poter poi estrarre dati sistematicamente fintanto che il modello di
mappatura risulta valido.
Dati Dati
Modello di
Layout mappatura
Documenti
Figura 2.3: Layout e modello di mappatura
Nel grafico sovrastante viene illustrata parte del ciclo di vita di un documen-
to, in particolare è evidenziato il parallelismo tra il layout (nella produzione
dei documenti) e il modello di mappatura (nell’acquisizione degli stessi).
Come il layout definisce una forma per i contenuti e ha per output un do-
cumento, allo stesso modo (ma nel verso opposto) il modello di mappatura
definisce una forma nel documento per riottenere i contenuti. Nel grafico
i documenti sono il formato di scambio (sia cartaceo che elettronico) tra
l’azienda che li emette a sinistra e l’azienda che li acquisisce a destra.
6
2.2. Problematiche dei PDF
Il modello di mappatura deve essere definito manualmente dall’utente. La

definizione di un modello di mappatura permette tuttavia l’analisi auto-
matizzata di tutti i documenti ad esso associati, introducendo perciò un
notevole miglioramento rispetto alla situazione precedente1 .
Per quanto questa soluzione sia già stata presa in considerazione dai pro-
gettisti ASI, Documentale non possiede ancora una gestione dei modelli di
mappatura.
2.2 Problematiche dei PDF

L’introduzione dei modelli di mappatura non risolve comunque il proble-
ma del ciclo passivo dei documenti, in quanto il formato PDF è in ogni
caso difficile da manipolare programmaticamente. In definitiva non risulta
immediata l’estrazione programmatica di porzioni di testo, l’estrazione di
attributi collegati ad esso, e l’affidabilità del testo estratto. L’introduzione
dei modelli di mappatura all’interno di Documentale è quindi vincolata alla
risoluzione di questi problemi, in quanto alla base dei modelli di mappatura
c’è appunto l’estrazione posizionale.
2.2.1 Estrazione del testo e dei suoi attributi

L’estrazione di testo da un documento PDF può avvenire oggigiorno (me-
diante l’utilizzo di soluzioni già pronte) in diversi modi, nessuno dei quali
però soddisfa le esigenze progettuali di ASI. È possibile estrarre del testo me-
diante selezione manuale, utilizzando software proprietario (Adobe Reader
per esempio), ma resta appunto una selezione manuale vincolata all’utilizzo
di un’interfaccia grafica. Esistono inoltre librerie sul mercato in grado di
estrarre programmaticamente il testo contenuto in una pagina, ottenendo
tuttavia il solo testo senza nessuno dei suoi attributi (posizione, valore se-
mantico, colore, stile).
Di fatto vi sono librerie (alcune di esse gratuite ed a sorgente aperto) in

grado di riconoscere non solo il testo, ma anche tutti gli attributi ad esso
collegati. Sono le librerie utilizzate per il rendering (la visualizzazione) dei
PDF.
1
Quella in cui l’utente associava (sempre manualmente) i dati ad ogni singolo
documento.
7
L’utilizzo di queste librerie non è stato preso in considerazione da ASI per

due motivi. Prima di tutto, le operazioni necessarie all’estrazione del testo
e dei suoi attributi sono differenti dalle operazioni necessarie al rendering
di un PDF, ragion per cui si sarebbe resa necessaria una costosa e non in-
differente operazione di modifica. In secondo luogo, rispetto alla vastità del
codice incluso nelle librerie, la qualità della documentazione allegata (defi-
nita anche in termini di commenti nel codice sorgente) si è spesso mostrata
insoddisfacente ed in molti casi quasi del tutto assente.
2.2.2 L’assenza di un layout fidato

Un’altra problematica fondamentale nell’estrazione del testo da file PDF è
l’affidabilità nell’estrazione posizionale. Nell’estrarre programmaticamente
il testo a partire da una data area nella pagina, è una pretesa ragionevole
voler essere certi che il testo estratto sia proprio quello contenuto nell’area.
Tale garanzia non esiste. Il grafico sottostante illustra proprio questo pro-
blema.
Modello di
mappatura
PDF
Dati e layout Processi

Intermedi Dati
PDF
PDF
PDF
Figura 2.4: Affidabilità dell’estrazione
Il modello di mappatura viene creato manualmente a partire da un docu-

mento acquisito dall’azienda, che ha quindi subito tutti i processi intermedi,
e che perciò ha un layout—con ogni probabilità—diverso dal layout di par-
tenza. Nell’applicare il modello di mappatura creato agli altri documenti
ottenuti dallo stesso layout iniziale, ci si può imbattere in incongruenze che
minano l’affidabilità del dato estratto. In altre parole, i processi che subisce
il documento dalla sua creazione alla sua acquisizione sono tali da poter
perfino ottenere dallo stesso documento iniziale due documenti diversi.
8
Supponendo di partire perfino dagli stessi dati2 , il layout del documento

(nella creazione del PDF, come pure nella stampa) può subire variazioni
apparentemente minimali eppur sufficienti ad invalidare il modello di map-
patura ad esso associato. Le variazioni nella posizione del testo sono tali per
cui la sola posizione non è più in grado di garantire l’affidabilità del dato
estratto.
2.2.3 L’assenza di una struttura logica

In altre tipologie di documento (definite con linguaggi di markup come XML
o HTML), il testo segue una struttura logica, ossia nel file del documento è
possibile trovare informazioni logiche sugli elementi testuali contenuti: tito-
li, paragrafi, elenchi puntati, tabelle, immagini. Ognuno di questi elementi
è associato al suo significato.
Titolo Titolo
Tabella
fi
Testo semplice Immagine
• Elemento Elenco puntato
• Altro elemento
HTML PDF
<h1> 1.000 g
Titolo 72.0000 72.0000 451.2756 697.8898 re f*
</h1> 72.0000 671.7566 151.7275 44.5332 re f*
<table bgcolor=#f3f3f3 border=1 bordercolor=#000000> ...
<tr> BT
<td> 72.0000 736.8495 Td
<img src="fi.png" alt= "fi (small ligature)" > /F1 18.0000 Tf
</td> (Titolo) Tj
<td> 36.0000 0.0000 0.0000 36.0000 75.0000 677.2898 cm
Testo semplice. /I1 Do
<br> 116.2500 702.5564 Td
<ul> /F2 10.0000 Tf
<li> (Testo semplice.) Tj
Elemento 144.7490 690.5564 Td
</li> ( • ) Tj
<li> 156.2500 690.5564 Td
Altro elemento (Elemento) Tj
</li> 144.7490 678.5564 Td
</ul> ( • ) Tj
</td> 156.2500 678.5564 Td
</tr> (Altro elemento) Tj
</table> ET
Figura 2.5: Differenza tra HTML e PDF
2
Di fatto i modelli di mappatura presuppongono di partire solamente dallo stesso
layout e non addirittura dagli stessi dati.
9
All’interno di un PDF tradizionale3 tuttavia non esiste alcuna struttura

logica. Il testo è organizzato in glifi, ognuno con una propria posizione,
dimensione, orientamento, inclinazione e colore. Le tabelle invece sono defi-
nite mediante tracciati vettoriali separati dal testo.
Nella figura precedente (2.5) viene illustrata la differenza tra la struttura

logica (come quella posseduta da un documento HTML) e la struttura pret-
tamente grafica posseduta da un documento PDF. Nella parte alta della
figura è visibile un esempio di documento costituito da un titolo e, da una
tabella contenente un’immagine e un elenco puntato.
In un documento HTML il testo è contenuto nella struttura logica. Ta-

belle, titoli ed elenchi puntati sono prima di tutto informazioni associate al
testo e solo successivamente (nel browser) rappresentazioni grafiche.
In un documento PDF invece tali elementi logici non esistono. La tabella

è pura rappresentazione grafica, completamente dissociata dal testo, tant’è
che la sua descrizione inizia e finisce prima della comparsa del testo. Ogni
altro elemento poi è reso dalla combinazione di caratteri, font e grandezze
dei font (l’operatore Tf definisce appunto un font da utilizzare e la sua gran-
dezza, la scritta “Titolo” in figura 2.5 è solo del testo scritto in grande per
un PDF).
Tale mancanza di struttura logica è dovuta alla natura stessa del formato
PDF. Il formato PDF nasce come formato di interscambio per i documenti.
Tra i requisiti della sua progettazione era forte la necessità di avere una
definizione di documento assoluta. Un layout che fosse indipendente dal
software e dall’hardware su cui era stato prodotto e su cui veniva visualizza-
to. Non era necessario che il documento possedesse una struttura logica, era
invece fondamentale che la copia stampata del documento fosse una fedele
riproduzione del documento digitale.
La soluzione adottata da Adobe fu quella di definire la posizione di ogni

elemento atomico (linea o glifo) in modo assoluto all’interno del sistema di
coordinate della pagina.
3
Il formato PDF prevede l’inserimento di XML all’interno del contenuto per dare
struttura logica e maggiore accessibilità ai PDF, lo standard ISO/AWI 14289 (PDF/UA)
si occupa proprio di questo. I Tagged PDF tuttavia non sono sufficientemente diffusi da
essere presi in considerazione nell’analisi del problema.
10
2.3. L’estrazione posizionale fidata
L’assenza di una struttura logica con cui percorrere il contenuto del file,
costringe una qualsiasi applicazione, che analizzi un PDF, a muoversi let-
teralmente alla cieca, identificando il testo solo per dove si trova e non per
cosa rappresenta a livello logico4 . Il fatto che il testo sia individuabile solo in
modo posizionale diventa quindi un serio problema considerata la mancanza
di un layout sicuro (vedi 2.2.2).
2.3 L’estrazione posizionale fidata

L’intenzione di ASI per il mio progetto di stage era proprio quella di trovare
e sviluppare una soluzione al problema del ciclo passivo dei documenti, in
modo tale da poterla integrare all’interno di Documentale. Ossia ottenere
degli strumenti (una libreria) per un analisi dettagliata del testo contenuto
in un PDF, in grado non solo di estrarre il testo da una determinata area
(ricavandosi quindi delle posizioni per il testo contenuto), ma capace inoltre
di sopperire alla mancanza di affidabilità (dovuta anche all’assenza di una
struttura logica), utilizzando i dati ricavati nella fase di analisi del PDF per
garantire l’esattezza del dato estratto.
Da parte di ASI c’era inoltre la necessità di avere una libreria ben docu-
mentata e ben progettata, in modo da essere in futuro facilmente estendibile
dall’azienda5 .
4
Una struttura logica permetterebbe di garantire l’estrazione di un dato in modo certo,
basandosi sul significato logico ad esso associato.
5
Tra le funzionalità che ASI vorrebbe integrare in Documentale c’è anche un ri-
conoscimento dei loghi aziendali nei documenti; è quindi interessata anche al futuro
riconoscimento di immagini in un PDF.
11
Capitolo 3
Attività di stage
In questo capitolo viene presentato un resoconto dell’attività di stage, ana-

lizzando i punti di forza e le criticità di ogni singola fase.
3.1 Studio del dominio applicativo

Nella prima fase dell’attività di stage ho dovuto acquisire tutta una serie di
conoscenze riguardanti .NET, C♯, WPF e Visual Studio. Le similitudini e
la somiglianza tra C♯ e Java, come pure tra C♯ e C++, mi hanno permesso
di familiarizzare fin da subito con questo nuovo linguaggio. Le ore di questa
fase sono state quindi dedicate, per la maggior parte, allo studio delle diffe-
renze e dei miglioramenti1 offerti da C♯ rispetto ai suoi diretti concorrenti.
Obiettivo di questa fase era inoltre l’assimilazione delle regole riguardan-

ti lo standard di codifica aziendale per C♯[4]. L’utilizzo di uno standard e
la sua conoscenza influenza positivamente la mantenibilità del codice e dei
documenti legati alla progettazione, promuovendo dei principi di design già
affermati, e obbligando gli sviluppatori a mantenere una certa unità nel co-
dice prodotto. L’utilizzo di uno standard di codifica migliora la produttività,
definendo delle linee guida rigorose nella nomenclatura, nella documentazio-
ne e nell’utilizzo di determinati costrutti sintattici.
1
C♯ introduce il concetto di “proprietà” di una classe. Le proprietà sono membri di
una classe che offrono funzionalità di lettura, scrittura, controllo e calcolo per i campi
dati privati di una classe. Una proprietà può essere utilizzata come un campo dati, ma
offre tutta la flessibilità di un metodo. C♯ inoltre permette di definire commenti XML
secondo una struttura ben precisa. Tali commenti, non solo possono essere utilizzati nella
generazione della documentazione (come avviene per il comando javadoc in Java), ma
anche da IntelliSense all’interno di Visual Studio per fornire un aiuto contestuale in fase
di codifica.
12
3.2. Analisi
In questo modo lo sviluppatore non indugia nelle scelte progettuali (avendo

direttive precise su come comportarsi) e non perde tempo nel capire il codice
altrui (in quanto tutto il codice aziendale segue le stesse regole2 ). L’adozione
di uno standard di codifica permette in aggiunta di evitare alcune tipologie
di errori e bug.
Lo standard di codifica adottato da ASI per C♯[4] risale alla definizione

di C♯ 1.0 da parte di Microsoft. Dennis Doomen che assieme a Vic Har-
tog ha definito lo standard di codifica adottato da ASI, nel marzo 2009, ha
pubblicato una versione aggiornata e rivista dello standard[5], prendendo in
considerazione anche le funzionalità aggiuntive introdotte fino a C♯ 3.0. Per
quanto dovessi attenermi al vecchio standard, ho ritenuto opportuno utiliz-
zare alcune delle regole del nuovo laddove nello standard aziendale veniva
lasciata libertà al programmatore.
3.2 Analisi
Durante la fase di analisi vi sono stati diversi incontri con l’azienda, rappre-
sentata dal tutor aziendale e da altri sviluppatori direttamente coinvolti o
interessati al progetto. Gli incontri non solo hanno permesso di individuare
i requisiti del progetto, ma anche di evidenziarne le criticità dello stesso. In
particolare fin dall’inizio erano state individuate e analizzate in dettaglio le
problematiche riguardanti la ricerca posizionale, date dalla combinazione di
un layout spesso variabile con l’assenza di una struttura logica (come de-
scritto nel capitolo precedente, vedi 2.2.2 e 2.2.3). La fase di analisi è inoltre
stata utile a fornire una visione d’insieme del problema, mediante diagram-
mi Use Case e diagrammi delle componenti (vedi figura 3.1), catalogando i
requisiti secondo diversi livelli di priorità a seconda delle necessità espresse
dall’azienda.
Nel diagramma sottostante (figura 3.1) sono rappresentate le componenti

di cui è costituita l’applicazione: MapManager, il quale si occupa della crea-
zione e della modifica dei modelli di mappatura (vedi capitolo precedente
2.1.1); MapFinder, che si occupa d’identificare il modello di mappatura da
utilizzare a partire da un dato PDF; e infine PdfAnalyzer che si occupa di
estrarre non solo i dati da un PDF, ma anche tutte le informazioni necessarie
a garantire l’esattezza del dato.
2
L’introduzione di uno standard di codifica per C♯ all’interno di ASI non è stata
immediata e, malgrado gli sforzi, parte del codice non aderisce tuttora alle nuove regole
aziendali.
13
3.2. Analisi
Lo studio del diagramma in figura 3.1 è stato fondamentale nella cataloga-

zione dei requisiti, il diagramma ha permesso d’identificare infatti le compo-
nenti prioritarie nell’applicazione, in modo da incentrare la fase successiva
sull’individuazione di una libreria di supporto per l’analisi dei PDF e sulla
progettazione della componente PdfAnalyzer.
cd: Visione di insieme
<< component>> << component, library >>

Visualizzatore Libreria di supporto
Applicazione
<< component>>
MapFinder
<< component>> << component>>

GUI PdfAnalyzer
<< component>>
MapManager
Figura 3.1: Diagramma generale delle componenti
14
3.3. Progettazione
Solo al termine della fase di analisi, quando già stava iniziando la fase di pro-
gettazione, è stato prodotto un documento contenente l’elenco dei requisiti
e i dettagli della fase appena conclusasi (studio delle criticità e definizione
delle priorità). Tale documento è stato in parte aggiornato e modificato
durante la prima metà della fase di progettazione.
3.3 Progettazione
La fase di progettazione è stata indubbiamente la fase principale all’interno
del mio progetto di stage. Di seguito vengono presentate le varie attività
su cui si è articolata. Ognuna delle seguenti attività è stata documentata
all’interno di un documento di specifica tecnica del prodotto, annotando:
scelte progettuali, risultati ottenuti, formalizzazioni UML, possibili sviluppi
futuri e limiti del prodotto. La specifica tecnica del prodotto è stata succes-
sivamente modificata in conseguenza alla campagna di test effettuata e alle
modifiche apportate al codice.
3.3.1 Individuazione di una libreria

La parte iniziale della fase di progettazione è stata incentrata nell’individua-
zione di una libreria di supporto all’analisi dei PDF. L’utilizzo di una libreria
all’interno del progetto avrebbe infatti permesso di risparmiare ore preziose
e usufruire di una porzione di codice già pronta, testata e documentata.
Nella fase precedente (analisi) era stato individuato il desiderio da parte

di ASI di utilizzare una libreria per l’analisi dei PDF, in modo da poter
poi concentrare il progetto di stage sul completamento della componente
PdfAnalyzer e sullo sviluppo delle componenti MapFinder e MapManager
(vedi figura 3.1).
15
3.3. Progettazione
La libreria da utilizzare doveva essere scelta in base ai seguenti criteri (in

ordine di priorità).
Licenza Fondamentale era la possibilità da parte di ASI

di utilizzare tale libreria all’interno di un software
commerciale come Documentale.
Funzionalità Quanto la libreria poteva essere utile al progetto3 , os-

sia che funzionalità offriva in termini di estrazione di
dati e contenuti a partire da un PDF, a quale livello di
dettaglio riusciva ad arrivare nell’estrazione dei dati4 .
Utilizzo di C♯ Vincolo fondamentale era la disponibilità della libreria

per il linguaggio C♯ (anche sotto forma di porting)5 .
Nel caso non fosse possibile era comunque accettabi-
le una libreria utilizzabile all’interno del framework
.NET.
Costo Non vincolante ma comunque importante era il costo

della libreria. Era sicuramente preferibile da parte del-
l’azienda l’utilizzo di una libreria gratuita, o con costo
moderato.
Documentazione Il livello di qualità della documentazione fornita per

la libreria, descrizione delle API ed esempi di codice.
Affidabilità Quanto la libreria poteva essere ritenuta affidabile6 .
3
In questo tipo di valutazione era importante considerare se la libreria in questione
era nata per risolvere questo tipo di problema, o se, nel risolvere un’altra tipologia di
problema, si ritrovava ad offrire funzionalità utili al progetto di stage.
4
In particolare era importante che la libreria permettesse di ottenere la posizione del
testo e il maggior numero di dati correlati ad esso, questo per risolvere le problematiche
presentate nel capitolo precedente, vedi 2.3.
5
Di fatto C♯ può far uso di librerie scritte anche in altri linguaggi, ma restava comunque
un requisito preferenziale l’identificazione di una libreria completamente scritta in C♯, in
quanto si sarebbe potuta rendere necessaria una modifica alla libreria da parte di ASI.
6
Nel valutare l’affidabilità di una libreria sono stati considerati: il team di sviluppo
(da quanti membri era composto, quali competenze avevano e se erano appoggiati da
una società o meno) e il progetto (da quanti anni era aperto, con che frequenza veniva
aggiornato e se attualmente era attivo o meno).
16
3.3. Progettazione
In base a quanto definito sopra, ho effettuato uno studio delle librerie presen-
ti in circolazione, scartando la maggior parte di esse per la mancanza di do-
cumentazione e/o affidabilità, soffermandomi in particolare su iTextSharp
e su PdfSharp.
La libreria iTextSharp è un porting C♯ di una libreria Java (iText).

iTextSharp è gratuita, a sorgente aperto, e può essere utilizzata all’inter-
no di applicazioni commerciali. iTextSharp—o meglio iText—nasce come
libreria per la creazione programmatica di PDF; offre tuttavia una scarsa
documentazione7 per le funzionalità di estrazione dati da essa offerte.
La libreria PdfSharp è una libreria gratuita, a sorgente aperto, e può es-

sere anch’essa utilizzata all’interno di prodotti commerciali. PdfSharp è
supportata da empira Software GmbH e nasce come libreria per la crea-
zione programmatica di PDF per il framework .NET. PdfSharp offre una
buona documentazione, oltre al sito infatti sono disponibili numerosi esempi
e un’ottima e completa descrizione delle API in formato CHM[2].
La qualità della documentazione è stata sicuramente il maggior fattore deci-

sionale che mi ha portato in ultima analisi all’utilizzo di PdfSharp all’interno
del progetto di stage8 .
PdfSharp pur essendo pensata principalmente per la creazione di PDF offre

tuttavia la possibilità di analizzare il contenuto interno dei PDF. Come è
possibile vedere in figura 3.2 un file PDF è sequenzialmente diviso in quat-
tro parti: l’Header, contenente le informazioni che identificano la versione
del formato PDF utilizzata; il File Trailer, che contiene le informazio-
ni principali sul documento (autore, date di creazione e modifica); la Cross
Reference Table, che permette di avere un accesso diretto (random access)
a tutti gli oggetti contenuti nel corpo del PDF; e infine il Body, che contiene
tutta la struttura interna del PDF.
7
La documentazione riguardante le API di iTextSharp è assente. Sul sito si rimanda
all’utilizzo della documentazione di iText prodotta con Javadoc, senza fornire nessuna
indicazione sulle diversità presenti tra le due librerie. iTextSharp essendo basata su C♯, fa
un largo uso delle proprietà laddove iText utilizza metodi “set” e “get”. Inoltre, differisce
nella nomenclatura (di metodi, classi, interfacce, proprietà e campi dati), seguendo quella
standard utilizzata da Microsoft per C♯.
8
A tal proposito l’azienda si è raccomandata di strutturare e documentare il progetto
di stage in modo che in un prossimo futuro sia possibile utilizzare un’altra libreria di
appoggio al posto di PdfSharp. ASI infatti ha già fatto uso di iTextSharp per altre sue
applicazioni, ed ha perciò avviato uno studio parallelo al mio, volto a valutare una possibile
sostituzione di PdfSharp con iTextSharp.
17
3.3. Progettazione
Tale struttura può essere notevolmente complicata in conseguenza a succes-

sive modifiche incrementali nel documento. PdfSharp permette di astrarre
completamente da questa iniziale struttura interna (sia essa semplice o com-
plessa), permettendo di accedere direttamente alle pagine del PDF, al loro
contenuto, agli encoding, e ai font utilizzati. PdfSharp tuttavia non essendo
stato pensato per l’analisi, ma per la creazione di PDF, non offre strumenti
che si spingano oltre la decifrazione dello stream del contenuto.
PDF Body
Header Catalog
Pages Pages Pages
Body
Page Page
Page
Fonts
Content
Font Font
Cross Reference Table
Stream Encoding Encoding

File Trailer
Figura 3.2: Struttura interna di un file PDF
3.3.2 L’analisi dello stream

In un file PDF esistono diversi tipi di stream. Uno stream rappresenta
un’unità atomica all’interno della struttura di un PDF, un tipo di dato
primitivo (come una stringa, un booleano o un numero). Uno stream è
sempre accompagnato da un filtro di codifica, in quanto (all’interno di un
PDF) rappresenta una sequenza di byte compressa. PdfSharp permette di
ottenerne la versione decompressa, come sequenza continua di byte.
18
3.3. Progettazione
Uno stream di contenuto (da qui in poi solo stream) va interpretato come
una sequenza di operatori e parametri (un esempio è visibile nella parte
destra della figura 2.5). Lo studio dello stream è una parte fondamentale
nell’analisi del testo di un PDF. Posizionamenti, font, colori, e lo stesso testo
sono contenuti infatti al suo interno.
Non sono presenti in circolazione librerie che analizzino il contenuto del-

lo stream e permettano di estrarre informazioni sulla posizione o su altri
attributi del testo contenuto9 . Esistono progetti in cui viene indicato come
interpretare alcuni dei comandi (costruendosi un proprio parser che analizzi
i singoli byte), ma sono ben distanti dal poter essere utilizzati come base in
un’applicazione aziendale, generalmente infatti si limitano a riconoscere una
decina di operatori, senza dare indicazioni su quali (e quanti) altri operatori
è possibile incontrare in uno stream.
Nella rete, nei progetti che ho preso in esame, nelle discussioni e negli artico-
li riguardanti questo argomento, sembra essere diffusa l’idea che il formato
PDF sia un formato chiuso. La maggior parte degli sviluppatori sembra
domandarsi come sia possibile sviluppare software in una situazione del ge-
nere e perché Adobe non fornisca un chiaro elenco degli operatori contenuti
in uno stream. La specifica del formato PDF[1] è in realtà consultabile e
scaricabile—non sorprendentemente in formato PDF—dal sito dell’Adobe.
3.3.3 La definizione della grammatica

L’utilizzo della specifica del formato PDF offre un elenco completo degli
operatori utilizzabili in uno stream, definendo per ognuno il funzionamen-
to e i parametri utilizzati. Da un lato quindi, la specifica[1] definisce in
modo chiaro come e quando possono essere usati tutti gli operatori di uno
stream, dall’altro rende improponibile lo sviluppo di un parser costruito da
zero. Conoscendo le problematiche legate alla realizzazione di un parser10 ,
e avendo già sperimentato i vantaggi di un compiler-compiler 11 , ho ritenuto
opportuno utilizzare ANTLRWorks nella realizzazione di un lexer e di un
parser per la grammatica definita nella specifica del formato PDF.
9
Esistono librerie in grado di farlo, come accennavo nel capitolo precedente (vedi
2.2.1), nello stesso capitolo tuttavia viene spiegato perché tali librerie non sono state
prese in considerazione all’interno del mio progetto di stage.
10
Le problematiche riguardanti la realizzazione di un parser, sono state almeno in parte
affrontate nello sviluppo del progetto per il corso di “Linguaggi di Programmazione”.
11
Conoscenze acquisite all’interno del progetto del corso di “Ingegneria del Software”.
19
3.3. Progettazione
stream WS generalGraphicStateOperator
specialGraphicStateOperator
pathConstructionOperator
pathPaintingOperator
clippingPathOperator
textObject
type3FontOperator
colorOperator
shadingPatternsOperator
inlineImageOperator
markedContentOperator
markedContentSequence
COMMENT WS EOF
Figura 3.3: Diagramma della struttura principale della grammatica
ANTLRWorks permette di definire una grammatica libera da contesto e di

generare in modo automatizzato un lexer e un parser per la grammatica
data (risparmiando tempo sia nella fase di codifica che in quella di verifica
e validazione). ANTLRWorks permette inoltre di inserire del codice C♯12
nella definizione della grammatica in modo da realizzare quello che viene
comunemente definito un “traduttore”, ossia un programma che converte
da un certo formato di dati a un altro.
In figura 3.3 è possibile vedere la struttura principale di uno stream. Uno

stream è composto da una sequenza di operatori separati da spazi bianchi13 ,
ognuno dei quali appartiene ad una delle categorie visibili nella colonna cen-
trale in figura 3.3.
12
ANTLRWorks permette di inserire all’interno della grammatica blocchi di codice
scritti nel linguaggio di destinazione della grammatica, ossia nel linguaggio in cui verranno
poi prodotti il lexer e il parser.
13
La specifica dei PDF[1] imporrebbe che gli operatori fossero ognuno su una linea
diversa del codice, ossia che fossero separati da caratteri come: “\n” (Line Feed), “\r”
(Carriage Return), “\r\n”, “\f” (Form Feed), “\u0085” (Next Line), “\u2028” (Line
Separator), “\u2029” (Paragraph Separator). Adobe tuttavia garantisce il funzionamento
anche di quei PDF in cui più operatori siano stati inseriti nella stessa linea.
20
3.3. Progettazione
Per l’analisi del testo e dei suoi attributi sono necessari e sufficienti gli
specialGraphicStateOperator e i textObject14. In particolare il primo
gruppo di operatori viene utilizzato per le operazioni sulle matrici posi-
zionali15 , push e pop dello stack delle matrici e modifica della matrice di
trasformazione corrente (CTM). Il secondo gruppo invece rappresenta gli
oggetti di testo (text objects).
textObject
BT WS textStateOperator
textPositioningOperator
textShowingOperator
colorOperator
COMMENT WS ET
Figura 3.4: Diagramma della struttura di un oggetto di testo.
Ogni text object può contenere una sequenza qualsiasi di operatori purché
siano: operatori di stato, operatori di posizionamento, operatori di stampa
oppure operatori di colore. Esclusi gli operatori di colore (per i quali non
c’è un’immediata necessità, considerando che i documenti contabili di un’a-
zienda sono perlopiù monocromatici), gli altri tre gruppi di operatori sono
riconosciuti in dettaglio all’interno della grammatica.
3.3.4 Estrazione posizionale di testo

La progettazione della grammatica è stata affiancata alla progettazione delle
classi che sarebbero andate ad accogliere i dati estratti una volta effettuata
l’analisi.
14
Gli altri gruppi di operatori sono comunque riconosciuti nella grammatica, ma
nessuno di essi viene realmente utilizzato nell’estrazione di dati dallo stream.
15
Il posizionamento del testo all’interno di un file PDF è ottenuto mediante manipo-
lazioni di matrici 3 x 3. Per posizionare il testo in una pagina vengono utilizzate cinque
matrici: la matrice di posizionamento del testo (text matrix Tm ), la matrice di posizio-
namento di linea del testo (text line matrix Tlm ), la matrice di trasformazione del testo
(current transformation matrix CTM ), una matrice di stato temporanea (state matrix) e
infine una matrice di rendering temporanea, utilizzata per calcolare la posizione di ogni
carattere nella pagina.
21
3.3. Progettazione
Plain.File.Extraction è il package progettato per l’analisi del PDF, il

parsing degli stream contenuti in esso, l’estrazione del testo e dei suoi at-
tributi. Plain.File.Extraction concretizza la componente PdfAnalyzer
visibile in figura 3.1, offrendo tutte le funzionalità necessarie all’analisi dei
PDF e all’estrazione posizionale di testo.
Come è possibile vedere nella figura 3.5, Plain.File.Extraction è costi-

tuito da una serie di classi atte ad immagazzinare (e rendere disponibili) i
dati riguardanti una pagina, il testo contenuto in essa, e i font utilizzati.
cd: Plain.File.Extraction
Plain.File.Extraction
PdfTextStreamLexer
PdfAnalyzer
PdfTextStreamParser
PdfPage PdfChar
PdfText
PdfFont
Figura 3.5: Diagramma delle classi in Plain.File.Extraction
Le classi principali del package sono PdfAnalyzer e PdfPage (evidenziate in

verde nella figura), queste due classi costituiscono infatti l’interfaccia ester-
na di Plain.File.Extraction.
22
3.3. Progettazione
Il lexer e il parser sono classi ottenute principalmente16 dalla definizione del-

la grammatica, il resto delle classi invece (ossia PdfFont, PdfText e PdfChar
sono strutture utilizzate solo internamente al package.
3.3.5 PdfAnalyzer
PdfAnalyzer è la classe principale del package Plain.File.Extraction.
L’applicazione che utilizza Plain.File.Extraction possiede una sola istan-
za della classe PdfAnalyzer. PdfAnalyzer implementa quindi il design pat-
tern Singleton. Il principale utilizzo di PdfAnalyzer è quello di ottenere
degli oggetti PdfPage. Solo PdfAnalyzer può costruire correttamente un’i-
stanza di PdfPage a partire da un dato PDF.
PdfAnalyzer offre all’esterno del package le seguenti funzionalità:
• OpenDocument(string path), apre un documento, di fatto memoriz-

za il path del documento, la sua apertura avviene solo nel momento
in cui viene richiesta una pagina.
• GetPage(int number), ritorna un oggetto PdfPage corrispondente al-

la pagina indicata. PdfAnalyzer ricava le dimensioni della pagina, re-
cupera i font e gli encoding utilizzati (costruendo degli oggetti PdfFont
associati alla pagina), e infine utilizza il lexer e il parser della gramma-
tica per ottenere il testo contenuto nella pagina. GetPage implementa
il design pattern façade, fornendo un unico metodo semplice a fronte
di una complicata serie di invocazioni ed istruzioni.
Si può dire che PdfAnalyzer implementi anche il design pattern Front

Controller, sebbene generalmente utilizzato nelle applicazioni web, tale
design pattern fornisce un punto d’entrata centralizzato, attraverso il quale
tutte le invocazioni devono passare. L’unico modo di ottenere una pagina è
infatti quello di passare dall’istanza di PdfAnalyzer.
PdfAnalyzer utilizza un efficiente sistema di cache interne, grazie al qua-

le è possibile migliorare i tempi di risposta per una pagina già analizzata
(fintantoché l’applicazione non viene chiusa). Ogni qual volta infatti vie-
ne richiesta una pagina, PdfAnalyzer verifica se la pagina richiesta (per il
documento correntemente aperto) è già stata analizzata, e solo in caso di
insuccesso analizza la pagina salvandola poi nella cache interna.
16
PdfTextStreamParser (oltre ai metodi e campi dati generati in modo automatico
a partire dalla grammatica) possiede anche una serie di metodi e strutture di supporto
progettate apposta per poter manipolare ed ottenere dei dati dagli stream contenuti in un
PDF.
23
3.3. Progettazione
3.3.6 PdfFont, PdfChar e PdfText

PdfFont Istanze della classe PdfFont vengono associate alla classe PdfPage
dal PdfAnalyzer. Un PdfFont racchiude informazioni riguardanti il nome
del font utilizzato, l’encoding e le dimensioni dei glifi del font. Nel calcolare
la posizione di ogni carattere, bisogna infatti tener conto della larghezza del
glifo associato al carattere precedente17 . L’encoding contenuto in un font
serve da traduttore per i caratteri di una stringa. A seconda dell’encoding
utilizzato il carattere con valore numerico pari a 174 può corrispondere infat-
ti al carattere “Æ”, oppure al carattere “fi” (come unico carattere), oppure
al carattere “o”18 .
PdfChar Un PdfChar rappresenta un carattere posizionale all’interno di

un PDF, è costituito infatti da una coppia di coordinate cartesiane e da un
carattere di testo (char).
PdfText PdfText rappresenta una stringa e corrisponde all’invocazione di

un’operatore di stampa all’interno dello stream. Indicativamente all’interno
di una pagina è necessario invocare l’operatore di stampa ogni qual volta
viene modificato un attributo del testo19 .
Volendo, un operatore di stampa può essere invocato per ogni singolo ca-
rattere contenuto in una pagina. I generatori di PDF attualmente in circo-
lazione tuttavia tendono ad invocare l’operatore di stampa quando cambia
uno degli attributi del testo e quando si va a capo nella pagina. In quest’ot-
tica, un’istanza di PdfText corrisponde ad una sequenza di testo disposto
su un’unica riga e che utilizza un set comune di attributi.
3.3.7 Lexer e Parser

PdfTextStreamLexer Questa classe rappresenta il lexer della gramma-
tica degli stream. PdfTextStreamLexer è generato in modo automatizzato
a partire dalla grammatica e non vi è stato nessun tipo di intervento su
questa classe.
17
Questo discorso viene gestito in maniera più efficiente per i font “monospace”, quei
font cioè che mantengono la stessa distanza per ogni glifo.
18
Addirittura è possibile definire un array di sostituzioni completamente arbitrario, nel
qual caso il carattere con valore numerico intero pari a 174 può rappresentare un qualsiasi
carattere Unicode.
19
Sono attributi del testo: il font, la grandezza del testo (size), la spaziatura tra le
lettere (char spacing), la spaziatura tra le parole (word spacing), la spaziatura tra una
riga e l’altra (text leading), l’offset verticale di un carattere (text rise) e il colore.
24
3.3. Progettazione
PdfTextStreamParser PdfTextStreamParser rappresenta il parser per

la grammatica degli stream. Pur essendo questa classe generata a partire
dalla grammatica, è stata necessaria una buona progettazione in quanto si
occupa di tradurre il contenuto di uno stream in una lista di PdfText. La sola
grammatica genera infatti un parser in grado di produrre un AST (Abstract
Syntax Tree) da uno stream. È necessario perciò modificare la grammatica
in modo che, utilizzando una serie di strutture di supporto (perlopiù matri-
ci), riesca a produrre l’output desiderato.
3.3.8 PdfPage
PdfPage è l’altra classe, oltre a PdfAnalyzer, disponibile all’esterno del pac-
kage Plain.File.Extraction. Un’istanza di PdfPage contiene una lista di
PdfFont e una lista di PdfText. PdfPage permette di analizzare il contenu-
to estratto da una pagina, ottenendo non solo il testo posizionale contenuto
nella pagina, ma anche tutti gli attributi ad esso connessi.
3.3.9 Affidabilità del dato estratto

Il problema dell’affidabilità nell’estrazione dei dati come descritto nel capi-
tolo precedente (vedi 2.2.2 e 2.2.3) viene quindi risolto dall’utilizzo dei dati
aggiuntivi ricavati da PdfPage e PdfAnalyzer.
Fattura A
Tabella contenente i vari elementi della fattura.
Totale: 198.509,08 €
1.0000 g
BT Modello di mappatura
74.2500 704.5730 Td Posizione iniziale del dato (x,y). 1
/F2 10.0000 Tf Posizione finale del dato (x,y) 2
174.7979 677.5730 Td
Preceduto dalla stringa "Totale:". 3
(Totale:) Tj
208.1475 677.5730 Td Posizione del primo carattere. 4
/F1 10.0000 Tf Utilizza un font sans, grande 10. 5
(198.509,08) Tj È un numero decimale positivo. 6
260.9746 677.5730 Td
/F2 10.0000 Tf È seguita dalla stringa "€ ". 7
(€) Tj
ET
74.2500 702.4538 201.7822 11.1719 re È posizionato sotto una linea. 8
Figura 3.6: Come garantire l’esattezza del dato estratto
25
3.3. Progettazione
Durante la definizione del modello di mappatura l’utente fornisce le coor-

dinate dell’area in cui è contenuto il dato da estrarre, mentre l’analisi del
PDF da parte del programma recupera (da PdfPage) tutta una serie di dati
supplementari (tra cui gli attributi del testo) utili a garantire l’esattezza del
dato estratto. Come è possibile vedere in figura 3.6 il programma è in grado
di ricavare, mediante analisi, le informazioni 3, 4, 5, 6, 7 e 8, che vanno
ad aggiungersi alle informazioni 1 e 2 fornite dall’utente nella definizione
dell’area in cui va cercato il dato.
I dati forniti dal programma (dal numero 3 al numero 8 in figura 3.6) devo-
no essere in questa fase verificati dall’utente, il quale segnala al programma
quali degli elementi trovati fanno parte del layout originario, e quali invece
sono errori dovuti ai processi intermedi. Questa fase della definizione di un
modello di mappatura è fondamentale, in quanto, maggiore è l’attenzione
posta dall’utente nel verificare i dati proposti dal programma, maggiore sarà
l’affidabilità dell’analisi automatizzata del programma.
In quest’ottica gli elementi confermati rappresentano precisamente l’affida-

bilità del dato estratto. Testando il dato in base agli elementi trovati è
possibile definire infatti un valore di affidabilità in base al numero dei test
superati da quel dato. In figura 3.7 è possibile vedere come i dati ottenu-
ti dal programma e verificati dall’utente riescano a garantire l’esattezza (o
meno) del dato estratto.
Fattura A 1 2 3 4 5 6 7 8 Affidabilità
Tabella contenente i vari elementi della fattura.
100%
Totale: 198.509,08 €
Fattura B 1 2 3 4 5 6 7 8 Affidabilità
Tabella differente dalla tabella precedente.
62%
Totale: 8919,85 €
Fattura C 1 2 3 4 5 6 7 8 Affidabilità
Tabella in cui sono contenuti dei numeri, per esempio:
Spese di cancelleria 8,09 € 37%
Totale: 5189,82 €
Figura 3.7: Misura d’affidabilità per il dato estratto
26
3.3. Progettazione
Maggiore il numero dei dati verificati, maggiore sarà la precisione nella mi-
sura d’affidabilità per il dato da estrarre. Sarebbe inoltre possibile definire
un peso diverso per ogni test. Per esempio in figura 3.7 sarebbe plausibi-
le dare più importanza al test numero 3 (L’elemento è preceduto dalla
stringa "Totale"), in quanto il superamento del test numero 3 negli esem-
pi di fattura proposti garantisce maggiormente l’esattezza del dato rispetto
agli altri test.
In base ai dati raccolti (e alle impostazioni dell’utente) l’applicazione può

decidere inoltre come comportarsi durante l’estrazione automatizzata dei
dati. In caso di fallimento nell’estrazione di un dato sarebbe possibile in-
fatti ignorare i test 1 e 2 (ignorare quindi la posizione del dato una volta
constatato il fallimento posizionale) e utilizzare solo gli altri test per l’indi-
viduazione del dato (avviando quindi una ricerca non-posizionale).
3.3.10 Limiti dell’applicazione

Per quanto il package Plain.File.Extraction offra una solida base per
la risoluzione del problema del ciclo passivo dei documenti, possiede tut-
tavia dei limiti. La libertà nella definizione di un file PDF (in particolare
la libertà offerta nella definizione degli encoding e degli stream) limitano
l’effettivo utilizzo di Plain.File.Extraction. Per quanto la grammatica
riconosca la quasi totalità degli operatori PDF, esistono tuttavia diverse va-
rianti degli operatori di posizionamento e di stampa non ancora supportate.
Plain.File.Extraction supporta i quattro encoding standard in un PDF[1]:

lo StandardEncoding, il MacRomanEncoding, il WinAnsiEncoding e infine il
PDF-DocEncoding; supporta inoltre la definizione di un array di differenze
per la modifica in dettaglio dell’encoding. Per quanto la presenza di un’array
di differenze garantisca di fatto piena libertà nella definizione dell’encoding,
alcuni generatori di PDF utilizzano degli oggetti CMap (definizioni assoluta-
mente arbitrarie) come encoding per il contenuto delle pagine. Tale tipologia
di definizione non è ancora riconosciuta dal programma.
27
3.4. Codifica
Plain.File.Extraction non è in grado poi di calcolare posizioni esatte per

i “14 font standard”20 , in quanto le informazioni riguardanti questi font non
vengono incluse nel file PDF21 , ma vanno ricercate all’interno dei font del
sistema operativo.
PdfSharp inoltre non supporta alcuni PDF dalla versione 1.6 della speci-
fica. Non è ancora in grado infatti di leggere il nuovo tipo di struttura
interna (iRef) adottata da tali PDF22 .
3.4 Codifica
L’implementazione delle classi di Plain.File.Extraction non è stata una
fase particolarmente onerosa all’interno dell’attività di stage. Gran parte del
codice è stato sviluppato velocemente a partire dal diagramma delle classi
e dai diagrammi di attività prodotti in fase di progettazione. Vi sono state
alcune modifiche alle classi in conseguenza all’individuazione di bug nella
fase di test, ma in linea di massima nella fase di codifica mi sono limitato a
seguire quanto progettato nella fase precedente.
Tra le attività svolte nella fase di codifica c’è stata anche la modifica della
grammatica. ANTLRWorks permette infatti di definire le proprie operazioni
di traduzione direttamente in linea, affiancandole alle regole della gramma-
tica23 . In questo modo, sono state modificate tutte le regole necessarie
all’estrazione del testo e dei suoi attributi.
20
Si tratta di quattordici font riconosciuti da Adobe come standard comune ad ogni
sistema operativo, per i quali quindi non vengono incluse le definizioni e le grandezze dei
glifi all’interno dei file PDF. In particolare i font sono: “Times” (versione 3) nei formati
normale, grassetto, corsivo e grassetto-corsivo; Helvetica (vesrione 3) nei formati normale,
grassetto, corsivo e grassetto-corsivo; Courier nei formati normale, grassetto, corsivo e
grassetto-corsivo; Symbol; e Zapf Dingbats. In alternativa a “Times” è possibile usare
anche “Times New Roman PS MT” (versione 4.x), mentre in alternativa ad “Helvetica”
è possibile anche utilizzare “Arial MT” (versione 4.x).
21
Dalla versione 1.5 dello standard PDF l’esclusione delle definizioni dei “14 font stan-
dard” è deprecata. Ogni font utilizzato in un PDF deve essere incluso all’interno del PDF
stesso. Tuttavia per retrocompatibilità sono considerati PDF validi anche i PDF che non
includono le definizioni per questi font.
22
PdfSharp permette comunque di analizzare tutti i PDF con versione superiore alla
1.5 che siano stati prodotti mantenendo la compatibilità con la versione 1.5 della specifica.
23
Grazie a questa funzionalità è possibile per esempio che il parser, una volta incon-
trato un operatore di posizionamento, esegua le istruzioni fornite in modo da ottenere
informazioni sulla posizione raggiunta in quel punto dello stream.
28
3.5. Verifica e validazione
Al termine dell’attività di codifica è stato prodotto un documento di descri-

zione delle API di Plain.File.Extraction, generato utilizzando Sandcastle
a partire dai commenti XML inseriti nel codice.
3.5 Verifica e validazione

Nella fase di verifica e validazione mi sono preoccupato di controllare se tut-
ti i requisiti individuati erano stati soddisfatti. Sono stati inoltre utilizzati
una serie di test case (realizzati in fase di progettazione) all’interno di AN-
TLRWorks per verificare il funzionamento della grammatica. Si è trattato
tuttavia di un test manuale nel quale venivano lanciati in sequenza esempi
di stream all’interno dell’interprete PDF, confrontando il risultato ottenuto
con l’output atteso.
Le classi di Plain.File.Extraction come pure le traduzioni effettuate dal

parser sono state inizialmente testate utilizzando degli stub e dei driver.
Una volta integrate fra loro le varie classi, il package è stato testato median-
te l’utilizzo di una classe driver. Tale classe a partire da alcuni PDF cercava
di ottenere il testo contenuto in diverse aree della pagina e gli attributi ad
esso associati. Tuttavia questa metodologia di test si è rivelata inefficiente
a causa del tempo necessario alla progettazione di nuovi test case (il tempo
impiegato ad individuare manualmente le coordinate delle aree da cui estrar-
re i dati). Non appena infatti è stato possibile integrare anche un’interfaccia
grafica minimale24 ho potuto eseguire un numero maggiore di test anche se
non rigorosi e precisi come quelli effettuati automaticamente.
24
La descrizione dell’utilizzo dell’interfaccia grafica minimale è stata illustrata nel ma-
nuale utente consegnato all’azienda. Data l’assenza di un’interfaccia grafica complessa,
la maggior parte della documentazione riguardante Plain.File.Extraction è contenuta
tuttavia nella specifica tecnica e nella descrizione delle API. Il manuale utente descrive
invece l’utilizzo della GUI minimale in cui è stato integrato Plain.File.Extraction.
29
3.6. Preventivo e consuntivo
3.6 Preventivo e consuntivo

Nel diagramma in figura 3.8 è visibile la distribuzione delle attività all’in-
terno di ogni fase (numerate dall’uno al sei).
Studio del dominio Codifica

Analisi Verifica e validazione
Progettazione Documentazione
70
60
50
40
30
20
10
0
1 2 3 4 5 6
Studio del Analisi Progettazione Codifica Verifica e Documentazione
dominio validazione
Figura 3.8: Dettaglio delle fasi
Il modello di ciclo di vita seguito all’interno dello stage è stato il modello

evolutivo. Tale modello sarebbe normalmente basato su una forte prototi-
pazione25 . Tuttavia non vi è stato nessuno sviluppo di prototipi intermedi,
l’attività di codifica è cominciata a metà dello stage. Vi sono stati inve-
ce ripetuti confronti con l’azienda nelle fasi di analisi e progettazione, che
hanno portato a modificare i requisiti iniziali individuati per il prodotto.
Il protrarsi dell’attività di codifica e dell’attività di progettazione fin quasi
al termine dello stage è dovuto all’introduzione (in parallelo) dell’attività
di testing e dell’attività documentativa all’interno delle fasi tre e quattro
(figura 3.8).
L’attività di verifica e validazione è stata portata avanti fin dall’inizio, questo

ha permesso di ridurre—a mio avviso—le ore dedicate alla codifica (corret-
tiva) all’interno della fase cinque (figura 3.8).
25
Il modello di ciclo di vita—detto evolutivo—si basa sulla rapida realizzazione di una
versione semplificata del prodotto, con la quale sperimentare ed esplorare nuovi requisiti
e funzionalità da aggiungere allo stesso. La verifica e il testing del prototipo possono
infatti portare all’aggiunta o alla rimozione di requisiti costringendo di conseguenza lo
sviluppatore a riaffrontare le fasi di: analisi, progettazione, sviluppo e test.
30
Un discorso analogo può essere fatto per l’attività di documentazione. L’at-

tività documentativa si è affiancata fin dall’inizio alle altre attività, in parti-
colare nel grafico in figura 3.8 è possibile vedere come l’attività di documen-
tazione abbia un’andamento simile a quello dell’attività progettuale. L’in-
serimento dell’attività documentativa all’interno delle altre fasi ha permesso
di costruire la documentazione del prodotto mentre esso veniva progettato,
evitando di trovarsi a scrivere la documentazione solo a prodotto finito26 .
Nel grafico in figura 3.9 è possibile vedere la differenza tra le ore preven-
tivate per ogni attività e le ore effettivamente dedicate ad ognuna di esse.
Nell’ottenere il grafico sono state considerate per ogni attività (analisi, pro-
gettazione, codifica, eccetera) le ore dedicate all’interno di ogni fase.
Preventivo
Consuntivo
70
60
50
40
30
20
10
0
Studio del Analisi Progettazione Codifica Verifica e Documentazione
dominio validazione
Figura 3.9: Preventivo e consuntivo a confronto
Nel grafico, le ore effettive per l’attività di studio del dominio sono inferiori
alle ore preventivate, questo perché lo studio di C♯, .NET e WPF non è stato
particolarmente oneroso, inoltre parte dello studio della specifica PDF[1] è
stato conteggiato all’interno delle ore di progettazione.
26
Documentare il prodotto mentre viene progettato non significa avere, per esempio,
una specifica tecnica pronta al termine dell’attività di progettazione. La documentazione
prodotta serve come base per il documento da produre, il quale può venire comunque
redatto al termine dell’attività in questione. Documentare i propri progressi mentre si
progetta e commentare il codice man mano che lo si scrive, serve ad evitare di trovarsi a
prodotto concluso difronte a del codice privo di documentazione. In situazioni del genere
le ore che vengono di norma impiegate nel tentativo di documentare il codice sono di gran
lunga superiori alle ore perse nel documentarlo mentre veniva prodotto.
31
Le ore dedicate all’attività di analisi sono state anch’esse inferiori a quelle

preventivate in quanto parte dell’analisi era già stata svolta dall’azienda.
Infine nel grafico è possibile vedere come lo sforzo dedicato all’attività di
progettazione abbia permesso di ridurre le ore effettive di codifica.
32
Capitolo 4
Valutazione retrospettiva
4.1 Conseguimento degli obiettivi fissati

Gli obiettivi fissati per il progetto di stage non sono stati raggiunti. Il mio
progetto di stage come descritto nel capitolo 2, doveva occuparsi della pro-
gettazione e dello sviluppo di una componente in grado di definire e gestire
dei modelli di mappatura (vedi 2.1.1).
Tale componente avrebbe poi dovuto utilizzare i modelli creati, per l’estra-
zione automatizzata di dati da file PDF. ASI avrebbe inoltre gradito uno
studio e una proposta di interfaccia grafica che rendesse più facile e intuitivo
il processo di definizione dei modelli di mappatura.
Tuttavia verso la fine della fase di analisi ci si è resi conto di aver sotto-
valutato il problema1 , ed è stato deciso quindi di portare avanti la base del
progetto (Plain.File.Extraction) e utilizzare le eventuali ore avanzate
per dare valore aggiunto al package e alla documentazione ad esso allegata.
1
ASI si aspettava di trovare una struttura logica all’interno dei PDF, o comunque
un’altro tipo di struttura che permettesse di risolvere il problema dell’affidabilità, e potersi
fin da subito concentrare sulla creazione e gestione dei modelli di mappatura.
33
4.2. Conoscenze acquisite
L’analisi degli stream si è rivelata più complessa di quanto preventivato a

causa dell’estrema libertà permessa all’interno di un file PDF. Di conseguen-
za non è stato possibile affrontare in dettaglio il problema dell’affidabilità, il
quale si presentava particolarmente interessante2 . Ho potuto infatti fornire
soltanto un’approccio parziale al problema (vedi 3.3.9).
4.2 Conoscenze acquisite

L’attività di stage mi ha portato ad acquisire numerose conoscenze durante
la fase di studio, ma anche durante le attività di analisi e progettazione.
Sono ora in possesso di una buona conoscenza di base per quanto riguar-
da: il framework .NET (vantaggi e svantaggi, funzionamento, linguaggi
supportati, librerie e strutture dati); il linguaggio di programmazione C♯
(definizione delle classi, utilizzo delle proprietà, utilizzo dei commenti XML
e integrazione con WPF); WPF (definizione di interfacce grafiche e utilizzo
in architetture asincrone). Tali conoscenze—seppur non complete—ritengo
siano comunque una solida base su cui sviluppare studi futuri.
Ho inoltre acquisito familiarità con gli ambienti di sviluppo Microsoft quali

Visual Studio (utilizzo dell’editor grafico per WPF, utilizzo degli strumen-
ti di debug, utilizzo di IntelliSense in combinazione con i commenti XML)
e Sandcastle (produzione di documentazione in formato CHM, personaliz-
zazione della documentazione in termini di layout e di classi incluse, utilizzo
dei commenti XML all’interno della documentazione prodotta).
Seppur avessi già utilizzato ANTLR e ANTLRWorks, durante il periodo

di stage ho approfondito le mie conoscenze al riguardo. La definizione del-
la grammatica degli stream si è dimostrata assai più complessa delle altre
grammatiche su cui avevo lavorato in precedenza. Ha richiesto infatti molta
attenzione nel disambiguare alcune delle regole.
2
Il programma avrebbe dovuto far uso di un’intelligenza artificiale nel fornire la lista di
dati ausiliari all’utente, nella definizione del modello di mappatura (vedi 3.3.9), fornendo il
più possibile dati inerenti al testo, e ricavando informazioni aggiuntive dalla comparazione
dei dati ottenuti dallo stream. C’era inoltre la possibilità, di utilizzare la verifica da parte
dell’utente dei dati proposti, per permettere al programma di migliorarsi. La necessità
da parte di ASI è tuttora quella di avere un software che con un input minimo da parte
dell’utente riesca ad ottenere un modello di mappatura preciso e sicuro; per ottenere ciò
il programma avrebbe dovuto sfruttare ogni conferma dell’utente, combinarla con gli altri
dati in suo possesso e fornire informazioni migliori all’utente stesso.
34
Ho inoltre acquisito conoscenze specifiche nell’utilizzo delle “actions” (istru-

zioni in C♯ inserite direttamente all’interno della grammatica)3 .
Nel processo di decodifica ho affrontato in prima persona il problema degli

encoding, in particolare all’interno di questo ambito ho acquisito conoscenze
specifiche per quanto riguarda: la differenza tra byte, carattere associato a
un byte e glifo associato a un carattere; i principali encoding[1]; la diffe-
renza tra ASCII e ANSI4 ; lo standard Unicode; il supporto dei font per gli
encoding5 .
4.2.1 ISO 32000

La maggior parte delle conoscenze acquisite riguardano però lo standard
ISO 32000, comunemente conosciuto come il formato PDF. All’interno del
progetto di stage ho potuto (e dovuto) esplorare in dettaglio la specifica
del formato PDF[1]. Ho acquisito conoscenze riguardanti: la struttura in-
terna dei documenti PDF (l’Header, il File Trailer, la Cross Reference
Table); le tipologie di dato contenute in un file PDF (booleani, stringhe,
numeri6 , nomi7 , array, dizionari8 e stream); la definizione degli oggetti al-
l’interno di un PDF (pagine, font, encoding, contenuti, spazi dei colori).
3
Le “actions” in ANTLR sono appunto blocchi di codice definiti nel linguaggio di
destinazione della grammatica (il linguaggio con cui verrà poi generato il parser). Le
“actions” vengono inserite direttamente all’interno della grammatica e permettono di per-
sonalizzare l’attività del parser. Esistono delle regole precise per integrare le istruzioni C♯
con il linguaggio utilizzato da ANTLR per definire la grammatica[3].
4
Generalmente si tende a confondere l’ASCII con l’ANSI. L’ASCII è un encoding
composto da 128 caratteri (alcuni di essi sono caratteri non stampabili di controllo),
mentre l’ANSI è la codifica generalmente utilizzato nei sistemi Microsoft Windows ed è
costituito da 256 caratteri (i primi 128 appartengono in effetti alla codifica ASCII).
5
Un font può essere sprovvisto dei glifi corrispodenti ad alcuni caratteri. L’utilizzo di
Unicode all’interno di un programma non garantisce quindi il supporto di ogni carattere
in quanto l’unico modo per rendere visibile un carattere all’occhio umano è l’utilizzo di un
font. Se il font non possiede il glifo corrispondente al dato carattere, quel carattere non
può essere visualizzato, in questo senso il processo di decodifica di una stringa non può
assolutamente astrarre dal font utilizzato nella visualizzazione del testo.
6
All’interno di un file PDF non vi è distinzione tra interi e reali, un “numero” può
infatti essere accompagnato o meno da un segno e accompagnato o meno da una parte
decimale.
7
Un nome all’interno del formato PDF è una stringa (preceduta dal carattere “/”),
serve per identificare risorse quali font e immagini (un font con nome “/F3” viene utilizzato
in uno stream richiamando appunto il suo identificativo “/F3 10 Tf”). Viene inoltre
utilizzato per identificare delle costanti all’interno di un PDF, per esempio è possibile
trovare una definizione del genere “Encoding /WinAnsi”, in questo caso “/WinAnsi”
indica una costante interna del formato PDF.
8
Il termine dizionario si riferisce ad una struttura informatica per la collezione di dati,
nella quale ad ogni elemento chiave corrisponde un altro elemento. All’interno dei PDF
la quasi totalità degli oggetti è costituita da dizionari, nei quali a determinate keyword
corrispondono determinate definizioni.
35
Nello studio poi degli stream di contenuto ho acquisito familiarità con: gli
operatori riguardanti le matrici di posizionamento; gli oggetti di testo con-
tenuti all’interno di uno stream; gli operatori di stato del testo (Tc, Tw, Tz,
TL, Tf, Tr e Ts); gli operatori posizionali del testo (Td, Tm e T*); gli operatori
di stampa (showing) del testo (Tj, ’, " e TJ)9 .
La ricerca del testo posizionale, mi ha posto a diretto contatto infine con i

meccanismi di rendering (posizionamento a video) del testo all’interno del
formato PDF.
4.2.2 PDF/UA e PDF/A

All’interno del progetto di stage ho avuto modo di conoscere alcune delle
varianti del formato PDF. L’assenza di una struttura logica come descritto
nel capitolo 2 (vedi 2.2.3) si è dimostrata un forte impedimento nella ma-
nipolazione dei file PDF. Adobe, resasi conto di questa profonda mancanza
all’interno del formato PDF (la mancanza di una struttura logica rende i
PDF di fatto inaccessibili), ha iniziato a lavorare assieme ad AIIM (Asso-
ciation for Information and Image Management) allo standard ISO/AWI
14289 (Aprile 2009), definendo il formato PDF/UA (PDF/Universal Ac-
cessibility).
La necessità da parte delle aziende di integrare l’archiviazione sostituiva

a norma nei processi aziendali ha spinto Adobe a sviluppare un’altro tipo di
standard. Già a partire dal 2005 infatti è stato definito l’ISO 19005-1, che
prende il nome di PDF/A. I PDF/A sono un formato per l’archiviazione a
lungo termine dei documenti elettronici. PDF/A costituisce un sottoinsieme
della specifica dei PDF in quanto lascia fuori alcune caratteristiche dei PDF
non adatte all’archiviazione a lungo termine10 . Sono escluse da un PDF/A
le seguenti funzionalità:
• Contenuti audio e video.
• Javascript e codice eseguibile.
• Riferimenti ad oggetti esterni (compresi link ipertestuali).
All’interno di un file PDF/A inoltre, vanno inclusi tutti i font (compresi i
“14 standard”), vanno definiti gli spazi dei colori in modo assolutamente
indipendente dal sistema e non è infine permessa la crittazione.
9
Sono state acquisite conoscenze parziali anche su altri tipi di operatori come: gli
operatori grafici, gli operatori di colore e gli operatori per il contenuto taggato (marked
content operator).
10
Lo standard PDF nella sua versione attuale permette di inserire tra le altre cose
anche filmati e audio all’interno di un documento, come pure animazioni 3D.
36
4.3. Valutazione del corso di studi
4.3 Valutazione del corso di studi

Trovo che gli argomenti affrontati durante il corso di studi siano stati adegua-
ti e soprattutto utili. Lo studio di C♯ si è rivelato più semplice considerando
i linguaggi di programmazione affrontati durante il corso (C++, Java). L’u-
tilizzo di WPF, in particolare, non ha richiesto alcuno sforzo considerata la
natura XML di XAML e la somiglianza con HTML. Sono state utili anche
le conoscenze acquisite riguardo alle grammatiche libere da contesto, e al
funzionamento di lexer e parser.
Mi ha sorpreso invece quanto appreso nello studio dei font e degli encoding.
Spesso queste conoscenze vengono date per scontate o comunque citate solo
marginalmente all’interno del corso di studi. Tuttavia ritengo che esse siano
un argomento abbastanza specifico e non strettamente necessario all’interno
del corso di laurea.
37
Appendice A
Glossario
C
Ciclo attivo All’interno del dominio applicativo il termine indica l’in-
sieme dei documenti emanati e prodotti da un’azienda,
per i quali la stessa è in possesso dei sorgenti da cui essi
sono derivati.
Ciclo passivo In questo documento il termine indica generalmente l’in-

sieme dei documenti emanati dai clienti di un’azienda
che neccessitano quindi di essere archiviati e indicizzati
dall’azienda ricevente.
Compiler- Un “compiler-compiler” o “generatore di compilatori” è

compiler uno strumento che crea lexer, parser, interpreti e com-
pilatori a partire da una descrizione formale di una
grammatica.
D
Documentale Plain
R Documentale è il pacchetto software prodotto
da ASI per la gestione del ciclo attivo e passivo dei
documenti aziendali.
38
E
ERP (Enterprise Resource Planning) è una tipologia di soft-
ware che cerca di integrare i vari processi di pianificazio-
ne dell’azienda, la realizzazione del prodotto, le vendite,
gli acquisti, la logistica di magazzino e il marketing.
G
Glifo Un glifo è la rappresentazione grafica di un carattere, la
figura geometrica con la quale esso appare all’interno di
un media (sia esso carta stampata oppure un monitor).
Un font è appunto la definizione di una mappatura tra
caratteri Unicode e glifi.
O
OCR (Optical Character Recognition), un programma OCR si
occupa di tradurre immagini in cui è contenuto del testo
in testo selezionabile. I programmi OCR sono una com-
ponente fondamentale nella creazione di PDF Searchable
a partire da documenti cartacei.
P
Posizionale Un’attività posizionale è un’attività legata all’utilizzo di
una o più posizioni geometriche, in particolare il ricono-
scimento posizionale come pure l’estrazione posizionale
di testo indicano la possibilità di riconoscere ed estrarre
il testo da un documento una volta definita una posizione
iniziale o un’area all’interno di una pagina del documento.
39
S
Searchable Viene definito PDF Searchable un documento PDF dove
sia possibile fare ricerca sul testo contenuto, deve inoltre
essere possibile selezionare e copiare porzioni di testo.
Questo tipo di distinzione è necessaria considerando che
all’interno di un PDF il testo può essere presente anche
come semplice immagine raster.
Sans Viene definito “sans” abbreviazione di “sans serif” un

font che non presenta piccole decorazioni alle estremità
dei glifi. Sono font “sans”: Arial, Tahoma, Verdana.
Stream Uno stream è generalmente una sequenza continua di da-

ti simili resi disponibili nel tempo. All’interno dei file
PDF uno stream indica una sequenza compressa di byte
che contiene la definizione, per esempio, di un font, di
un’immagine o del contenuto di una pagina.
T
Tagged Un Tagged PDF, è un documento PDF all’interno del
quale sono stati inserite sequenze di XML in modo da
dare una struttura logica a quella che altrimenti sarebbe
solo una rappresentazione grafica (rendering) del testo.
U
Unicode Unicode è uno standard che permette di manipolare e
rappresentare correttamente il testo contenuto nella mag-
gior parte dei sistemi di scrittura del mondo. L’ultima
versione dello standard contiene più di 107.000 caratteri
e copre 90 sistemi di scrittura. Il successo di Unicode nel-
l’unificare i vari set di caratteri presenti nel mondo è stato
tale da aver portato alla sua implementazione in mol-
te e diverse tecnologie, come XML, Java e il framework
.NET. In .NET infatti un char rappresenta un carattere
Unicode tra 0 e 65.535.
40
W
WPF (Windows Presentation Foundation) è un sistema per lo
sviluppo di interfacce grafiche per applicazioni Windows.
WPF separa l’interfaccia grafica dalla logica del program-
ma, pur permettendo una veloce ed efficace integrazione
tra le due.
X
XAML (eXtensible Application Markup Language) è un linguag-
gio basato su XML utilizzato per la definizione delle
interfacce grafiche in WPF.
41
Bibliografia
[1] Adobe Systems Incorporated, November 2006

PDF Reference Sixth edition (Adobe
R Portable Document Format Ver-
sion 1.7)
PDF Reference, Sixth Edition
[2] empira Software GmbH, 2009,

empira PdfSharp & Migradoc Documentation
[3] Terence Parr, 2007,

The Definitive ANTLR Reference (Building Domain-Specific Languages)
[4] Vic Hartog and Dennis Doomen, 2005,

Coding Standard: C# (Philips Medical Systems - Software / SPI)
[5] Dennis Doomen, 2009,

C# 3.0 Coding Guidelines (Guidelines for .NET development)
42
Indice analitico
affidabilità, 7–9, 11, 16, 17, 25, 26,

33, 34
AIIM, 36
Symbols analisi
attività di, 30, 31, 34
Tlm (text-line matrix), 21 automatizzata, 7, 26
Tm (text matrix), 21 del PDF, 14
Æ (AE), 24 fase di, 10, 13, 15, 30, 31, 33
.NET, 2, 12, 16, 17, 31, 34, 40 testo, 21
fi (fi, small ligature), 9, 24 analisi dei requisiti, vedi
\f (Form Feed), 20 documentazione
\n (Line Feed), 20 animazioni, 2
\r (Carriage Return), 20 ANSI, 35
\r\n, 20 ANTLR, 34, 35
\u0085 (Next Line), 20 ANTLRWorks, 19, 20, 28, 29, 34
\u2028 (Line Separator), 20 API, 16, 17, 29
\u2029 (Paragraph Separator), 20 applicazione
14 font standard, 28, 36 desktop, 2
web, 2, 23
Windows, 41
WPF, 2
A architetture asincrone, 34
Abstract Syntax Tree, vedi AST archiviazione, 5
accelerazione hardware, 2 archiviazione sostitutiva a norma, 3,
accessibilità, 10 36
accesso all’informazione, 3 Arial, 28, 40
acquisizione, 1, 5 ASCII, 35
actions, 35 ASI, 1–3, 6–8, 11, 13, 15–17, 33, 34,
Adobe 38
Flash, 2 AST, 25
Reader, 7 astrazione, 2
43
Indice analitico
attività ciclo passivo del documento, vedi

di analisi, vedi analisi documento
di codifica, vedi codifica CMap, 27
di documentazione, vedi codice
documentazione esempi di, 16
di progettazione, vedi mantenibilità, 12, 31
progettazione testato, 15
di stage, 12, 28, 34 unità del, 12, 13
di studio del dominio, vedi codice sorgente, 8
studio del dominio codifica
di testing, vedi attività di, 29–31, 33
verifica e validazione correttiva, 30
di verifica e validazione, vedi fase di, 12, 20, 28, 30, 31
verifica e validazione colore, 7, 19, 24
azienda, 1–5, 8, 11, 13, 17, 29, 38, 39 commento XML, 12, 29, 34
compilatore, 38
compiler-compiler, 19, 38
componente, 13, 14, 33
B content stream, 18–25, 27–29, 34–36,
browser, 10 40
bug, 13, 28 analisi, 34
definizione, 27
parsing, 22
controllo, 12
C coordinate cartesiane, 24, 26, 29
copia cartacea, 5
C++, 12, 37
corsivo, 28
C♯, 2, 12, 13, 16, 17, 20, 31, 35, 37
costrutto sintattico, 12
nomenclatura standard, 17
Courier, 28
proprietà, 12, 17
CPU, 2
cache, 23
criticità, 12, 13, 15
campagna di test, 15
crittazione, 36
carattere, 10, 24, 39
CTM, 21
certificazione, 1
current transformation matrix, vedi
CFG (context-free grammar), 20, 37
CTM
char spacing, 24
CHM, 17, 34
ciclo
attivo, 3, 38
di vita, 6, 30
D
passivo, 3, 4, 38 data binding, 2
ciclo attivo del documento, vedi dato
documento estrazione, 11, 13, 16
posizione, 25, 26
44
Indice analitico
verificato, 26, 27
dato primitivo, 18
debug, 34
decodifica, 35 E
design pattern elenco puntato, 9, 10
façade, 23 encoding, 18, 23, 24, 27, 35, 37
front controller, 23 ERP, 1, 39
singleton, 23 errore, 6, 13, 26
diagramma estrazione
delle classi, 28 attributi, 7
delle componenti, 13 automatica, 27, 33
di attività, 28 di testo, 7, 8, 16
Use Case, 13 di un dato, 6, 11, 13
dimensioni della pagina, 23 fallimento, 27
DirectX, 2 posizionale, 7, 8, 22, 39
DOC, 4
Documentale, 3, 6, 7, 11, 16, 38
documentazione, 17
allegata, 8, 33 F
analisi dei requisiti, 15
attività di, 12, 15, 17, 30, 31 fallimento posizionale, 27
fase di, 30, 31 fase
generazione, 12 di analisi, vedi analisi
mantenibilità, 12 di codifica, vedi codifica
manuale utente, 29 di documentazione, vedi
qualità della, 8, 16, 17 documentazione
specifica tecnica, 15, 29 di progettazione, vedi
documento progettazione
acquisizione, 5, 6, 8, 38 di studio del dominio, vedi
archiviazione, 3, 36 studio del dominio
cartaceo, 3, 5, 6, 10, 39 di testing, vedi
ciclo attivo, 1, 4, 38 verifica e validazione
ciclo di vita, 6 di verifica e validazione, vedi
ciclo passivo, 1, 5, 7, 11, 27, 38 verifica e validazione
creazione, 5, 8 filtro di codifica, 18
digitale, 5, 10, 36 firma digitale, 3
HTML, 9, 10 font, 10, 18, 19, 22–25, 35, 37, 39, 40
layout, 3, 6, 9 font monospace, 24
produzione, 3, 6, 38 formato
driver, 29 cartaceo, 5, 6
di scambio, 6, 10
elettronico, 6
intermedio, 4
principale, 4
45
Indice analitico
framework .NET, vedi .NET intelligenza artificiale, 34

IntelliSense, 12, 34
interfaccia esterna, 22
interfaccia grafica, 2, 7, 29, 33, 41
G iRef, 28
garanzia di sicurezza, 2, 8, 26, 27 ISO 19005-1, 36
GDI, 2 ISO 32000, 35
generazione automatica, 20, 23, 24 ISO/AWI 14289, 10, 36
gestionale, 1 iText, 17
gestione iTextSharp, 17
ciclo attivo, 3
ciclo passivo, 3
dei documenti, 3, 4
delle informazioni, 3
J
modello di mappatura, 7 Java, 12, 17, 37, 40
glifo javadoc, 12, 17
colore, 10 Javascript, 36
definizione, 28, 35, 39, 40
dimensione, 10, 24
inclinazione, 10
orientamento, 10 L
posizione, 10 layout
GPU, 2 di partenza, 4, 8, 9, 26
grammatica, 19–21, 23–25, 27–29, 34, incongruenza, 8
35, 38 indipendente, 10
grammatica libera sicuro, 11
da contesto, vedi CFG variabile, 6, 8, 13
(context-free grammar) lexer, 19, 20, 23, 24, 37, 38
grassetto, 28 libreria
grassetto-corsivo, 28 .NET, 2
GUI, 2, 14, 29 criteri di scelta, 16
di rendering, 7, 8
di supporto, 7, 14, 15
individuazione, 11, 14, 15
H licenza, 16
Helvetica, 28 limiti del prodotto, 15, 27
HTML, 9, 37 linea (tracciato), 10
linea guida, 12
linguaggio di markup, 9
logica del programma, 2, 41
I logo, 11
IBM, 1
immagine raster, 5, 40
46
Indice analitico
M N
macchina virtuale, 2 NET (framework), vedi .NET
MacRomanEncoding, 27 nomenclatura, 12, 17
manuale utente, vedi
documentazione
MapFinder, 13–15
MapManager, 13–15 O
matrice OCR, 5, 6, 39
di linea di testo, vedi Tlm oggetto di testo, vedi text object
di posizionamento, 25, 36 operatore, 20, 21, 27, 36
di testo, vedi Tm di colore, 21, 36
posizionale, 21 di posizionamento, 21, 28, 36
stack, 21 di stampa, 21, 24, 36
matrice di stato, vedi state matrix di stato, 10, 21, 36
matrice di trasformazione corrente, grafico, 36
vedi CTM per il contenuto taggato, 36
media, 39 operazione di traduzione, 28
Microsoft, 1, 13, 34 ore effettive, 31
.NET, vedi .NET ore preventivate, 31
nomencatura standard, 17
SQL Server, vedi SQL Server
Visual SourceSafe, vedi
Visual SourceSafe P
Visual Studio, vedi Visual Studio
package, vedi Plain.File.Extraction
Windows, 2, 35
pagina web, 2
Windows Forms, vedi WinForms
parser, 19, 20, 23, 25, 28, 29, 35, 37,
Windows Presentation
38
Foundation, vedi WPF
PDF
modello di ciclo di vita, 30
analisi, 11, 14, 15, 17, 19, 21, 22,
modello di mappatura
26
creazione, 8, 13
Body, 17
definizione, 6, 7, 25, 26, 33, 34
contenuto, 11, 18, 35
gestione, 33
creazione, 9, 17, 18
identificazione, 13
Cross Reference Table, 17, 35
modifica, 13
dizionario, 35
modello evolutivo, 30
File Trailer, 17, 35
monocromatico, 21
formato chiuso, 19
generatore, 5, 24, 27
Header, 17, 35
layout, 13
47
Indice analitico
modifica incrementale, 18 progettazione

name, 35 attività di, 12, 14, 21, 25, 29–31,
operatore, vedi operatore 33, 34
progettazione, 10 fase di, 2, 14, 15, 28–31
rendering, 7, 8 progetto di stage, 11, 13, 15–17, 19,
specifica, 19, 31, 35, 36 33, 35, 36
struttura interna, 17, 18, 35 proprietà, 12, 34
valido, 28 prototipo, 30
variante, 36
PDF Searchable, 4–6, 39, 40
PDF/A, 36
PDF/UA, 10, 36 R
Tagged PDF, 10, 40 random access, 17
tradizionale, 10 rendering, 7, 8
versione, 17 requisito
1.5, 28 catalogazione, 14
1.6, 28 elenco, 15
PDF-DocEncoding, 27 individuazione, 13, 30
PdfAnalyzer (componente), 13–15, 22 verifica, 29
PdfSharp, 17, 18, 28 retrocompatibilità, 28
plain, 1 ricerca
Plain.File.Extraction, 22, 23, 25, contenuto, 3
27–29, 33 documento, 3
PdfAnalyzer (classe), 22–25 non-posizionale, 27
PdfChar, 23, 24 posizionale, 13
PdfFont, 23–25 sul testo, 40
PdfPage, 22–26 risorsa umana, 1
PdfText, 23–25
PdfTextStreamLexer, 24
PdfTextStreamParser, 23, 25
portale, 1 S
porting, 16
Sandcastle, 29
posizionale, 39
sans, 40
carattere, 24
sans serif, 40
estrazione, 8
scanner, 5, 6
ricerca, 13
scanner OCR, 6
posizione assoluta, 10
scelta progettuale, 13, 15
posizione del testo, vedi testo
sicurezza, 3
processo
significato logico, 11
aziendale, 36
Silverlight, 2
di acquisizione, 6
sistema di coordinate nella pagina,
di sviluppo, 1
10
gestionale, 1
software ERP, 1
intermedio, 8, 26
48
Indice analitico
software gestionale, 1 significato, 9

sorgente, 4, 6 text leading, 24
sorgente aperto, 7, 17 text matrix, vedi Tm
spazio bianco, 20 text object, 21, 36
spazio dei colori, 35, 36 text rise, 24
specifica tecnica, vedi text size, 24
documentazione text-line matrix, vedi Tlm
SQL Server, 1 Times, 28
standard di codifica, 12, 13 Times New Roman, 28
StandardEncoding, 27 tracciato vettoriale, 10
state matrix, 21 traduttore, 20
stile, 7 trasparenza, 2
stream, 18, 35, 40
decodifica, 18
di contenuto, vedi
content stream U
struttura UML, 15
di supporto, 25 Unicode, 24, 35, 39, 40
grafica, 10
logica, 9–11, 13, 33, 36, 40
stub, 29
studio del dominio V
attività di, 30, 31
valore semantico, 7
fase di, 12, 30, 31, 34
Verdana, 40
Symbol (font), 28
verifica e validazione
attività di, 30, 31
fase di, 20, 28–31
T vettoriale, 2, 10
visione d’insieme, 13
tabella, 9 Visual SourceSafe, 1
Tahoma, 40 Visual Studio, 1, 12, 34
test case, 29 visualizzatore, 14
test manuale, 29
testo, 10
affidabilità, 7
analisi, 11, 21 W
attributo del, 8, 24–26, 28
WinAnsiEncoding, 27
estrazione, 7, 8, 11, 22, 28
Windows Forms, vedi WinForms
identificazione del, 11
Windows Presentation
posizionale, 25, 36
Foundation, vedi WPF
posizionamento, 21
WinForms, 2, 3
posizione del, 7, 9, 11, 16
word spacing, 24
rendering, 36
WPF, 2, 3, 12, 31, 34, 37, 41
49
Indice analitico
X
XAML, 2, 37, 41
XML, 4, 9, 10, 12, 29, 34, 37, 40, 41
XPS, 4
Z
Zapf Dingbats (font), 28
50

Riconoscimento Posizionale Di Testo All'interno Di Un PDF (Report)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Riconoscimento Posizionale Di Testo All'interno Di Un PDF (Report)

Caricato da

Copyright:

Formati disponibili

Università degli studi di Padova

Facoltà di Scienze MM.FF.NN.

RICONOSCIMENTO POSIZIONALE DI TESTO

Anno Accademico 2009-2010

3.3.9 Affidabilità del dato estratto . . . . . . . . . . . . . . 25

2.1 Ciclo attivo e passivo in un’azienda . . . . . . . . . . . . . . . 4

3.1 Diagramma generale delle componenti . . . . . . . . . . . . . 14

ASI è Business Partner di IBM relativamente all’hardware e al software, è

1.2 Tecnologie e processi aziendali

1.2.1 Il framework .NET

1.2.3 Windows Presentation Foundation

1.3 Ciclo attivo e passivo di un’azienda

Nella gestione dei documenti i due termini indicano rispettivamente: l’insie-

Plain R Documentale (da qui in poi solo Documentale) è il pacchetto soft-

Documentale offre tra le altre le seguenti funzionalità:

• ricerca, consultazione, trasmissione e condivisione dei documenti e dei

• sicurezza nell’accesso alle informazioni;

• unificazione dei diversi database documentali presenti in azienda;

• gestione del ciclo passivo dei documenti cartacei.

Documentale offre inoltre il supporto alla firma digitale nei documenti e

2.1 Problematiche del ciclo passivo

Figura 2.1: Ciclo attivo e passivo in un’azienda

Generatore PDF Immagine

Figura 2.2: Produzione e acquisizione di un documento

Come è possibile vedere in figura 2.2, il processo di acquisizione dei dati

2.1.1 Modelli di mappatura

Figura 2.3: Layout e modello di mappatura

Il modello di mappatura deve essere definito manualmente dall’utente. La

2.2 Problematiche dei PDF

2.2.1 Estrazione del testo e dei suoi attributi

Di fatto vi sono librerie (alcune di esse gratuite ed a sorgente aperto) in

L’utilizzo di queste librerie non è stato preso in considerazione da ASI per

2.2.2 L’assenza di un layout fidato

Dati e layout Processi

Figura 2.4: Affidabilità dell’estrazione

Il modello di mappatura viene creato manualmente a partire da un docu-

Supponendo di partire perfino dagli stessi dati2 , il layout del documento

2.2.3 L’assenza di una struttura logica

Figura 2.5: Differenza tra HTML e PDF

All’interno di un PDF tradizionale3 tuttavia non esiste alcuna struttura

Nella figura precedente (2.5) viene illustrata la differenza tra la struttura

In un documento HTML il testo è contenuto nella struttura logica. Ta-

In un documento PDF invece tali elementi logici non esistono. La tabella

La soluzione adottata da Adobe fu quella di definire la posizione di ogni

2.3 L’estrazione posizionale fidata

In questo capitolo viene presentato un resoconto dell’attività di stage, ana-

3.1 Studio del dominio applicativo

Obiettivo di questa fase era inoltre l’assimilazione delle regole riguardan-

In questo modo lo sviluppatore non indugia nelle scelte progettuali (avendo

Lo standard di codifica adottato da ASI per C♯[4] risale alla definizione

Nel diagramma sottostante (figura 3.1) sono rappresentate le componenti

Lo studio del diagramma in figura 3.1 è stato fondamentale nella cataloga-

cd: Visione di insieme

<< component>> << component, library >>

<< component>> << component>>

Figura 3.1: Diagramma generale delle componenti

3.3.1 Individuazione di una libreria

Nella fase precedente (analisi) era stato individuato il desiderio da parte

La libreria da utilizzare doveva essere scelta in base ai seguenti criteri (in

Licenza Fondamentale era la possibilità da parte di ASI

Funzionalità Quanto la libreria poteva essere utile al progetto3 , os-

Utilizzo di C♯ Vincolo fondamentale era la disponibilità della libreria

Costo Non vincolante ma comunque importante era il costo