> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/it/altri-argomenti/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Introduzione ai file PDF taggati: struttura interna e sfide dell'accessibilità ## Aggiornamento: gennaio 2026 Si vedano [le istruzioni di Overleaf sulla creazione di PDF con tag](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Il [Il team LaTeX](https://latex-project.org/) ha rilasciato nuove funzionalità che consentono il tagging automatico dei PDF, il requisito centrale per l'accessibilità dei PDF. Queste nuove funzionalità sono disponibili in Overleaf in [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), con aggiornamenti più recenti disponibili nella versione rolling di TeX Live disponibile tramite [Overleaf Labs](https://www.overleaf.com/labs/participate). Ora è possibile produrre un PDF con tag da sorgente LaTeX conforme al livello AA delle WCAG 2.1 seguendo [la nostra documentazione per gli utenti](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) utilizzando le versioni di TeX Live disponibili in Overleaf. L'articolo seguente del 2020, pur non essendo aggiornato con le informazioni più recenti sull'accessibilità in LaTeX, può continuare a essere letto con interesse e come informazione di base sul tagging dei PDF. *** ## Di cosa tratta questo articolo? L'obiettivo di questo articolo è fornire un'introduzione al PDF con tag insieme a una panoramica di alcune sfide tecniche affrontate dal software, inclusi i motori TeX e LaTeX, il cui scopo è produrre file PDF taggati e accessibili. L'accessibilità, in particolare dei PDF, è un argomento ampio e complesso, che presenta anche sfide tecniche che non sempre hanno una soluzione unica, universalmente concordata o accettata, ad esempio come rappresentare la matematica complessa all'interno dei PDF in modo accessibile: usando MathML o codice LaTeX? Sebbene non possiamo approfondire ogni argomento, e dobbiamo semplificare molti dettagli, possiamo dare uno sguardo all'interno dei PDF per mostrare in cosa consiste davvero il tagging di un PDF. Overleaf spera che questo articolo serva come un'introduzione utile, fornendo un contesto sufficiente per consentire ai lettori di comprendere meglio le sfide tecniche e sostenere ulteriori letture ed esplorazioni del PDF con tag e dell'accessibilità. Le risorse incluse in questo articolo comprendono: * [un video di 8 minuti](#video-showing-the-logical-structure-of-a-tagged-pdf) che esplora un PDF con tag prodotto da LaTeX; * [un progetto Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) per esplorare l'uso dei caratteri di spazio in LuaTeX; * [registrazioni audio](#tagged-yes-but-the-reading-order-is-incorrect) che dimostrano problemi di accessibilità dei PDF. ## Introduzione Garantire l'accessibilità dei contenuti digitali è giustamente riconosciuto come un aspetto importante della produzione e diffusione dei contenuti. Inoltre, i governi, inclusi [il Regno Unito](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) e il [gli Stati Uniti](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), stanno approvando leggi che richiedono che i contenuti prodotti sotto la loro giurisdizione siano conformi a criteri di accessibilità definiti. La conformità tramite la diffusione dei contenuti in HTML non è eccessivamente onerosa, ma garantire il livello di accessibilità richiesto per i documenti distribuiti in formato PDF può essere una sfida tecnica significativa, a seconda del software utilizzato per creare contenuti destinati all'output come file PDF. Il PDF emerse all'inizio degli anni '90 come soluzione ai problemi legati al trasferimento affidabile dei documenti e la storia ha dimostrato che ha avuto un successo straordinario. Tuttavia, il PDF è anche un formato di file complesso, nato prima del riconoscimento e dell'accettazione diffusi della necessità di facilitare l'accessibilità dei contenuti documentali. Ciononostante, col tempo la specifica PDF si è evoluta per fornire funzionalità che consentono e supportano la produzione di documenti PDF accessibili usando una variante di PDF “stilizzata” che Adobe chiama *PDF con tag*. In pratica, la produzione di PDF —*e completamente accessibili*— comporta significativi requisiti tecnici aggiuntivi per il software che genera PDF, e questo include i motori TeX e l'ecosistema LaTeX di macro e pacchetti aggiuntivi LaTeX. ## Genesi del PDF come carta digitale in forma finale Il [la genesi del Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) risale a un'epoca in cui il trasferimento di documenti tra computer era pieno di difficoltà, spesso causate da conversioni di file che provocavano il riflusso delle pagine e altre discrepanze, aggravate da font e codifiche del testo incompatibili usati su diversi sistemi operativi (in particolare Windows e Macintosh). L'autore di questo documento lavorava nell'editoria in quel periodo e ha vividi ricordi di aver affrontato quelle sfide! Il PDF è stato progettato per affrontare i problemi di condivisione dei file introducendo una carta digitale universale, in forma finale (non modificabile), consentendo il trasferimento senza soluzione di continuità di documenti autonomi che includevano i font necessari per visualizzarli. Gli utenti potevano finalmente trasferire ogni genere di documento con ragionevole certezza che i destinatari, indipendentemente dalla piattaforma informatica, potessero aprirli e leggerli: l'integrità del documento era preservata e i disordinati riflussi di pagina, la compatibilità/disponibilità dei font, erano ormai un ricordo del passato. ### Carta digitale: buona per tutti gli utenti? La discendenza del PDF, come forma di carta digitale, presupponeva naturalmente l'uso dei numeri di pagina stampati, della tipografia o di elementi di design come indizi per la navigazione visiva del suo contenuto, su schermo o su carta. Tuttavia, tali indizi/meccanismi visivi sono ovviamente privi di significato per le persone con gravi disabilità visive. Oggi, il miglioramento dell'accessibilità dei contenuti digitali è giustamente riconosciuto come un aspetto importante della produzione e diffusione dei contenuti. La sfida per il PDF era fornire meccanismi che facilitassero l'accesso non visivo ai contenuti racchiusi in un “contenitore” originariamente progettato per replicare il mezzo visivo della pagina stampata. La prima versione della specifica PDF (PDF 1.0) fu [rilasciata ufficialmente il 15 giugno 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) seguita da nuove versioni con aggiornamenti che, nel 2001 (PDF 1.4), includevano l'introduzione del “PDF con tag”, che [“...consentiva agli utenti di tecnologie assistive”](https://www.adobe.com/accessibility/pdf.html). Le versioni successive della specifica PDF hanno ampliato e migliorato le funzionalità del PDF, culminando nell'ultima versione (PDF 2.0) che, in base a [rapporti](https://www.pdfa.org/tagged-pdf-2-0/), ha rinnovato in modo significativo le funzionalità di accessibilità, sebbene PDF 2.0 non sia ancora ben supportato dai motori TeX. ## Contenuto all'interno dei PDF Per apprezzare i problemi coinvolti, vale la pena esaminare come i file PDF rappresentano realmente il contenuto delle pagine che contengono. Nel profondo di un file PDF, il contenuto di ogni pagina risiede nel suo *flusso di contenuto*: una sequenza di operatori PDF (“comandi”) che collocano testo o grafica in una particolare posizione della pagina per il rendering (visualizzazione) da parte del software usato per *visualizzare* il PDF. In effetti, il flusso di contenuto fornisce una descrizione grafica o una “ricetta” che indica alle applicazioni di visualizzazione dei PDF come “disegnare” ogni pagina, definendo cosa deve essere visualizzato sulla pagina e dove. Naturalmente, quella serie di operatori include istruzioni per scegliere specifici font a una dimensione specifica, selezionare i colori, definire gli spessori delle linee, tracciare linee, curve e così via: tutto ciò che serve per fornire una descrizione grafica completa per la presentazione visiva di una pagina. Per ridurre le dimensioni del file, i flussi di contenuto PDF sono compressi e memorizzati in un formato binario compatto, ma se si ha accesso a software adatto, come Adobe Acrobat Pro DC, si può usarlo per visualizzare una versione in testo semplice “decompressa” dei flussi di contenuto delle pagine. Consideriamo come gli operatori PDF potrebbero “disegnare” una tabella: il flusso di contenuto PDF conterrebbe una sequenza appropriata di operatori per produrre linee orizzontali/verticali, selezionare font diversi e produrre testo collocato in varie posizioni della pagina per creare il contenuto della tabella. Per dimostrarlo, consideriamo un documento PDF molto semplice, non taggato, che non contiene altro che una tabella di base con un po' di testo, creato in Microsoft Word per ragioni che diventeranno chiare più avanti nell'articolo. Ecco uno screenshot che mostra il nostro semplice PDF: ![Una tabella creata in Microsoft Word](/files/1c2861a11c66a90ef16abbd22ebbf09dccdc0bd8) Se estraiamo il flusso di contenuto della pagina (decompresso) per questo file e incolliamo le prime righe in un editor di testo, possiamo riassumere alcuni degli operatori PDF per dare un’idea di come i file PDF “descrivano” il contenuto visualizzato su questa pagina. ![Immagine del flusso di contenuto in un file PDF](/files/cdd0179b39452fd82ebfcba07cd2d0b84811024b) Ecco la vista di Acrobat della *struttura interna del PDF* stesso PDF, che fornisce utilmente una descrizione su una riga di ogni operatore usato per “disegnare” la nostra singola pagina contenente una tabella di base: notate che queste brevi descrizioni sono fornite da Adobe Acrobat Pro DC, non sono *non* presenti nel file PDF stesso: ![Immagine di un flusso di contenuto PDF visualizzato in Adobe Acrobat Pro DC](/files/2e641cf21c46e1f84d37bedfb924085587ee7903) Tuttavia, osservate che nessuna di quelle istruzioni di disegno (operatori) memorizza alcun “significato” o “descrizione” di ciò che sta effettivamente producendo: sono solo un insieme di operatori grafici che danno luogo alla costruzione di ciò che un *osservatore vedente riconosce* come una tabella. Chiaramente, per chi ha una grave disabilità visiva, visualizzare la tabella risultante da quegli operatori grafici nel flusso di contenuto del PDF non è un metodo praticabile per accedere a quel contenuto. Ciò che serve è un meccanismo affinché i file PDF contengano una descrizione non visiva adeguata (leggibile da una macchina) di quella tabella e, naturalmente, di tutti gli altri elementi di contenuto contenuti nelle pagine di un file PDF. Per consentire l'accesso non visivo ai contenuti, i file PDF devono contenere dati aggiuntivi che associno un “significato” o una semantica a collezioni o gruppi di operatori usati per “disegnare” un particolare contenuto. Necessariamente, questo principio di assegnare o fornire un “significato” deve estendersi a tutte le forme di contenuto presenti in un PDF: questo meccanismo esiste ed è chiamato *tagging* il PDF per produrre una “variante” di PDF chiamata, non sorprendentemente, *PDF con tag*. ## Introduzione al PDF con tag Il PDF con tag è il nome dato a un tipo specifico di file PDF che contiene dati aggiuntivi (e strutture di dati) non presenti nei file PDF non taggati. Sebbene i principi/le idee alla base del PDF con tag si prestino a una descrizione sintetica, i dettagli completi sono complessi e occupano molte pagine della specifica PDF formale. Adobe ha progettato il PDF con tag per raggiungere una serie di obiettivi, tra cui rendere il contenuto accessibile agli utenti con disabilità visive, ma esso comprende anche il seguente elenco tratto dalla Sezione 10.7 della [specifica PDF 1.7 di Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * estrazione semplice di testo e grafica da incollare in altre applicazioni; * riflusso automatico del testo e della grafica associata per adattarli a una pagina di dimensioni diverse da quelle presupposte per il layout originale; * elaborazione del testo per scopi quali ricerca, indicizzazione e controllo ortografico; * conversione in altri formati di file comuni (come HTML, XML e RTF) mantenendo la struttura del documento e le informazioni di stile di base. Inoltre, il PDF con tag richiede anche: * che il testo all'interno del contenuto PDF sia rappresentato in una forma convertibile in Unicode; * che le interruzioni di parola siano rappresentate esplicitamente: si noti che i motori TeX non usano caratteri spazio per separare le parole, ma usano la spaziatura flessibile di TeX chiamata glue (vedi sotto); * che il contenuto reale (“vero”) sia distinto dagli artefatti di layout e impaginazione. Alla base del PDF con tag ci sono due concetti chiave che esamineremo: * definire la struttura logica del contenuto in un file PDF; * marcatura (tagging) del contenuto PDF con un insieme di tipi di contenuto standard. ## Struttura logica Nei documenti più lunghi, il contenuto è di solito suddiviso in una sequenza di elementi di contenuto più piccoli; ad esempio, i libri sono tipicamente divisi in capitoli che a loro volta sono suddivisi in sezioni e sottosezioni contenenti paragrafi, tabelle, figure/grafici, elenchi puntati o numerati, note a piè di pagina e riferimenti e così via. La struttura e l'organizzazione del contenuto in un libro del genere, o in qualsiasi altro tipo di documento, è indicata come sua *struttura logica*. La nozione di struttura logica di un documento svolge un ruolo importante nell'accessibilità dei PDF ma, come concetto, la struttura logica può sembrare un po' vaga e difficile da comprendere. La seguente definizione dall' [Enciclopedia dei sistemi di database](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) offre una prospettiva utile: > “La struttura logica si riferisce al modo in cui le informazioni in un documento sono organizzate; definisce la gerarchia delle informazioni e la relazione tra le diverse parti del documento. La struttura logica indica come è costruito un documento, in contrapposizione a ciò che un documento contiene.” Si noti che questa definizione di struttura logica non fa riferimento in modo preciso *come* al fatto che tali informazioni strutturali siano memorizzate fisicamente; afferma semplicemente che esse forniscono una rappresentazione della struttura e dell'organizzazione di un documento. I dettagli precisi di come la struttura logica di un documento sia memorizzata o rappresentata dipendono dall'implementazione: una funzione del software usato per generarlo ed elaborarlo. ### Struttura logica nei PDF La specifica PDF fornisce meccanismi attraverso i quali la struttura logica di un documento può essere registrata all'interno di un file PDF, per essere usata da software che, ad esempio, potrebbe voler esportare il contenuto del PDF in altri formati come XML, HTML o Microsoft Word. Questi processi di esportazione devono produrre un documento di testo strutturato correttamente che sia conforme alle regole del formato di file di destinazione: ciò si ottiene al meglio quando l'elaborazione dell'esportazione è guidata dalle informazioni sulla struttura logica fornite all'interno del PDF. Inoltre, la struttura logica di un file PDF è essenziale per il software di accessibilità che, ad esempio, potrebbe voler eseguire operazioni di sintesi vocale, leggendo il contenuto ad alta voce a una persona con disabilità visive. Il processo di sintesi vocale deve assicurarsi che il contenuto venga letto ad alta voce nell'ordine/sequenza corretto, altrimenti produrrebbe risultati privi di senso. Si noti anche che il concetto stesso di pagina può non avere alcun significato per le applicazioni di accessibilità, interessate solo al contenuto e alla struttura del documento PDF, non alla suddivisione e presentazione visiva in blocchi delle dimensioni di una pagina. #### Denominare gli elementi di contenuto La registrazione (memorizzazione) della struttura logica di un documento PDF richiede un insieme di nomi significativi assegnati ai vari *tipi* di elemento di contenuto che è probabile trovare in un tipico documento PDF: identificando sezioni di contenuto che rappresentano titoli, paragrafi, tabelle, elenchi e così via. Inoltre, alcuni elementi di contenuto come indice, elenchi numerati/ puntati e materiale tabellare hanno strutture proprie piuttosto complesse, quindi servono anche alcune linee guida/regole per specificare come tali elementi di contenuto più complessi sono costruiti, cioè la loro sotto-struttura. Un ulteriore requisito è identificare chiaramente qualsiasi contenuto PDF che dovrebbe essere ignorato dal software di assistenza che elabora il PDF; per esempio, intestazioni e piè di pagina sono artefatti di impaginazione che contengono testo superfluo per chi ha gravi disabilità visive: quel contenuto dovrebbe essere ignorato. I meccanismi usati dal PDF per definire la struttura logica di un documento sono progettati per essere flessibili, quindi, in linea di principio, applicazioni diverse che generano ed elaborano file PDF potrebbero usare nomi per i tipi di contenuto secondo una convenzione a loro scelta. Tuttavia, per massimizzare l'intercambiabilità dei documenti e consentire a diverse applicazioni di elaborazione PDF di fornire risultati coerenti, Adobe ha definito un insieme di nomi standard per i tipi di elementi di contenuto che il software di generazione PDF dovrebbe rispettare. All'interno della specifica PDF questi nomi standard sono chiamati tag, dando origine alla nozione di *PDF* con tag. ### Marcatura del contenuto PDF: uno sguardo “sotto il cofano” Per rendere la discussione un po' meno astratta daremo una breve occhiata ai dettagli interni dei file PDF con tag, sebbene non possiamo coprire tutti i dettagli perché il PDF con tag è un argomento così ampio e complesso. #### Sequenze di contenuto marcato: blocchi fondamentali per il PDF con tag Al livello più basso, il processo di registrazione del significato del contenuto contenuto all'interno di una pagina PDF (cioè, all'interno del suo flusso di contenuto) inizia con *sequenze di contenuto marcato* che vengono usate per identificare (dare “significato” a) gruppi o insiemi di operatori PDF. Alle sequenze di contenuto marcato viene assegnato un identificatore numerico chiamato `MCID` (*identificatore del contenuto marcato*) che è un intero che va da 0 a un massimo N su ogni pagina. Quei `MCID` valori forniscono un modo per identificare in modo univoco sequenze di operatori contenute nel flusso di contenuto di una particolare pagina. Per chiarezza, per ogni pagina gli `MCID` identificatori iniziano da 0 e aumentano in modo sequenziale fino a un valore massimo che dipende da quante sequenze di contenuto marcato sono contenute nel flusso di contenuto di una specifica pagina. Le sequenze di contenuto marcato sono, in effetti, “blocchi fondamentali” usati per assemblare strutture dati di livello superiore chiamate *elementi di struttura*. Questi elementi di struttura contengono un tag, che è il nome usato per identificare quale tipo di elemento di contenuto rappresentano. #### Esempio di elementi di struttura Qui facciamo un salto leggermente in avanti, ma vale la pena esaminare un esempio. Supponiamo di avere 3 piccoli frammenti di testo del contenuto della pagina e che ciascuno sia identificato nel flusso di contenuto da una diversa sequenza di contenuto marcato. Ciascuno di questi 3 frammenti di testo può essere inserito in un proprio elemento di struttura, con un tag, e tutti e tre possono essere “collegati” usando un altro elemento di struttura per rappresentare un elemento di contenuto di livello superiore, come una riga in un indice. ![Immagine che spiega elementi di struttura e sequenze di contenuto marcato](/files/11e5ab8ef876d09430c905f3afc25ab1961649f2) Attraverso una forma di relazione dati padre-figlio, collezioni di elementi di struttura vengono combinate per creare strutture dati collegate che rappresentano elementi di dati più complessi come elenchi numerati e puntati, tabelle, matematica e così via. Alla fine, l'intera raccolta di elementi di struttura contenuti nell'intero file PDF è ulteriormente collegata e combinata per creare la struttura logica del documento PDF: torneremo su questo più avanti nell'articolo. ### Che cos'è una sequenza di contenuto marcato? Nella discussione sopra abbiamo usato un semplice documento PDF non taggato contenente una tabella (creata in Microsoft Word), ma se istruiamo Word a creare un PDF con tag possiamo vedere che nel flusso di contenuto della pagina è apparsa una certa marcatura aggiuntiva. Qui consideriamo solo le prime righe del flusso di contenuto (ce ne sono centinaia), ma notate la presenza di operatori aggiuntivi come `/P <> BDC` e `EMC` che sono usati per identificare una sequenza di contenuto marcato. Non esploreremo la sintassi completa delle sequenze di contenuto marcato, ma rimandiamo il lettore a pagina 862 della [specifica PDF 1.7 ufficiale di Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Immagine che mostra sequenze di contenuto marcato in un flusso di contenuto di un PDF con tag](/files/82cfaa8be6bd06e1f5ffec385011c6e1b485f6f7) Per facile riferimento, mostriamo di nuovo la versione non taggata: ![Immagine che mostra il flusso di contenuto PDF](/files/cdd0179b39452fd82ebfcba07cd2d0b84811024b) Nella *non taggato* PDF, operatori come `/P <> BDC` e `EMC` sono assenti ma gli operatori rimanenti non cambiano: il PDF non taggato manca della marcatura aggiuntiva usata per identificare certe sequenze/raccolte di operatori. Anche qui possiamo usare la funzione di Adobe Acrobat per visualizzare le sequenze di contenuto marcato all'interno di un flusso di contenuto: qui le abbiamo evidenziate usando un bordo verde: *struttura interna del PDF* funzione ![Immagine che mostra sequenze di contenuto marcato in un flusso di contenuto di un PDF con tag visualizzato in Adobe Acrobat Pro DC](/files/98c6c5e5b83a79f6a7d90ab5e1445607e3988e59) Notate che alcuni elementi di contenuto sono contrassegnati con `/Artifact` che identifica il materiale sulla pagina PDF che dovrebbe essere *ignorato* dalle applicazioni software di assistenza, come quelle che leggono ad alta voce per le persone con disabilità visive. La seguente schermata mostra una vista ingrandita della prima sequenza di contenuto marcato, quella con `MCID` valore di `0`. La fine della sequenza di contenuto marcato è identificata dall'operatore PDF `EMC`. ![Immagine che mostra i dettagli degli operatori compresi in un flusso di contenuto marcato](/files/1c5c1f806626e599024995c0cdf2cebb3d99bc5a) ### Memorizzare la struttura logica Come notato, oltre a fornire una descrizione dei singoli elementi di contenuto (paragrafi, elenchi, tabelle, ecc.) è necessario che i PDF accessibili contengano una rappresentazione dell'intero documento sotto forma della sua struttura logica. Le singole parti di contenuto accessibile devono essere collegate insieme per creare un documento completo, navigabile e accessibile: in modo simile a come un singolo documento HTML è costruito a partire da paragrafi, grafica, tabelle per creare una pagina web. Inoltre, è essenziale che la struttura logica di un documento PDF garantisca che tutto il contenuto possa essere navigato nel corretto *ordine di lettura*, indipendentemente dall'ordine in cui il contenuto della pagina è stato scritto nei flussi di contenuto della pagina PDF. Esamineremo più in dettaglio l'ordine di lettura qui sotto. #### Struttura logica: un “albero” di elementi di struttura Abbiamo notato che i PDF usano qualcosa chiamato *elemento di struttura* per rappresentare singoli elementi di contenuto, e che un elemento di struttura contiene un tag per identificare quale tipo di contenuto rappresenta. Per fornire una rappresentazione della struttura logica del documento, tutti gli elementi di struttura sono collegati tra loro, usando relazioni padre-figlio, e organizzati in un “albero della struttura”. Internamente, i file PDF con tag contengono un oggetto chiamato `StructTreeRoot` che contiene (punta a) elementi di struttura che fungono da punto di partenza o “radice” dell'albero della struttura logica del documento. Di solito, la “radice” dell'albero della struttura inizia con un singolo elemento di struttura contrassegnato `Document` che contiene numerosi *figli* elementi di struttura che, collettivamente, rappresentano l'intero contenuto del documento. Qualsiasi software progettato per produrre PDF accessibili tramite tagging deve costruire questa struttura dati molto complessa (e altre ancora!) — e questo include i motori TeX e LaTeX. Un esempio di tale albero della struttura del documento (`StructTreeRoot`) è mostrato nello screenshot seguente di un PDF con tag aperto in Adobe Acrobat Pro DC: ![Immagine che mostra lo StructTreeRoot in un PDF con tag](/files/74d57d104db468b45e572bf7fadf3cec38a59229) Confrontate la struttura sopra con la versione del PDF non taggato: ![Immagine che mostra l'assenza di StructTreeRoot in un PDF non taggato](/files/f3665554e5a968e3232bdda8ba9a1fc8d42d1b6b) ### Esplorare la struttura logica dei PDF Iniziamo con alcuni grafici per riassumere ciò che abbiamo trattato e concludiamo con un video che usa Adobe Acrobat Pro DC per mostrare più dettagli sulla struttura logica di un file PDF con tag. Innanzitutto, iniziamo con uno schema per mostrare i principi generali: una pagina PDF con il suo flusso di contenuto marcato con sequenze di contenuto marcato (MCS). ![Grafico che mostra il concetto di sequenze di contenuto marcato nelle pagine di un documento PDF](/files/51e22d105cad5cd1709e359690996b9e0084b32f) Queste MCS vengono successivamente combinate in *elementi di struttura* che costituiscono la base per tipi di contenuto più grandi che a loro volta sono ulteriormente collegati tra loro per memorizzare la struttura logica del PDF all'interno di un oggetto chiamato `StructTreeRoot`. ![Grafico che mostra la struttura logica di un file PDF con tag](/files/30db8031eb724b61950fefd3be91755e0f9442df) #### Video che mostra la struttura logica di un PDF con tag Il seguente video (8 minuti) usa Adobe Acrobat Pro DC per accompagnarvi in un “tour guidato” alla scoperta dei dettagli della struttura logica di un file PDF con tag prodotto usando LaTeX. Il file PDF con tag usato nel video si chiama `tagpdf.pdf`, che è un ottimo esempio contenente documentazione per il pacchetto sperimentale LaTeX [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Lo scopo del `tagpdf` pacchetto è fornire “strumenti per sperimentare il tagging e l'accessibilità usando pdfLaTeX e LuaTeX”. {% embed url="" %} ### Una nota sul tagging e la flessibilità La specifica HTML fornisce un gran numero di tag predefiniti da usare nella costruzione di pagine web, ma consente anche flessibilità nel modo in cui li combinate per creare il documento HTML desiderato. Allo stesso modo, la specifica PDF con tag di Adobe fornisce un insieme di nomi di tag predefiniti ma impone pochissime restrizioni sul modo in cui si combinano tali tag per rappresentare elementi di contenuto complessi all'interno di un PDF: per progettazione, c'è un gran grado di flessibilità. Inoltre, in qualsiasi specifica grande e complessa come PDF, è inevitabile che alcune ambiguità o problemi di chiarezza si insinuino nella specifica scritta. Gli sviluppatori software incaricati di implementare una specifica così complessa possono dover fare “valutazioni” nell'interpretarla, perché devono tradurre descrizioni scritte in codice funzionante. La flessibilità intrinseca del PDF con tag, insieme all'interpretazione delle specifiche (o degli standard di accessibilità), influisce naturalmente sugli sviluppatori di applicazioni per la creazione di documenti: quali combinazioni di tag dovrebbero essere usate per rappresentare il contenuto creato dall'utente quando lo si esporta in un file PDF con tag? Se si tiene conto della capacità illimitata degli utenti di costruire ogni sorta di contenuto utilizzando le funzioni del software di creazione documenti, si può vedere che la produzione automatica di PDF con tag accessibili è una sfida notevole! Forse riflettendo le inevitabili complessità della produzione di PDF con tag che rispettino pienamente gli standard di accessibilità, il web è ricco di “come fare”, “consigli” e indicazioni sulle “best practice” per creare PDF con tag tramite software come Adobe InDesign o Microsoft Word. Inoltre, la PDF Association ha prodotto un utile documento chiamato [Guida alle migliori pratiche per il PDF con tag](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) scritto per aiutare gli sviluppatori che affrontano le sfide dell'implementazione del PDF con tag e di PDF/UA. ## Avete un PDF, ma è accessibile? Per stabilire se un dato file PDF sia conforme agli standard di accessibilità richiesti come PDF/A o PDF/UA (vedi sotto) deve essere *validato* usando un processo di validazione o uno strumento software concordato. Tuttavia, la validazione di solito avviene dopo che il documento è terminato, ma tale processo potrebbe non essere condotto dall'autore del documento bensì da specialisti dell'accessibilità all'interno dell'organizzazione o dell'ente che ha richiesto la conformità. Se il PDF non supera la validazione, potrebbe essere necessario un intervento manuale qualificato tramite Adobe Acrobat Pro DC per correggere il tagging (se possibile). In alternativa, potrebbe perfino dover tornare all'autore affinché modifichi il documento originale, magari evitando l'uso delle funzioni del software di creazione che hanno causato i problemi: cosa che potrebbe essere estremamente difficile da realizzare perché potrebbe essere al di fuori del controllo dell'autore. ### Ordine di lettura e ordine dei contenuti Come notato, la produzione di PDF realmente accessibili impone requisiti tecnici aggiuntivi al software di creazione e, potenzialmente, anche agli autori dei documenti, imponendo una “disciplina autoriale” nel modo in cui usano/applicano le funzioni del software di creazione. Sebbene il PDF con tag sia il meccanismo che *consente* la produzione di PDF completamente accessibili, il fatto che un PDF sia taggato non *non* significa automaticamente che sia completamente accessibile, come vedremo in un esempio qui sotto. Per produrre PDF completamente accessibili, tutti gli elementi di contenuto del PDF dovrebbero essere taggati per creare una struttura logica che garantisca che il contenuto possa essere accessibile e letto nella sequenza corretta, chiamata *ordine di lettura*ordine di lettura *ordine di lettura* di: 1. testo 2. table 3. grafico Quando viene scritto in un PDF, il software che genera un flusso di contenuto per quella pagina potrebbe iniziare con operatori per disegnare la tabella, quindi produrre operatori per generare il grafico seguiti da operatori per il testo, il che, nel flusso di contenuto, produrrebbe un *ordine dei contenuti* di: 1. table 2. grafico 3. testo Naturalmente, tutto verrà collocato nella posizione corretta quando quella pagina viene visualizzata. Per un lettore vedente, l'ordine in cui tali elementi sono memorizzati all'interno del flusso di contenuto della pagina non ha alcun interesse: egli vede una pagina renderizzata completa con tutto nel posto giusto. Tuttavia, se il software di assistenza dovesse fare affidamento sull'ordine degli elementi in un flusso di contenuto (l'ordine dei contenuti), incontrerebbe difficoltà se l'ordine dei contenuti fosse diverso dall'ordine naturale di lettura; per esempio, gli strumenti di lettura ad alta voce leggerebbero il materiale nella sequenza sbagliata. Fortunatamente, il software di assistenza può usare l'ordine logico (la struttura) di un PDF con tag, che deve essere organizzato per riflettere la sequenza in cui il contenuto dovrebbe essere letto. È per queste ragioni che i dati che rappresentano la struttura logica del documento sono memorizzati separatamente dal contenuto reale visualizzato sulle pagine visibili, per consentire > “... l'ordinamento e l'annidamento degli elementi di contenuto logico siano completamente indipendenti dall'ordine e dalla posizione degli oggetti grafici sulle pagine del documento.” (pagina 856 di [The PDF Reference, sesta edizione, novembre 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) In pratica, garantire un ordine logico che preservi l'ordine di lettura è molto più difficile di quanto possa sembrare, quindi usiamo un esempio semplice, seppur inventato, che dia un'indicazione dei problemi coinvolti. #### Ordine di lettura errato: un esempio con Microsoft Word L'autore di un documento potrebbe usare le funzionalità del software di creazione scelto per ottenere un effetto visivo specifico, ad esempio usando tabelle per creare un particolare layout del testo. Per esempio, la seguente schermata mostra il documento Microsoft Word usato negli esempi precedenti. Contiene una tabella che è stata usata per creare un insieme di paragrafi numerati affiancati. Ma quando si tratta di taggare questo contenuto, come dovrebbe essere trattato: come tabella o come elenco numerato? Entrambi questi tipi di contenuto richiedono una struttura di tagging complessa per rappresentarli correttamente. Nell'immagine seguente, notate l'ordine in cui i paragrafi numerati sono destinati a essere letti: colonna per colonna, non riga per riga. ![Immagine di una tabella creata in Microsoft Word](/files/c1a709803ffcf9b5993048336fd99b354d681bf6) Se chiediamo a Word di salvare questo documento in PDF usando la sua esportazione integrata—non il plug-in Acrobat PDFMaker—possiamo dirgli di creare un PDF taggato: ![Finestra di dialogo delle opzioni del processo di esportazione di Microsoft Word](/files/1020d6e118cd90e1befa481c8bacfb052ebbca1f) Quindi, come etichetta Word questo layout? Nel seguente brevissimo video (14 secondi) usiamo Adobe Acrobat Pro DC per ispezionare la struttura di tagging prodotta da Microsoft Word. {% embed url="" %} Per questo documento, Word ha creato un documento PDF taggato che utilizza un `Tabella` tag contenente due sotto-tag: `THead` per il gruppo di righe di intestazione della tabella e e `TBody` per rappresentare il gruppo di righe del corpo della tabella. `THead` e `TBody` entrambi contengono `TR` tag per rappresentare le singole righe di contenuto. I `TR` tag contengono ulteriori tag per rappresentare l'elemento dell'elenco numerato presente in ogni cella. La seguente immagine dello schermo mostra la struttura di tagging profondamente annidata e la corrispondente complessa struttura logica necessaria per rappresentare persino questo documento estremamente basilare! ![Immagine che mostra una struttura di tagging profondamente annidata e la struttura logica di una semplice tabella creata in Microsoft Word](/files/7988186993385eb24971a386e9f59a9236ce03b6) Rispetto ai PDF generati da TeX e LaTeX, questo esempio di Word è un documento estremamente semplice, ma richiede comunque una struttura logica complessa per rappresentarlo. Immaginate il livello di complessità del tagging necessario per rappresentare PDF generati da LaTeX contenenti matematica e tabelle complesse! #### Taggato, sì, ma l'ordine di lettura è errato Anche se Word produce un [PDF con tag](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) it dimostra una delle sfide fondamentali affrontate da qualsiasi applicazione che tenti di produrre PDF pienamente accessibili: rappresentare correttamente l'ordine di lettura previsto del contenuto. Durante la creazione del PDF taggato, i processi interni di Word hanno deciso di scrivere il corrispondente flusso di contenuto producendo la tabella riga per riga, non colonna per colonna. Per un lettore vedente che visualizza il PDF, questi dettagli di basso livello non fanno alcuna differenza: la tabella viene visualizzata correttamente. Tuttavia, per le persone con disabilità visive, la struttura logica del documento di Word produce il risultato sbagliato perché l'ordine di lettura desiderato (colonna per colonna) non viene preservato: il contenuto viene letto ad alta voce nell'ordine sbagliato. La seguente registrazione audio è stata prodotta utilizzando la funzione “Read Out Loud” di Adobe Reader DC. Come è evidente, il testo viene letto nella sequenza sbagliata: riga per riga, non colonna per colonna: ![Una tabella creata in Microsoft Word](/files/9b52d60493d78f616d2d9c9584e746e8f8aacfaf) Come notato sopra, questo esempio è in qualche modo artificioso, ma dimostra quanto sia facile applicare combinazioni di funzionalità software che innescano problemi di accessibilità—ma come può l'autore del documento sapere in anticipo tutto ciò? È probabile che questo problema verrebbe rilevato solo se il PDF risultante fosse sottoposto a test pratici di usabilità per l'accessibilità—ad esempio, usando software assistivo. Potenzialmente, tali documenti potrebbero superare i test di conformità/validazione PDF/A ma fallire nell'uso “nel mondo reale”. Garantire il corretto ordine di lettura di un file PDF come questo richiederebbe un intervento manuale qualificato usando strumenti avanzati di modifica PDF come Adobe Acrobat Pro DC: un processo lungo e costoso. In alternativa, l'autore del documento potrebbe astenersi dall'usare questa particolare forma di espressione del contenuto o di layout—ma solo se sapesse che è problematica! ### Uso di caratteri di spazio per separare le parole Mentre digitate testo nei word processor o negli editor di testo usate il carattere di spazio per segnare la fine di una parola e l'inizio della successiva. Se in seguito create un PDF da un documento del genere, i caratteri di spazio che avete digitato saranno naturalmente prodotti e faranno parte del testo memorizzato nel PDF. Tuttavia, i motori TeX non usano i caratteri di spazio per separare le parole nel testo impaginato; invece, convertono i caratteri di spazio in una forma di spaziatura flessibile chiamata glue (vedi questo [articolo di Overleaf](/latex/it/articoli-approfonditi/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) per maggiori informazioni sui box e sul glue di TeX). All'interno del flusso di contenuto delle pagine PDF create dai motori TeX, la separazione delle singole parole si ottiene spostandosi in una posizione diversa sulla pagina e iniziando il testo per la parola successiva—piuttosto che producendo un carattere di spazio per ottenere quella spaziatura. Inoltre, la quantità di spazio tra le parole nei paragrafi di testo impaginati dai motori TeX varia da riga a riga a causa dell'algoritmo di spezzatura delle righe di TeX. Tale variazione si riflette nei dati posizionali scritti nel flusso di contenuto delle pagine PDF. Questo aspetto dell'impaginazione di TeX ha implicazioni per il copia/incolla del testo dai suoi PDF e per il software assistivo che cerca di leggere ad alta voce il testo impaginato nei PDF prodotti dai motori TeX. Il software assistivo deve analizzare il flusso di contenuto di una pagina PDF per estrarre il testo di cui ha bisogno per elaborarlo. Chiaramente, tale software ha bisogno di qualche meccanismo per rilevare l'inizio e la fine delle parole—la soluzione più ovvia è usare un carattere di spazio. Tenendo presente ciò, gli standard di accessibilità richiedono che le singole parole siano chiaramente delimitate (ad es., da caratteri di spazio), il che è problematico per i motori TeX a causa del loro uso di glue interparola. #### Ma non tutto è perduto! Nel 2014 pdfTeX ha introdotto 2 nuovi primitivi per migliorare il supporto all'accessibilità consentendo l'uso di caratteri di spazio tra le parole nei PDF che produce: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Questi comandi fanno uso di un “dummy font” contenente solo un glifo di spazio. I dettagli e un esempio si trovano a pagina 29 del [Manuale dell'utente di pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Using LuaTeX: Un esempio nella Galleria di Overleaf LuaTeX non supporta quei primitivi di pdfTeX, ma può essere programmato per ottenere risultati molto simili a pdfTeX usando il cosiddetto meccanismo di callback di LuaTeX. Un progetto Overleaf per convertire il glue in caratteri di spazio è disponibile nella Galleria di Overleaf con il titolo [Uso di LuaTeX per convertire il glue interparola in spazi e kern](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Se impagini il tuo codice LaTeX usando LuaTeX (cioè l'opzione del compilatore LuaLaTeX su Overleaf), allora, usando codice Lua, puoi post-elaborare un paragrafo impaginato per individuare eventuale glue interparola e sostituirlo con un carattere di spazio più un kern adatto. La spaziatura fornita dalla larghezza del carattere di spazio può essere aggiunta a (o ridotta da) calcolando un valore di kern appropriato per preservare la quantità di spazio fornita dal glue interparola, senza alcuna differenza visiva nel risultato impaginato. Per comprendere la differenza che ciò fa per gli utenti di software di accessibilità, ascolta questa registrazione audio catturata dalla funzione di Adobe Reader DC’s *Read Out Loud* Questa funzione registra le due righe di testo in quel progetto lette ad alta voce, prima e dopo la conversione del glue in spazi. Nota come la seconda lettura della riga, che usa gli spazi, sia letta ad alta voce in modo rapido e fluido rispetto alla riga che usa il glue interparola. Il progetto Overleaf è un file TeX puro compilato usando LuaTeX e fornito solo per uso sperimentale; non è inteso come soluzione completa, pronta per la produzione. Principalmente, è progettato per aiutare a comprendere i problemi tecnici relativi ai PDF accessibili. Il codice Lua utilizzato in quel progetto si basa su un lavoro contenuto in un articolo di Overleaf molto precedente [Caselle e colla: una breve, ma visiva, introduzione con LuaTeX](/latex/it/articoli-approfonditi/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Nota: per semplicità il progetto utilizza il proprio caricatore di font OpenType molto minimale, derivato da questo codice: . ### Altri problemi di accessibilità e PDF taggato Sebbene il tagging consenta l'identificazione degli elementi di contenuto presenti all'interno di un PDF, alcuni tipi di contenuto, come la grafica o la matematica complessa, richiedono dati o informazioni aggiuntivi se devono essere resi accessibili tramite software progettato per supportare persone con disabilità visive. Per fornire e supportare l'accessibilità per un'ampia gamma di tipi di contenuto, la specifica PDF offre la possibilità di allegare “Descrizioni alternative” o “ActualText” agli elementi di contenuto, fornendo descrizioni testuali adeguate o altre rappresentazioni leggibili dalla macchina. Ad esempio, MathML è stato designato a questo scopo all'interno della specifica PDF 2.0. #### Contenuto “reale” o solo un artefatto? Per le persone con disabilità visive, il processo di suddivisione e visualizzazione del contenuto in blocchi rettangolari delle dimensioni di una pagina ha effetti collaterali indesiderati, come la sillabazione delle parole. Inoltre, aspetti della progettazione o del layout della pagina usati per migliorare la presentazione visiva sono del tutto privi di significato per chi non può vederli. Per questi motivi, il tagging del contenuto PDF deve riconoscere che alcuni contenuti all'interno di un PDF dovrebbero essere trattati come un *artefatto* della presentazione visiva o dell'impaginazione. Ad esempio, numeri di pagina, intestazioni e piè di pagina, sfondi ombreggiati o altri elementi grafici di design devono essere identificati in modo che il software di accessibilità che elabora il contenuto sappia ignorarli. ## Panoramica degli standard PDF/A Le richieste per produrre PDF accessibili fanno di solito riferimento a uno standard ISO chiamato [ISO 19005](https://www.iso.org/standard/38920.html), più comunemente noto come PDF/A. Tuttavia, poiché PDF/A è una *famiglia* di standard, richiedere semplicemente la “conformità PDF/A” potrebbe non specificare pienamente i requisiti effettivi. Per capire perché, iniziamo con una breve panoramica di PDF/A dal [sito web della PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (consultato il 21 maggio 2020) che descrive ISO 19005 (PDF/A) come segue: > «Lo scopo principale di ISO 19005 è definire un formato di file basato su PDF, noto come PDF/A, che fornisce un meccanismo per rappresentare documenti elettronici in modo da preservarne l'aspetto visivo statico nel tempo, indipendentemente dagli strumenti e dai sistemi utilizzati per creare, archiviare o rendere i file. > > Uno scopo secondario di ISO 19005 è definire un quadro per rappresentare la struttura logica e altre informazioni semantiche dei documenti elettronici all'interno dei file conformi. > > Un altro scopo di ISO 19005 è fornire un quadro per registrare il contesto e la storia dei documenti elettronici nei metadati all'interno dei file conformi.» Chiaramente, PDF/A ha diversi obiettivi fondamentali. ### Evoluzione e crescita del PDF Il [specifica PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) fu pubblicata nel 1993 e conteneva solo 230 pagine. Tuttavia, 13 anni dopo, la specifica per [la versione PDF 1.7 di Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) supera ampiamente le 1000 pagine! Nel tempo, la dimensione e la complessità della specifica PDF sono cresciute aggiungendo nuove funzionalità supportate: comprendendo nuove tecnologie e i requisiti di flussi di lavoro e casi d'uso basati su PDF sempre più sofisticati in diversi mercati e comunità. Tuttavia, è probabile che nessun utente, o insieme di utenti, utilizzi mai tutte le possibilità: PDF deve “coprire tutti i fronti” per assicurarsi di poter servire le esigenze del mercato più ampio possibile. Ad esempio, molte funzionalità PDF progettate per supportare la stampa commerciale di fascia alta non sono richieste dall'uso quotidiano tipico in ufficio come formato per archiviare o condividere documentazione. ### PDF/A: “ritorno alle basi” per il PDF L'obiettivo fondamentale di PDF/A è garantire che i PDF conformi siano adatti all'archiviazione a lungo termine o contengano contenuti accessibili alle persone che utilizzano varie tecnologie assistive per “fruire” di quei PDF. Per raggiungere questi obiettivi PDF/A limita l'insieme di funzionalità PDF consentite nei file PDF conformi, vietando l'uso di funzionalità che potrebbero compromettere l'archiviabilità o l'accessibilità. Si può pensare a PDF/A come a un insieme di standard che specificano come i file PDF conformi usano un *sottoinsieme* dell'intera specifica PDF per produrre file adatti all'archiviazione a lungo termine o per garantire che il loro contenuto sia accessibile. Le restrizioni di PDF/A consentono di usare i PDF come una “carta digitale d'archivio” indipendente dalla tecnologia di lettura PDF e dall'ambiente informatico usati per accedere al loro contenuto. I PDF conformi non dovrebbero contenere nulla il cui comportamento sia “dipendente dall'implementazione”—cioè dipenda dal software o dai sistemi operativi specifici usati per visualizzarli o elaborarli. I PDF devono anche essere *completi*: le risorse chiave del documento devono essere incorporate nel file—come i font o i profili colore. ### Versioni PDF/A e livelli di conformità Esistono diverse *versioni* dello standard PDF/A, ciascuna delle quali riflette una particolare versione della specifica PDF formale (PDF 1.4, 1.7 e 2.0). Inoltre, esistono vari *livelli di conformità* che specificano a quale aspetto/i dello standard PDF/A un file PDF è conforme. Di conseguenza, quando si dichiara o si richiede la “conformità PDF/A” bisognerebbe pensare a file PDF che sono conformi a **PDF/A-** Ad esempio * PDF/A-1a: significa PDF/A versione 1, livello di conformità a * PDF/A-2b: significa PDF/A versione 2, livello di conformità b Li esploriamo un po' più in dettaglio. #### Versioni PDF/A Lo standard PDF/A è sotto l'egida dell'ISO, pubblicato come standard chiamato ISO 19005. Come osservato, la specifica PDF si è evoluta nel tempo e ciò, a sua volta, ha reso necessari aggiornamenti a ISO 19005, dando origine alla tabella seguente: | | | | | ------------------ | ---------------- | ----------------------------- | | **Versione PDF/A** | **Standard ISO** | **Basato sulla versione PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) | Al momento della stesura (aprile/maggio 2020) un aggiornamento PDF/A-4 (ISO 19005-4) è [in preparazione](https://www.iso.org/standard/71832.html). #### Livelli di conformità PDF/A Oltre a tre versioni PDF/A (PDF/A-1, PDF/A-2 e PDF/A-3) ci sono tre *livelli di conformità*: * Livello A (accessibile) per l'accessibilità (include i requisiti di archiviazione del Livello B) * Livello B (base) per l'archiviazione * Livello U (Unicode) (= archiviazione più uso di Unicode per il testo) Ecco una breve descrizione di questi livelli di conformità: * **Livello B (base)** è il requisito minimo per la conformità secondo PDF/A. Definisce requisiti per garantire che i documenti PDF conformi siano adatti all'archiviazione a lungo termine—that they can always be reliably viewed or printed independent of specific software, tools or operating systems. * **Livello A (accessibilità)** include i requisiti della conformità di Livello B ma, inoltre, richiede l'uso di PDF taggato per fornire struttura logica e informazioni sull'ordine di lettura insieme all'uso di Unicode per consentire l'accesso al testo del documento. * **Livello U (Unicode)** la conformità è stata un livello aggiunto a PDF/A-2 e si basa sul Livello B richiedendo inoltre l'uso di Unicode per il testo del documento, ma non arriva fino al Livello A imponendo informazioni sulla struttura. Le versioni PDF/A e i livelli di conformità possono essere riassunti in una tabella: | | | | | | ------------------------- | ------------------------------ | -------- | -------- | | **Livello di conformità** | **PDF/A-** | | | | Livello A (accessibile) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Livello B (base) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Livello U (Unicode) | N/D (non esisteva per PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Accessibilità universale”) Sebbene la conformità di Livello A dello standard PDF/A vada in parte nella direzione di definire i requisiti per PDF accessibili, un altro standard ISO chiamato [ISO 14289](https://www.iso.org/standard/64599.html), denominato PDF/UA, va oltre. PDF/UA rafforza i requisiti di accessibilità e chiarisce le indicazioni contenute negli standard PDF/A ed è diventato lo standard preferito per i PDF accessibili. #### Protocollo Matterhorn I lettori con un profondo interesse ad approfondire la conformità PDF/UA potrebbero essere interessati al [Protocollo Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) che è “un elenco di tutti i modi possibili per fallire la conformità PDF/UA”. ### Software di validazione Per verificare se un file PDF è conforme a un particolare standard deve essere *validato* utilizzando software di conformità che analizza il PDF per verificare se il suo contenuto e la sua struttura sono conformi ai requisiti di quello standard—come PDF/UA o PDF/A-*x*a (dove *x* = 1, 2 o 3). Si noti che la validazione dei PDF—il loro processamento con uno strumento di validazione preferito—può produrre messaggi diagnostici o avvisi che possono essere piuttosto criptici per l'utente non esperto—forse a causa di alcuni dati PDF di basso livello (o della struttura) che non soddisfano lo standard pertinente. Per molti autori, interpretare tali avvisi e convertirli in una correzione attuabile per il/i loro documento/i può essere una vera sfida. #### Software di validazione gratuito * [veraPDF](https://verapdf.org/) che, per citare il loro sito web (consultato il 28 maggio 2020), è un “validatore del formato file open source, progettato appositamente, che copre tutte le parti e i livelli di conformità di PDF/A”. * (solo Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) che è uno “...strumento gratuito di controllo dell'accessibilità PDF che è stato provato e testato dal 2010”. #### Software di validazione commerciale * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) fornisce una suite di test di validazione PDF insieme a strumenti per modificare e correggere i tag nei file PDF non conformi. ### PDF Association: un'ottima fonte di informazioni Il [PDF Association](https://www.pdfa.org/) produce molte *eccellente* risorse su PDF/A, PDF/UA e molti altri argomenti relativi ai PDF—inclusi video sul loro [canale YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) insieme a articoli e pubblicazioni tecniche gratuite disponibili sul loro sito web. Una di queste pubblicazioni è [PDF/UA in poche parole](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) che fornisce un'introduzione preziosa allo standard PDF/UA e ai suoi requisiti. ## PDF accessibili dai motori TeX e da LaTeX Speriamo che le discussioni precedenti abbiano indicato che la produzione di file PDF pienamente accessibili e correttamente taggati sia una sfida tecnica impegnativa. Inoltre, anche il semplice esempio di Microsoft Word ha dimostrato che gli autori possono molto facilmente usare combinazioni di funzionalità software che danno luogo a documenti PDF taggati che non soddisfano i criteri di accessibilità. Come strumento di authoring, LaTeX offre agli autori una flessibilità quasi illimitata nella gamma e nella complessità dei documenti che si possono creare—che potrebbe essere proprio la ragione per cui lo si è scelto in primo luogo. LaTeX supporta anche l'estensibilità tramite migliaia di pacchetti aggiuntivi che gli autori possono usare come parte dei loro documenti. Oltre a tutto ciò, gli autori hanno la libertà di scrivere nuove macro TeX o LaTeX, o ridefinire quelle esistenti, per ottenere effetti specifici. Tuttavia, forse questa libertà e flessibilità ha un prezzo, perché il contenuto prodotto dalle innumerevoli interazioni di tutti quei pacchetti e macro LaTeX “in qualche modo” deve essere orchestrato se LaTeX deve generare automaticamente output PDF correttamente taggati e accessibili. In pratica, l'estensibilità, la potenza, la versatilità e la “libertà” di authoring conferite da LaTeX pongono sfide tecniche alla produzione fluida e trasparente (“automatica”) di documenti PDF taggati pienamente accessibili che siano conformi agli standard PDF/UA o PDF/A-{1|2|3}a. La più ampia comunità TeX e LaTeX sta lavorando duramente per affrontare tali sfide e il TeX User Group (TUG) sta coordinando gli sforzi di ricerca e sviluppo attraverso il PDF accessibility and PDF standards [gruppo di lavoro](https://www.tug.org/twg/accessibility/). Esiste una [lista di discussione](https://tug.org/mailman/listinfo/accessibility) che fornisce un modo per le parti interessate di discutere la produzione di file PDF taggati usando TeX e LaTeX. In queste discussioni vale la pena ricordare che LaTeX in realtà non è un programma eseguibile di impaginazione, ma una grande raccolta di macro sofisticate (comandi) scritte in un linguaggio di livello inferiore chiamato TeX. Tra il vostro documento LaTeX accuratamente elaborato e il PDF finale impaginato c'è un pezzo di software chiamato motore TeX il cui compito è “eseguire” la raccolta di comandi LaTeX (cioè macro) usati per scrivere e costruire il vostro documento—convertendoli nella rappresentazione impaginata del vostro documento salvata come file PDF. Chi è nuovo all'ecosistema TeX/LaTeX è spesso, e comprensibilmente, confuso dalla pletora di nomi dal suono criptico usati per gli strumenti che incontra: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX e LuaLaTeX. Se vi sentite allo stesso modo, l'aiuto è a portata di mano nell'articolo di Overleaf [Che cosa c'è in un nome: una guida alle molte sfumature di TeX](/latex/it/articoli-approfonditi/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) che spiega l'origine e il significato di tutti questi termini. I motori TeX come pdfTeX, XeTeX o LuaTeX sono una classe di software chiamata *compilatori di documenti*: prendono il vostro codice LaTeX e lo compilano nella sua forma impaginata “convertendo” le macro (comandi) LaTeX di nuovo nelle loro istruzioni del linguaggio TeX di livello inferiore che vengono “eseguite” per produrre il risultato impaginato. I sistemi di impaginazione basati su TeX sono in grado di produrre contenuti eccezionalmente complessi—tra cui matematica avanzata, notazione musicale, strutture chimiche, grafica e testo impaginato multilingue sofisticato. Per garantire che tali documenti complessi siano conformi agli standard e alle normative di accessibilità, i motori TeX, insieme alla raccolta di macro LaTeX e ai pacchetti LaTeX, devono generare file PDF opportunamente taggati incorporando una grande quantità di dati aggiuntivi nei file PDF che generano. Anche se i motori TeX possono generare file PDF estremamente complessi, i loro processi interni, algoritmi e funzioni non hanno *integrate* funzionalità *specificamente progettate* per supportare la produzione di PDF taggati e accessibili. Al contrario, il supporto al tagging e all'accessibilità deve essere ottenuto tramite una programmazione complessa di macro che “iniettano” dati aggiuntivi nei PDF generati dai motori TeX—creando le sequenze di contenuto marcato, gli elementi di struttura e le strutture dati della struttura logica memorizzate in `StructTreeRoot`. Ed è qui che quell'“orchestrazione” entra chiaramente in gioco: il codice nel nucleo (kernel) di LaTeX insieme al codice in migliaia di pacchetti e in innumerevoli macro create dagli autori dovrebbe cooperare con estrema attenzione per garantire che l'esecuzione delle macro produca un tagging corretto del contenuto dei documenti risultanti. Quell'“orchestrazione” dovrebbe essere affidabile—indipendentemente da come gli autori scelgano di combinare e usare le funzionalità, i comandi e la funzionalità di LaTeX, il suo sistema di pacchetti e la potenza delle macro TeX. ### Le esigenze degli autori Per la maggior parte delle persone, LaTeX è solo uno strumento che consente di creare documenti impaginati in modo bello con la libertà di scegliere i pacchetti che vi aiutano a raggiungere questo obiettivo. La grande maggioranza degli autori LaTeX vuole semplicemente che i propri documenti “funzionino”: che siano impaginati senza errori così da poter presentare la tesi, l'articolo, il rapporto o finire quel libro tanto atteso. Non irragionevolmente, gli utenti di LaTeX si aspettano che la raccolta di pacchetti LaTeX da loro scelta coesista pacificamente, interoperando in modo fluido e trasparente per fornire i comandi e le funzionalità necessari a produrre i loro documenti. Gli stessi desideri si ritrovano probabilmente quando ci si trova di fronte al requisito di produrre PDF taggati da LaTeX: dovrebbe “semplicemente funzionare”, in modo trasparente e con un intervento minimo da parte dell'autore. Purtroppo, siamo ancora lontani dall'esperienza del “Ecco fatto! il tagging accade e basta, qualunque cosa strana io faccia”. Collegare i requisiti tecnici dell'accessibilità con il PDF taggato e la libertà di authoring di LaTeX è intrinsecamente complesso e, forse, può essere inevitabile che sia necessaria una qualche forma di “disciplina dell'autore” se le sfide tecniche devono diventare adatte a un'implementazione e a una risoluzione pratiche. Una questione separata, ma correlata, è che un tagging errato potrebbe non avere alcun impatto visivo sul PDF finale: visivamente, potrebbe apparire perfetto e probabilmente verrebbe stampato senza problemi, ma, a insaputa dell'autore, il tagging potrebbe essere “rotto”, per essere scoperto solo in seguito tramite il fallimento dei controlli di conformità/validazione PDF/A e/o ulteriori test pratici mediante software di accessibilità come i lettori di schermo. ### File PDF prodotti su Overleaf Overleaf fornisce alla propria comunità di utenti un editor LaTeX basato su browser insieme a strumenti di gestione di progetti e documenti che facilitano la scrittura collaborativa—tutto costruito sopra un'installazione standard di TeX Live. In effetti, Overleaf consente agli utenti di “eseguire LaTeX a distanza” tramite un browser web, fornendo un livello di protezione rispetto alle complessità della gestione e della manutenzione di un sistema completo TeX Live. Una conseguenza dell'uso da parte di Overleaf di un'installazione standard TeX/LaTeX è che i PDF prodotti dal codice LaTeX scritto nell'editor di Overleaf vengono creati usando esattamente le stesse tecnologie presenti in qualsiasi altra installazione TeX Live della stessa versione—inclusi i setup installati dagli utenti sui loro dispositivi locali. L'unica differenza è che i motori TeX che compilano ed elaborano il codice LaTeX di Overleaf eseguono su server remoti, non su macchine locali. Overleaf linearizza il PDF generato da TeX per un download/visualizzazione efficiente in un browser, ma tale processo non è correlato all'accessibilità del contenuto del PDF in sé. La produzione di PDF accessibili tramite Overleaf si basa sulle capacità e sulle funzionalità integrate nei motori TeX standard insieme alla disponibilità di pacchetti di macro LaTeX adatti che gli utenti possono impiegare come parte del loro documento. I documenti LaTeX creati usando Overleaf devono rimanere compatibili con altre installazioni TeX e LaTeX perché gli utenti spesso devono esportare il loro progetto LaTeX da Overleaf per la sottomissione a un'ampia gamma di sistemi di riviste e editori. Introdurre funzionalità specifiche di Overleaf nei suoi documenti LaTeX, o nei motori TeX sottostanti, limiterebbe seriamente la libertà degli utenti di usare il proprio lavoro altrove. Overleaf riconosce e supporta la necessità di PDF pienamente accessibili generati da sistemi di authoring TeX/LaTeX: investiamo tempo nella ricerca dei problemi di accessibilità, esplorando gli ultimi sviluppi nei motori TeX e nei pacchetti LaTeX sperimentali che supportano il PDF taggato. In definitiva, al momento della stesura, non esiste una soluzione “pronta all'uso” che gli autori LaTeX possano usare (tramite `\usepackage`) per generare in modo fluido e trasparente PDF pienamente accessibili e conformi a PDF/UA da documenti LaTeX generici. Quando tali soluzioni saranno disponibili tramite gli aggiornamenti di TeX Live, diventeranno naturalmente disponibili alla comunità di utenti Overleaf. ### Alcuni pacchetti LaTeX per esplorare il tagging e l'accessibilità Per molte persone, [tex.stackexchange](https://tex.stackexchange.com/) è il primo punto di riferimento per l'aiuto con TeX, LaTeX o ConTeXt. È una risorsa straordinaria e contiene molte domande sul tema dell' [accessibilità](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) e della produzione di PDF accessibili tramite LaTeX. Se leggete e consultate queste domande, e il successivo flusso di risposte e commenti, una sola conclusione è inevitabile: al momento non esiste una soluzione completa, di livello produttivo, per creare automaticamente PDF pienamente accessibili, conformi agli standard e taggati da ogni tipo di documento LaTeX. Tuttavia, esistono alcuni pacchetti che supportano il tagging—anche se, forse, entro un ambito di casi d'uso e tipi di documento limitato. Il seguente elenco è fornito per i lettori che desiderano esplorare il tagging PDF basato su LaTeX: * [`tagpdf` che fornisce i comandi e le funzionalità necessarie per includere file grafici esterni. L'esempio sopra carica il](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): pacchetto altamente capace progettato per sperimentare il tagging PDF. Supporta pdfTeX e LuaTeX e fornisce una documentazione estremamente utile e interessante che contiene alcune ottime note sulle sfide tecniche della creazione di PDF taggati tramite motori TeX; è una lettura fortemente consigliata per chiunque voglia comprendere meglio i problemi coinvolti. La direzione futura sarà probabilmente orientata verso LuaTeX. * [`axessibility` che fornisce i comandi e le funzionalità necessarie per includere file grafici esterni. L'esempio sopra carica il](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov e Università di Torino): fornisce accesso alle formule nei file PDF tramite tecnologie assistive. * [`accessibilità` che fornisce i comandi e le funzionalità necessarie per includere file grafici esterni. L'esempio sopra carica il](https://ctan.org/pkg/accessibility) (Andy Clifton): crea file PDF taggati e strutturati. Le note CTAN indicano che questo pacchetto è “destinato agli utenti delle classi di documento KOMA-Script”. * [`accsupp` che fornisce i comandi e le funzionalità necessarie per includere file grafici esterni. L'esempio sopra carica il](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): pacchetto sperimentale per fornire un migliore supporto all'accessibilità per i file PDF. Un altro riferimento degno di nota è un articolo del 2018 [Implementazione degli standard PDF per l'editoria matematica](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) del Dr Ross Moore del Dipartimento di Matematica, Macquarie University. In quell'articolo il Dr Moore include una breve panoramica delle sfide del tagging dei PDF in LaTeX: > «La principale fonte di difficoltà risiede nel modo in cui ambienti diversi possono interagire tra loro. Ci sono molte situazioni in LaTeX in cui un ambiente o una struttura non è davvero completata fino a quando non è iniziata la successiva. Quindi non si tratta semplicemente di avvolgere ogni pezzo di contenuto fornito con tag di inizio e fine. Occorre invece comprendere le sottigliezze di come i diversi ambienti e altre strutture iniziano e terminano realmente, nel contesto stabilito dal materiale circostante.» Il Dr Moore è anche l'attuale manutentore del [`pacchetto pdfx`](https://ctan.org/pkg/pdfx) e un esperto e pioniere del PDF taggato usando TeX/LaTeX. Il suo lavoro merita sicuramente una ricerca—compreso questo video su YouTube che fornisce interessanti approfondimenti: {% embed url="" %} #### Nota sul pacchetto pdfx Il [`pacchetto pdfx`](https://ctan.org/pkg/pdfx) Il pacchetto (Ross Moore et al.) offre un eccellente supporto per PDF/A-1|2|3b (archiviazione) e altre opzioni, ma non produce ancora PDF taggati. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/it/altri-argomenti/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.