Skip to topic | Skip to bottom
Home

Tesi
Tesi.PdFConverterIIr1.13 - 18 May 2009 - 13:59 - LorenzoBenfenatitopic end

Start of topic | Skip to actions

PDF Converter II

In questa pagina si organizzano tutti i materiali di lavoro connessi con la tesi sulla II parte del lavoro sul convertitore da e per PDF.

In particolare, qui ci concentriamo sulla identificazione di strutture significative all'interno del documento SVG generato dal PDF usando lo strumento creato da LauroCottafavi nella prima parte del progetto.

Risorse del progetto

Analisi dei passi di sviluppo

Il lavoro dovrebbe essere organizzato in tre fasi. Le prime due corrono parallelamente e sono l'individuazione di indicatori sulle caratteristiche del documento analizzato, come per esempio l'interlinea e i margini, e l'identificazione delle macrostrutture (titoli, paragrafi, tabelle, grafica) all'interno del documento. L'ultima fase è la conversione ad un formato generico XML (anche XHTML), cecando di mantenere piu' informazioni possibili sul documento originale, in modo da poterne rendere una rappresentazione pressoche identica.

Struttura di un documento PDF

Analizzo la struttura dei documenti PDF perchè il convertitore scritto da LauroCottafavi genera un SVG con una struttura pressoché identica rispetto al PDF originale. In un generico documento di testo generalmente si puo' trovare un Titolo, una o piu' colonne di testo, un'intestazione o pie' di pagina, ad esempio con numero di pagina e autore, ed eventualmente immagini, tabelle, grafici. Il formato PDF organizza gli elementi al suo interno a scopo puramente presentazionale e non esistono i concetti di paragrafo, tabella, intestazione,ecc.; è un contenitore di stringhe di testo posizionate nel foglio insieme a figure geometriche. Un paragrafo o una tabella saranno quindi formati da un'insieme di stringhe di caratteri con alcune caratteristiche particolari.

Caratteristiche degli oggetti nel documento.

Gli oggetti presenti in un documento si possono principalmente dividere in tre gruppi:
  • testo
  • grafica (vettoriale)
  • immagini
Questi elementi hanno caratteristiche comuni, come la posizione all'interno del documento, e caratteristiche proprie, come lo stile del carattere per il testo o l'URL per le immagini

Idee sulla realizzazione del progetto

Flessibilità

La difficoltà principale nella realizzazione di questo progetto è creare delle regole per l'identificazione delle macrostrutture che possano applicarsi al piu' grande numero di documenti possibili, dall'articolo di giornale al volantino pubblicitario. Per questo ho pensato di lasciare queste regole fuori dall'"eseguibile", in un file esterno. E' anche possibile che coesistano piu' file di regole, utilizzati per diversi tipi di documento.

Struttura a "cipolla"

Partendo dai tre elementi che posso trovare nel documento (testo, grafica, immagini) dovrei raggruppare quelli con determinate caratteristiche all'interno di contenitori che a loro volta potranno essere parte di un raggruppamento piu' esteso. A esempio posso raggruppare elementi "testo" in elementi "riga", che verranno poi raggruppate in "paragrafi", che a loro volta faranno parte di "colonne di testo" o, insieme ad elementi di grafica, in tabelle. Questa organizzazione mi permentte anche di avere piu' controllo sui passi della conversione, in modo da individuare subito il momento in cui si verifica un problema

Linguaggio di programmazione

Il documento originale in SVG è un formato XML, il risultato deve essere un file XML, la scelta piu' ovvia sarebbe usare uno o piu' fogli di stile XSLT per realizzare il convertitore. Date pero' le grosse difficoltà che ho incontrato durante i tentativi fatti con XSLT, ho deciso di utilizzare un linguaggio (a mio parere) piu' flessibile e intuitivo: Python

Scelte implementative

To DOM o non to DOM

Quando ho cominciato a lavorare sulla tesi (mooolto tempo fa;) l'implementazione di DOM per Python non era, evidentemente, scritta molto bene. Fare il parsing di un documento di una decina di pagine richiedeva piu' di 600 Mb di RAM, e il mio pc non ne aveva cosi' tanta. Ho scelto quindi di scrivere un semplice parser utilizzando le regular expression e le liste e i dizionari di Python

Strutture dati

All'inizio ho utilizzato le liste e i dizionari di python come struttura dati per elaborare il file SVG e, nonostante fossero relativamente veloci e efficenti, avevano alcuni svantaggi. Il primo era dovuto al fatto che, essendo le strutture dati in RAM volatili per definizione, per testare i nuovi algoritmi che scrivevo dovevo lanciare il programma da zero ogni volta, il che significa aspettare che faccia il parsing del documento e che esegua la parte di programma stabile, e, alla fine, salvare il contenuto delle strutture dati in un file di output, spesso molto lungo e poco leggibile. Il secondo era che non riuscivo a trovare un modo "decente" di rappresentare le "regole" in un file esterno al programma. Un giorno però mi sono imbattuto in questo (http://plesslweb.ch/2006/12/01/using-sqlite-database-files-as-the-native-application-data-format/) articolo, che commenta positivamente un talk del creatore di SQLite Richard Hipp, in cui suggeriva di usare SQLite per gestire le strutture dati nelle proprie applicazioni. Mi è sembrata in effetti una buona idea, perchè avrebbe risolto in un colpo solo i miei due problemi, permettendomi di effettuare il parsing del documento una volta sola e di testare i miei algoritmi su una struttura "solida" e mi dava la possibilità di salvare le "regole", che a questo punto sarebbero istruzioni SQL, in un file esterno. Inoltre lavoro con i database ogni giorno e ho una certa dimestichezza con l'SQL.
DB e tabelle
La struttura del database è molto semplice. Ci sono 3 tabelle:
  • Elements che contiene gli elementi del documento, sia quelli letti direttamente dal file SVG, sia quelli creati per aggregarli
  • Relations che contiene le relazioni fra gli elementi.
  • Info che contiene informazioni riguardanti il documento, come ad esempio il numero di pagine o la dimensione delle stesse

Stato di avanzamento

Integrazione con PDFConverter

Ho una classe python che richiama l'eseguibile giusto (a seconda dell'architettura) del programma di conversione da PDF a SVG. Ho cercato, perdendoci molto tempo ma senza alcun risultato, di integrare meglio il programma di LauroCottafavi, modificandolo in modo da usarlo come libreria dinamica e costruendo un wrapper per Python con le librerie SWIG. I problemi al momento insormontabili sono il design del programma di LauroCottafavi, che, mano a mano che procede nell'elaborazione, scrive direttamente su filesystem il file SVG (per trasformarlo in una libreria che ritorna una stringa o una struttura dati avrei dovuto cambiarlo sostanzialmente) e la mia scarsa dimestichezza con il C++ linker e SWIG.

Rilevazione di strutture

Le percentuali di successo nel rilevare le parti del documento sono:
  • 99% sul corpo del testo principale (anche su piu' colonne)
  • 100% su immagini "bitmap"
  • 99% su immagini vettoriali
  • 99% su box di testo (potrebbe succedere che, se sono piccoli e con molta "grafica" attorno, li scambi per immagini vettoriali)
  • 99% note a fondo pagina
  • 0% tabelle (attualmente vengono classificate o come immagine vettoriale, o come un insieme di box di testo)
  • 90% intestazione e piè di pagina (so che ci sono e quali oggetti ne fanno parte, quindi non li confondo con il resto del testo, ma ancora non li gestisco bene)

Esempi allegati

In allegato a questa pagina c'è un piccolo esempio di come funziona il mio programma. Il file PDF è il file originale, il file 3.svg è la terza pagina come viene convertita dal programma di Lauro, i file 3_*.svg sono rappresentativi dei passi che il mio programma esegue per processare l'SVG e il file stile.css è il foglio di stile per visualizzare correttamente gli SVG. I passi visibili nei 4 file che ho prodotto sono:
  • Passo 1: Riconoscimento dei blocchi di testo (non è visibile nel file ma a questo punto so anche qual'è il corpo del testo "principale")
  • Passo 2: Individuazione dell'area della pagina. Qui ho rilevato l'area in cui sta il testo pricipale, e, di conseguenza, intestazioni, pie' di pagina e margini laterali
  • Passo 3: Gli spazi senza testo. Qui ho trovato le aree "vuote" del corpo della pagina. Da qui comincero' a cercare le immagini, vettoriali e non.
  • Passo 4: Riconoscimento del disegno. Qui ho trovato l'immagine vettoriale.

Prestazioni

I tempi di elaborazione e la memoria occupata variano a seconda dal tipo di documento, dalla sua lunghezza e da come viene usato SQLite. SQLite puo' scrivere il DB su disco o tenerlo completamente in memoria (ovviamente in questo caso al termine del programma il DB viene perso). Negli ultimi giorni ho lavorato per migliorare i tempi di elaborazione e sono riuscito a scendere di un'ordine di grandezza, passando da "minuti" a "secondi", ottimizzando l'utilizzo del db e creando qualche indice. La memoria utilizzata dal programma comunque varia fra i 10 e i 25 MB. I tempi di elaborazione, partendo da un documento PDF, variano fra i 2 e i 10 secondi per pagina se il DB viene scritto su disco, mentre variano fra 1 e 5 secondi se il DB viene tenuto in memoria.

Problemi conosciuti

Tabelle

Praticamente non le rilevo. Potrebbero venire classificate come "grafica vettoriale" o come caselle di testo. Il problema è che non sono riuscito a trovare un modo per riconoscere certamente una tabella. A volte ci sono linee a deleimitare le celle, e a volte no. A volte sono una struttura a reticolo, ma a volte fra colspan e rowspan sono un aggregato quasi casuale.

Formule matematiche

Se sono inserite nel corpo del testo non danno problemi, ma se, come accade spesso in testi scientifici, sono un "blocco" a parte e, per caso, questo blocco è posizionato in fondo alla pagina, viene rilevato come nota a pie' pagina. In ogni caso le formule matematiche sono un problema...

Problemi di prestazioni

Ci sono alcuni casi in cui le prestazioni calano notevolmente. In alcuni documenti PDF con immagini molto grandi il programma di lauro impiega molto tempo a convertire le immagini in PNG e questo si riperquote sul tempo totale della conversione. Ho notato che sotto windows, se il database SQLite viene scritto su disco, l'antivirus (ho McAfee?) rallenta molto l'IO e le performance peggiorano notevolmente (il tempo di esecuzione triplica!)

Visualizzatori SVG e formato SVG

Quando LauroCottafavi scrisse il programma per convertire da PDF a SVG l'unico visualizzatore SVG utilizzabile era il plugin della Adobe per Internet Explorer e Firefox. La Adobe ha annunciato che dal 1 gennaio 2009 ha abbandonato il supporto per questa applicazione. Nel frattempo pero' sia Firefox che Safari hanno implementato la funzione di visualizzazione dei file SVG. Di questi due pero' solo Safari li visualizza correttamente. Il convertitore da PDF a SVG, puo' creare come output sia un file SVG per pagina (che è il solo modo in cui il mio programma "capisce" l'output del convertitore) sia un file SVG unico. In quest'ultimo caso pero' l'SVG prodotto non è standard. Veniva interpretato correttamente dal plugin della Adobe, ma sia Firefox che Safari si rifiutano di aprirlo. Non ho trovato, in effetti, nessun modo di eseguire la paginazione di un file SVG nello standard. Dovrei forse cercare meglio?

Jstor

Jstor è un'associazione che un archivio digitale di testi scientifici molto ampio. Alcuni di questi sono stati creati in modo alquanto singolare. Gli articolo che evidentemente esistevano soltanto in formato cartaceo, sono stati acquisiti, un OCR ha riconosciuto il testo, e il PDF è composto dal un layer di testo a cui è sovrapposta l'immagine scannerizzata del documento originale.

Varie ed eventuali

PDFtoSVG?

Ho scoperto che esiste un programma commerciale http://www.pdftron.com/pdf2svg/index.html (demo gratuita) che mette a disposizione anche una libreria in C per convertire i PDF in SVG. Dovrei provarlo?

-- LorenzoBenfenati - 06 May 2009

  • 3.svg: Il file SVG convertito

  • 3_1.svg: Passo 1: Riconoscimento dei blocchi di testo

  • 3_2.svg: Passo 2: individuazione dell'area della pagina

  • 3_3.svg: Passo 3: Gli spazi senza testo

  • 3_4.svg: Passo 4: Riconoscimento del disegno

to top

I Attachment sort Action Size Date Who Comment
00957891.pdf manage 184.3 K 06 May 2009 - 22:28 LorenzoBenfenati Il PDF di test
3.svg manage 41.2 K 06 May 2009 - 22:31 LorenzoBenfenati Il file SVG convertito
style.css manage 33.0 K 06 May 2009 - 22:32 LorenzoBenfenati Il foglio di stile
3_1.svg manage 24.4 K 06 May 2009 - 22:33 LorenzoBenfenati Passo 1: Riconoscimento dei blocchi di testo
3_2.svg manage 274.2 K 06 May 2009 - 22:35 LorenzoBenfenati Passo 2: individuazione dell'area della pagina
3_3.svg manage 35.3 K 06 May 2009 - 22:36 LorenzoBenfenati Passo 3: Gli spazi senza testo
3_4.svg manage 24.5 K 06 May 2009 - 22:37 LorenzoBenfenati Passo 4: Riconoscimento del disegno

You are here: Tesi > ArgomentiDiTesi > IsaWiki > PdFConverterII

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback