> 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/no/flere-emner/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # En introduksjon til taggede PDF-filer: interne detaljer og utfordringene med tilgjengelighet ## Oppdatering: januar 2026 Se [Overleafs instruksjoner om å lage taggede PDF-er](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Den [LaTeX-teamet](https://latex-project.org/) har lansert nye funksjoner som gjør automatisk PDF-tagging mulig, det sentrale kravet for PDF-tilgjengelighet. Disse nye funksjonene er tilgjengelige i Overleaf i [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), med nyere oppdateringer tilgjengelige i den rullerende TeX Live-utgaven tilgjengelig via [Overleaf Labs](https://www.overleaf.com/labs/participate). Det er nå mulig å produsere en tagget PDF fra LaTeX-kilde som er i samsvar med WCAG 2.1 nivå AA ved å følge [vår brukerdokumentasjon](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) ved bruk av TeX Live-utgivelser som er tilgjengelige i Overleaf. Artikkelen nedenfor fra 2020, selv om den ikke er oppdatert med den nyeste informasjonen om LaTeX-tilgjengelighet, kan fortsatt leses av interesse og for bakgrunnsinformasjon om PDF-tagging. *** ## Hva dekker denne artikkelen? Målet med denne artikkelen er å gi en introduksjon til tagget PDF sammen med en oversikt over noen tekniske utfordringer som programvare møter, inkludert TeX-motorer og LaTeX, som har som mål å produsere taggede og tilgjengelige PDF-filer. Tilgjengelighet, særlig for PDF-er, er et bredt og komplekst tema, som også har tekniske utfordringer som ikke alltid har én enkelt, universelt avtalt eller akseptert løsning – for eksempel hvordan man representerer kompleks matematikk i PDF-er på en tilgjengelig måte: ved bruk av MathML eller LaTeX-kode? Selv om vi ikke kan gå i dybden på hvert tema, og må forenkle mange detaljer, kan vi ta en titt inne i PDF-er for å vise hva det egentlig innebærer å tagge en PDF. Overleaf håper denne artikkelen vil være en nyttig introduksjon, og gi tilstrekkelig bakgrunn til å gjøre leserne bedre i stand til å forstå de tekniske utfordringene og støtte videre lesing og utforsking av tagget PDF og tilgjengelighet. Ressurser i denne artikkelen inkluderer: * [en 8-minutters video](#video-showing-the-logical-structure-of-a-tagged-pdf) som utforsker en tagget PDF produsert av LaTeX; * [et Overleaf-prosjekt](#using-luatex-an-example-in-the-overleaf-gallery) for å utforske bruk av mellomromstegn i LuaTeX; * [lydopptak](#tagged-yes-but-the-reading-order-is-incorrect) som demonstrerer problemer med PDF-tilgjengelighet. ## Innledning Å sikre tilgjengelighet for digitalt innhold blir med rette anerkjent som et viktig aspekt ved produksjon og distribusjon av innhold. Videre vedtar myndigheter, inkludert [Storbritannia](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) og [USA](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), lover som krever at innhold produsert under deres jurisdiksjon skal oppfylle definerte tilgjengelighetskriterier. Samsvar via publisering av innhold i HTML er ikke spesielt byrdefullt, men å sikre nødvendig nivå av tilgjengelighet for dokumenter distribuert i PDF-format kan være en betydelig teknisk utfordring – avhengig av programvaren som brukes til å lage innhold som skal ut som en PDF-fil. PDF dukket opp tidlig på 1990-tallet som en løsning på problemer knyttet til pålitelig dokumentoverføring, og historien har vist at den var en enorm suksess. PDF er imidlertid også et komplekst filformat som oppstod før behovet for å legge til rette for tilgjengelighet av dokumentinnhold ble allment anerkjent og akseptert. Likevel har PDF-spesifikasjonen over tid utviklet seg for å tilby funksjoner som muliggjør og støtter produksjon av tilgjengelige PDF-dokumenter ved bruk av en «stilisert» variant av PDF som Adobe kaller *tagget PDF*. I praksis stiller produksjonen av taggede –*og fullt tilgjengelige*– PDF-filer betydelige ekstra tekniske krav til programvare som genererer PDF – og det inkluderer TeX-motorer og LaTeX-økosystemet av makroer og tilleggspakker for LaTeX. ## PDFs opphav som digitalt sluttdokument Den [opphavet til Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) stammer fra en tid da overføring av dokumenter mellom datamaskiner var forbundet med vanskeligheter, ofte forårsaket av filkonverteringer som førte til sideombrudd og andre avvik, forsterket av inkompatible fonter og tekstkodinger som ble brukt på ulike operativsystemer (særlig Windows og Macintosh). Forfatteren av dette dokumentet jobbet i forlagsbransjen på den tiden og har levende minner om å håndtere disse utfordringene! PDF ble utformet for å løse problemer med fildeling ved å innføre et universelt, endelig (ikke-redigerbart) digitalt papir, som muliggjorde sømløs overføring av selvstendige dokumenter som inneholdt fontene som trengtes for å vise dem. Brukere kunne endelig overføre alle slags dokumenter med rimelig sikkerhet om at mottakerne, uansett dataplattform, kunne åpne og lese dem – dokumenttrofastheten ble bevart og rotete sideombrudd samt problemer med fontkompatibilitet/-tilgjengelighet hørte fortiden til. ### Digitalt papir: bra for alle brukere? PDFs avstamning som en form for digitalt papir tok naturlig utgangspunkt i bruk av trykte sidetall, typografi eller designelementer som signaler for visuell navigasjon i innholdet – på skjerm eller på papir. Slike visuelle signaler/mekanismer er naturligvis meningsløse for personer med alvorlig synsnedsettelse. I dag blir bedre tilgjengelighet for digitalt innhold med rette anerkjent som et viktig aspekt ved produksjon og distribusjon av innhold. Utfordringen for PDF var å tilby mekanismer som legger til rette for ikke-visuell tilgang til innhold som er låst inne i en «beholder» som opprinnelig ble utformet for å gjenskape det visuelle mediet til den trykte siden. Den første versjonen av PDF-spesifikasjonen (PDF 1.0) ble [offisielt utgitt 15. juni 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) etterfulgt av nye versjoner med oppdateringer som i 2001 (PDF 1.4) inkluderte innføringen av «tagget PDF», som [«...gjorde det mulig for brukere av hjelpemiddelteknologi»](https://www.adobe.com/accessibility/pdf.html). Påfølgende utgivelser av PDF-spesifikasjonen har utvidet og forbedret funksjonene i PDF, og kulminerte i den nyeste utgaven (PDF 2.0) som, basert på [rapporter](https://www.pdfa.org/tagged-pdf-2-0/), har gjort tilgjengelighetsfunksjonene betydelig omarbeidet – selv om PDF 2.0 ennå ikke er godt støttet av TeX-motorer. ## Innhold inne i PDF-er For å forstå problemene som er involvert, er det verdt å undersøke hvordan PDF-filer faktisk representerer sideinnholdet de inneholder. Dypt inne i en PDF-fil ligger innholdet for hver side i sidens *innholdsstrøm*: en sekvens av PDF-operatorer («kommandoer») som plasserer tekst eller grafikk på et bestemt sted på siden for gjengivelse (visning) av programvaren som brukes til å *vise* PDF-en. I praksis gir innholdsstrømmen en grafisk beskrivelse eller en «oppskrift» som forteller PDF-visningsapplikasjoner hvordan de skal «tegne» hver side – ved å definere hva som skal vises på siden, og hvor. Naturligvis inkluderer den serien av operatorer instruksjoner om å velge bestemte fonter i en bestemt størrelse, velge farger, definere linjebredder, tegne linjer, kurver og så videre – alt som trengs for å gi en fullstendig grafisk beskrivelse for visuell presentasjon av en side. For å redusere filstørrelsen komprimeres PDF-innholdsstrømmer og lagres i et kompakt binært format, men hvis du har tilgang til passende programvare, for eksempel Adobe Acrobat Pro DC, kan du bruke den til å vise en «dekomprimert» ren tekstversjon av sideinnholdsstrømmer. La oss vurdere hvordan PDF-operatorer kan «tegne» en tabell: PDF-innholdsstrømmen ville inneholde en passende sekvens av operatorer for å produsere horisontale/vertikale linjer, velge ulike fonter og skrive ut tekst plassert på forskjellige steder på siden for å produsere innholdet i tabellen. For å demonstrere dette, la oss se på et veldig enkelt, ikke-tagget PDF-dokument som ikke inneholder noe mer enn en grunnleggende tabell med noe tekst – laget i Microsoft Word av grunner som blir tydelige senere i artikkelen. Her er et skjermbilde som viser vår enkle PDF: ![En tabell laget i Microsoft Word](/files/c59b5c9b0905d89b7adad2d3a11809d8c2d3fc6f) Hvis vi trekker ut den (dekomprimerte) sideinnholdsstrømmen for denne filen og limer de første linjene inn i en tekstredigerer, kan vi oppsummere noen av PDF-operatorene for å få et «inntrykk» av hvordan PDF-filer «beskriver» innholdet som vises på denne siden. ![Bilde av innholdsstrøm i en PDF-fil](/files/cc153a6632fa6815bdefc1a42a11b5b4c58f6732) Hvis du har tilgang til Adobe Acrobat Pro DC, kan du bruke det til å liste opp operatorene som finnes i en sideinnholdsstrøm i PDF. Her er Acrobats *Intern PDF-struktur* visning av den samme PDF-en, som hjelpsomt gir en ettlinjesbeskrivelse av hver operator som brukes til å «tegne» vår enkeltside med en grunnleggende tabell – merk at disse korte beskrivelsene er gitt av Adobe Acrobat Pro DC, de *inneholder* finnes i selve PDF-filen: ![Bilde av en PDF-innholdsstrøm vist i Adobe Acrobat Pro DC](/files/5c41051cf32273302b5fcdc8a49c03c2bd639fa8) Legg imidlertid merke til at ingen av disse tegningsinstruksjonene (operatorene) lagrer noen «betydning» eller «beskrivelse» av hva de faktisk produserer: de er bare et sett med grafikkoperatorer som resulterer i konstruksjonen av det en *seende observatør gjenkjenner* som en tabell. Tydeligvis er det, for personer med alvorlig synsnedsettelse, ikke en gangbar metode for å få tilgang til innholdet å vise tabellen som disse grafiske operatorene i PDF-ens innholdsstrøm gir. Det som trengs er en mekanisme for at PDF-filer skal inneholde en passende ikke-visuell (maskinlesbar) beskrivelse av den tabellen – og selvfølgelig alt annet innhold som finnes på sidene inne i en PDF-fil. For å muliggjøre ikke-visuell tilgang til innhold må PDF-filer inneholde tilleggsdata som knytter «betydning» eller semantikk til samlinger eller grupper av operatorer som brukes til å «tegne» et bestemt innholdsstykke. Nødvendigvis må dette prinsippet om å tildele eller gi «betydning» omfatte alle former for innhold i en PDF: den mekanismen finnes og kalles *tagging* av PDF-en for å produsere en «variant» av PDF kalt, ikke overraskende, *tagget PDF*. ## Innledning til tagget PDF Tagget PDF er navnet på en bestemt type PDF-fil som inneholder tilleggsdata (og datastrukturer) som ikke finnes i ikke-taggede PDF-filer. Selv om prinsippene/ideene bak tagget PDF egner seg for en overordnet beskrivelse, er de fullstendige detaljene komplekse og opptar mange sider i den formelle PDF-spesifikasjonen. Adobe utformet tagget PDF for å oppnå en rekke mål, inkludert å gjøre innhold tilgjengelig for brukere med synsnedsettelser, men det omfatter også følgende liste hentet fra seksjon 10.7 i [Adobes PDF 1.7-spesifikasjon](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * enkel uttrekking av tekst og grafikk for innliming i andre applikasjoner; * automatisk omslåing av tekst og tilhørende grafikk for å passe til en side med en annen størrelse enn den som ble antatt for den opprinnelige layouten; * behandling av tekst til formål som søk, indeksering og stavekontroll; * konvertering til andre vanlige filformater (som HTML, XML og RTF) med dokumentstruktur og grunnleggende stilinformasjon bevart. I tillegg krever tagget PDF også: * at tekst i PDF-innhold skal representeres i en form som kan konverteres til Unicode; * ordskiller må representeres eksplisitt – merk at TeX-motorer ikke bruker mellomromstegn for å skille ord, de bruker TeXs fleksible mellomrom kalt glue (se nedenfor); * det faktiske («virkelige») innholdet skilles fra layout- og pagineringsartefakter. Under tagget PDF ligger to nøkkelbegreper som vi skal gjennomgå: * definere den logiske strukturen til innhold i en PDF-fil; * merking (tagging) av PDF-innhold med et sett standard innholdstyper. ## Logisk struktur I lengre dokumenter deles innhold vanligvis inn i en sekvens av mindre innholdselementer; for eksempel deles bøker typisk inn i kapitler som igjen er delt inn i seksjoner og underseksjoner som inneholder avsnitt, tabeller, figurer/diagrammer, punktlister eller nummererte lister, fotnoter og referanser og så videre. Strukturen og organiseringen av innholdet i en slik bok, eller hvilken som helst annen dokumenttype, omtales som dens *logiske struktur*. Forestillingene om et dokuments logiske struktur spiller en viktig rolle for tilgjengeligheten av PDF-er, men som konsept kan logisk struktur virke litt vag og vanskelig å forstå. Følgende definisjon fra [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) gir nyttig innsikt: > «Logisk struktur viser til måten informasjon i et dokument er organisert på; den definerer hierarkiet i informasjonen og forholdet mellom ulike deler av dokumentet. Logisk struktur viser hvordan et dokument er bygd opp, i motsetning til hva et dokument inneholder.» Legg merke til at denne definisjonen av logisk struktur ikke henviser til nøyaktig *hvordan* hvor denne strukturelle informasjonen er lagret fysisk; bare at den gir en representasjon av dokumentets struktur og organisering. De presise detaljene om hvordan et dokuments logiske struktur lagres eller representeres er implementeringsavhengige: en funksjon av programvaren som brukes til å generere og behandle den. ### Logisk struktur i PDF-er PDF-spesifikasjonen gir mekanismer som gjør at et dokuments logiske struktur kan lagres i en PDF-fil – til bruk for programvare som for eksempel kan ønske å eksportere PDF-ens innhold til andre formater som XML, HTML eller Microsoft Word. Disse eksportprosessene må produsere et korrekt strukturert tekstdokument som samsvarer med reglene for det målrettede eksportfilformatet – noe som best oppnås når eksportbehandlingen styres av logisk struktur-informasjon som finnes i PDF-en. I tillegg er den logiske strukturen til en PDF-fil avgjørende for tilgjengelighetsprogramvare som for eksempel kan ønske å utføre tekst-til-tale-operasjoner, og lese innhold høyt for en person med synsnedsettelser. Tekst-til-tale-prosessen må sikre at innhold blir lest høyt i riktig rekkefølge/sekvens, ellers vil den produsere meningsløse resultater. Legg også merke til at selve begrepet side kanskje ikke gir noen meningsfull mening for tilgjengelighetsapplikasjoner som bare er interessert i PDF-ens innhold og dokumentets struktur, ikke den visuelle inndelingen og presentasjonen i side-store biter. #### Navngi innholdselementer Å registrere (lagre) den logiske strukturen til et PDF-dokument krever et sett med meningsfulle navn tildelt de ulike *typene* innholdselementer som sannsynligvis finnes som en del av et typisk PDF-dokument – som identifiserer seksjoner av innhold som representerer overskrifter, avsnitt, tabeller, lister og så videre. I tillegg har enkelte innholdselementer som innholdsfortegnelse, nummererte/punktvise lister og tabellmateriale ganske komplekse egne strukturer, så det trengs også noen retningslinjer/regler for å spesifisere hvordan disse mer komplekse innholdselementene er bygget opp – deres understruktur. Et ytterligere krav er å tydelig identifisere alt PDF-innhold som skal ignoreres av hjelpesoftware som behandler PDF-en; for eksempel er topp- og bunntekster sideinndelingsartefakter som inneholder tekst som er overflødig for personer med alvorlig synsnedsettelse: det innholdet skal ignoreres. Mekanismene som brukes av PDF for å definere et dokuments logiske struktur er utformet for å være fleksible, så i prinsippet kunne ulike applikasjoner som genererer og behandler PDF-filer bruke navn for innholdstyper etter hvilken som helst konvensjon de ønsker. For å maksimere dokumentutveksling og tillate at ulike PDF-behandlingsapplikasjoner gir konsistente resultater, definerte Adobe imidlertid et sett med standardnavn for typer innholdselementer som PDF-genereringsprogramvare bør følge. Innenfor PDF-spesifikasjonen omtales disse standardnavnene som tagger, noe som gir opphav til forestillingen om *tagget* PDF. ### Merking av PDF-innhold: Et blikk «under panseret» For å gjøre diskusjonen litt mindre abstrakt skal vi ta en kort titt på internals i taggede PDF-filer – selv om vi ikke kan dekke alle detaljene fordi tagget PDF er et så stort og komplekst tema. #### Markerte innholdssekvenser: byggeklosser for tagget PDF På laveste nivå begynner prosessen med å registrere betydningen av innhold som finnes på en PDF-side (dvs. i innholdsstrømmen) med *markerte innholdssekvenser* som brukes til å identifisere (gi «betydning» til) klynger eller grupper av PDF-operatorer. Markerte innholdssekvenser tildeles en numerisk identifikator kalt dens `MCID` (*markert innholdsidentifikator*) som er et heltall som går fra 0 til en viss maksimal N på hver side. Disse `MCID` verdiene gir en måte å unikt identifisere sekvenser av operatorer i innholdsstrømmen på en bestemt side. For å presisere: for hver side starter `MCID` identifikatorene på 0 og øker sekvensielt opp til en viss maksimalverdi som avhenger av hvor mange markerte innholdssekvenser som finnes i innholdsstrømmen til en bestemt side. Markerte innholdssekvenser er i praksis grunnleggende «byggeklosser» som brukes til å sette sammen høyere nivå datastrukturer kalt *struktur-elementer*. Disse struktur-elementene inneholder en tagg, som er navnet som brukes til å identifisere hvilken type innholdselement de representerer. #### Eksempel på struktur-elementer Her hopper vi litt fremover, men det er verdt å gjennomgå et eksempel. Anta at du har 3 små tekstutdrag av sideinnhold, og hvert av dem er identifisert i innholdsstrømmen av en annen markert innholdssekvens. Hvert av disse 3 tekstutdragene kan pakkes inn i sitt eget struktur-element, med en tagg, og alle tre kan «kobles sammen» ved hjelp av et annet struktur-element for å representere et innholdselement på et høyere nivå, for eksempel en linje i en innholdsfortegnelse. ![Bilde som forklarer struktur-elementer og markerte innholdssekvenser](/files/f1340119dcbb4a3a6af5ae3ae05cf53bca92257c) Gjennom en form for foreldre–barn-datasammenheng kombineres samlinger av struktur-elementer for å skape koblede datastrukturer som representerer mer komplekse dataelementer som nummererte og punktvise lister, tabeller, matematikk og så videre. Til slutt kobles hele samlingen av struktur-elementer i hele PDF-filen sammen og kombineres for å skape den logiske strukturen til PDF-dokumentet – vi kommer tilbake til dette senere i artikkelen. ### Hva er en markert innholdssekvens? I diskusjonen ovenfor brukte vi et enkelt, ikke-tagget PDF-dokument som inneholdt en tabell (laget i Microsoft Word), men hvis vi ber Word lage en tagget PDF kan vi se at noe ekstra markering har dukket opp i sideinnholdsstrømmen. Her ser vi bare på de første linjene i innholdsstrømmen (det er hundrevis av linjer), men legg merke til tilstedeværelsen av ekstra operatorer som `/P <> BDC` og `EMC` som brukes til å identifisere en markert innholdssekvens. Vi vil ikke utforske den fulle syntaksen til markerte innholdssekvenser, men viser leseren til side 862 i [Adobes offisielle PDF 1.7-spesifikasjon](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Bilde som viser markerte innholdssekvenser i en tagget PDF-innholdsstrøm](/files/a0b34a0e981f495e19989107424f5760d342d315) For enkel referanse viser vi igjen den ikke-taggede versjonen: ![Bilde som viser PDF-innholdsstrøm](/files/cc153a6632fa6815bdefc1a42a11b5b4c58f6732) I *ikke-tagget* PDF, operatorer som `/P <> BDC` og `EMC` er fraværende, men de gjenværende operatorene er uendret: den ikke-taggede PDF-en mangler den ekstra markeringen som brukes til å identifisere bestemte sekvenser/samlinger av operatorer. Igjen kan vi også bruke Adobe Acrobats *Intern PDF-struktur* funksjon til å vise de markerte innholdssekvensene i en innholdsstrøm – her har vi fremhevet dem med en grønn kant: ![Bilde som viser markerte innholdssekvenser i en tagget PDF-innholdsstrøm vist i Adobe Acrobat Pro DC](/files/da30ce35c327407ff0f794df2f3446d0fe43b278) Legg merke til at noen innholdsdeler er markert med `/Artifact` som identifiserer materiale på PDF-siden som skal *ignoreres* av hjelpesoftware, slik som de som leser høyt for synshemmede. Følgende skjermbilde viser en utvidet visning av den første markerte innholdssekvensen – den med `MCID` verdien av `0`. Slutten på den markerte innholdssekvensen identifiseres av PDF-operatoren `EMC`. ![Bilde som viser detaljene i operatorene som omfattes av en markert innholdsstrøm](/files/3a2e45a59e3f6fb8594a0a5c74644f7005b519ca) ### Lagring av den logiske strukturen Som nevnt er det, i tillegg til å gi en beskrivelse av individuelle innholdselementer (avsnitt, lister, tabeller osv.), nødvendig for tilgjengelige PDF-er å inneholde en representasjon av hele dokumentet i form av dets logiske struktur. Enkelte deler av tilgjengelig innhold må kobles sammen for å skape et komplett, navigerbart og tilgjengelig dokument – liknende hvordan et enkelt HTML-dokument bygges opp av avsnitt, grafikk og tabeller for å skape en webside. Videre er det avgjørende at den logiske strukturen i et PDF-dokument sikrer at alt innhold kan navigeres i riktig *leserekkefølge*, uavhengig av rekkefølgen innholdet på siden ble skrevet ut til PDF-ens sideinnholdsstrømmer. Vi skal utforske leserekkefølge mer detaljert nedenfor. #### Logisk struktur: et «tre» av struktur-elementer Vi har nevnt at PDF-er bruker noe som kalles en *struktur-element* for å representere individuelle innholdselementer, og at et struktur-element inneholder en tagg for å identifisere hvilken innholdstype det representerer. For å gi en representasjon av dokumentets logiske struktur kobles alle struktur-elementene sammen ved hjelp av foreldre–barn-forhold, og organiseres i et «strukturtre». Internt inneholder taggede PDF-filer et objekt kalt `StructTreeRoot` som inneholder (peker på) struktur-elementer som fungerer som startpunkt eller «rot» for dokumentets logiske strukturtre. Vanligvis starter «roten» i strukturtreet med ett enkelt struktur-element som er tagget `Document` som inneholder tallrike *underordnede* struktur-elementer som til sammen representerer hele dokumentets innhold. All programvare som er utformet for å produsere tilgjengelige PDF-er via tagging, må bygge denne svært komplekse datastrukturen (og andre!) – og det inkluderer TeX-motorer og LaTeX. Et eksempel på et slikt dokumentstrukturtre (`StructTreeRoot`) er vist i følgende skjermbilde av en tagget PDF åpnet i Adobe Acrobat Pro DC: ![Bilde som viser StructTreeRoot i en tagget PDF](/files/c0ddcb8df6b9f6d9c4e214b11175fccd85ac3395) Sammenlign strukturen ovenfor med versjonen uten tagger: ![Bilde som viser fraværet av StructTreeRoot i en ikke-tagget PDF](/files/d8656c6b11a59b68da9df2800611e4c0b8216e73) ### Utforsking av den logiske strukturen i PDF-er Vi begynner med noen grafikker for å oppsummere det vi har dekket, og avslutter med en video som bruker Adobe Acrobat Pro DC til å vise mer detalj om den logiske strukturen i en tagget PDF-fil. Først starter vi med en skisse som viser de generelle prinsippene: en PDF-side med innholdsstrømmen merket opp med markerte innholdssekvenser (MCS). ![Grafikk som viser konseptet markerte innholdssekvenser i PDF-dokumentsider](/files/20fcff77d7e88e7f8a70f7388b8c91899d4aff15) Disse MCS-ene kombineres deretter til *struktur-elementer* som danner grunnlaget for større innholdstyper som selv kobles videre sammen for å lagre PDF-ens logiske struktur i et objekt kalt `StructTreeRoot`. ![Grafikk som viser den logiske strukturen til en tagget PDF-fil](/files/4c5787e6761f6557358805f46637b27593894ed6) #### Video som viser den logiske strukturen til en tagget PDF Følgende video (8 minutter) bruker Adobe Acrobat Pro DC til å ta deg med på en «guidet tur» for å utforske detaljer i den logiske strukturen til en tagget PDF-fil laget ved hjelp av LaTeX. Den taggede PDF-filen som brukes i videoen heter `tagpdf.pdf`, som er et utmerket eksempel som inneholder dokumentasjon for den eksperimentelle LaTeX-pakken [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Målet med `tagpdf` pakken er å tilby «verktøy for å eksperimentere med tagging og tilgjengelighet ved bruk av pdfLaTeX og LuaTeX». {% embed url="" %} ### En merknad om tagging og fleksibilitet HTML-spesifikasjonen gir et stort antall forhåndsdefinerte tagger for bruk i oppbygging av nettsider, men den tillater også fleksibilitet i hvordan du kombinerer dem for å lage det valgte HTML-dokumentet. På samme måte gir Adobes spesifikasjon for tagget PDF et sett med forhåndsdefinerte tagnavn, men pålegger svært få begrensninger på hvordan du kombinerer disse taggene for å representere komplekse innholdselementer i en PDF – med hensikt er det stor grad av fleksibilitet. I tillegg, med enhver spesifikasjon så stor og kompleks som PDF, er det uunngåelig at noen uklarheter eller spørsmål om klarhet sniker seg inn i den skrevne spesifikasjonen. Programvareutviklere som får i oppgave å implementere en så kompleks spesifikasjon, kan måtte ta «skjønnsavgjørelser» når de tolker den, fordi de står overfor å omsette skriftlige beskrivelser til fungerende kode. Den iboende fleksibiliteten i tagget PDF, sammen med tolkning av spesifikasjoner (eller tilgjengelighetsstandarder), påvirker naturlig utviklere av dokumentredigeringsapplikasjoner: hvilke kombinasjoner av tagger bør brukes for å representere brukeropprettet innhold når det skrives ut til en tagget PDF-fil? Hvis du tar med den grenseløse evnen brukere har til å konstruere alle slags innhold ved å bruke funksjonene i programvaren for dokumentproduksjon, kan du se at automatisk produksjon av tilgjengelige, taggede PDF-er er noe av en utfordring! Kanskje som en refleksjon av de uunngåelige kompleksitetene ved å produsere taggede PDF-er som fullt ut samsvarer med tilgjengelighetsstandarder, er nettet fullt av «slik gjør du det»-forklaringer, «tips» og råd om «beste praksis» for å lage taggede PDF-er via programvare som Adobe InDesign eller Microsoft Word. I tillegg har PDF Association utarbeidet et nyttig dokument kalt [Tagged PDF Best Practice Guide](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) skrevet for å hjelpe utviklere som står overfor utfordringene ved å implementere tagget PDF og PDF/UA. ## Har du en PDF, men er den tilgjengelig? For å avgjøre om en gitt PDF-fil er i samsvar med nødvendige tilgjengelighetsstandarder som PDF/A eller PDF/UA (se nedenfor) må den *valideres* ved hjelp av en avtalt valideringsprosess eller programvareverktøy. Validering skjer imidlertid vanligvis etter at dokumentet er ferdig, men den prosessen utføres kanskje ikke av dokumentets forfatter, men av tilgjengelighetsspesialister i organisasjonen eller organet som krevde samsvar. Hvis PDF-en ikke består valideringen, kan det hende den må få manuell ekspertbehandling i Adobe Acrobat Pro DC for å rette taggingen (hvis mulig). Alternativt kan den til og med måtte sendes tilbake til forfatteren for å endre det opprinnelige dokumentet, muligens ved å unngå bruk av funksjonene i redigeringsprogrammet som forårsaket problemene – noe som kan være ekstremt vanskelig å få til fordi det kan ligge utenfor forfatterens kontroll. ### Leserekkefølge og innholdsrekkefølge Som nevnt stiller produksjon av virkelig tilgjengelige PDF-er ekstra tekniske krav til redigeringsprogramvaren og potensielt også til dokumentforfattere, ved å håndheve «forfatterdisiplin» i hvordan de bruker/anvender funksjonene i redigeringsprogramvaren. Selv om tagget PDF er mekanismen som *gjør det mulig* å produsere fullt tilgjengelige PDF-er, betyr ikke bare det at en PDF er tagget *inneholder* automatisk at den er fullt tilgjengelig, som vi skal se i et eksempel nedenfor. For å produsere fullt tilgjengelige PDF-er bør alle innholdselementer i PDF-en være tagget for å skape en logisk struktur som sikrer at innhold kan nås og leses i riktig sekvens – kalt *leserekkefølge*leserekkefølgen *leserekkefølge* av: 1. tekst 2. table 3. grafikk Når det skrives til en PDF, kan programvare som genererer en innholdsstrøm for den siden starte med operatorer for å tegne tabellen, deretter skrive ut operatorer for å produsere grafikken, etterfulgt av operatorer for teksten, som i innholdsstrømmen ville gi en *innholdsrekkefølge* av: 1. table 2. grafikk 3. tekst Selvfølgelig vil alt plasseres på riktig sted når siden vises. For en fullt seende leser er rekkefølgen disse elementene er lagret i inne i sidens innholdsstrøm, irrelevant: de opplever en fullt gjengitt side med alt på riktig plass. Men hvis hjelpesoftware måtte stole på rekkefølgen til elementene i en innholdsstrøm (innholdsrekkefølgen), ville den møte problemer dersom innholdsrekkefølgen var annerledes enn den naturlige leserekkefølgen; for eksempel vil verktøy for høytlesing lese materialet i feil sekvens. Heldigvis kan hjelpesoftware bruke den taggede PDF-ens logiske rekkefølge (struktur), som må være organisert for å gjenspeile sekvensen innholdet skal leses i. Det er av disse grunnene at data som representerer dokumentets logiske struktur lagres separat fra det faktiske innholdet som vises på de synlige sidene, for å gjøre det mulig > «... at ordningen og nesting av logiske innholdselementer er fullstendig uavhengig av rekkefølgen og plasseringen av grafikkobjekter på dokumentets sider.» (side 856 i [The PDF Reference, sjette utgave, november 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) I praksis er det langt mer utfordrende enn det kan se ut til å garantere en logisk rekkefølge som bevarer leserekkefølgen, så la oss bruke et enkelt, om enn konstruert, eksempel som gir en pekepinn på problemene som er involvert. #### Feil leserekkefølge: Et eksempel med Microsoft Word En forfatter av et dokument kan bruke funksjonene i den valgte redigeringsprogramvaren for å oppnå en bestemt visuell effekt – for eksempel ved å bruke tabeller for å lage et bestemt tekstoppsett. Følgende skjermbilde viser for eksempel Microsoft Word-dokumentet som ble brukt i tidligere eksempler. Det inneholder en tabell som har blitt brukt til å lage et sett med nummererte avsnitt side om side. Men når det kommer til tagging av dette innholdet, hvordan bør det behandles: tagget som en tabell eller en nummerert liste? Begge disse innholdstypene krever en kompleks taggingsstruktur for å representere dem korrekt. I det følgende bildet, legg merke til rekkefølgen de nummererte avsnittene er ment å leses i: kolonne for kolonne, ikke rad for rad. ![Bilde av en tabell laget i Microsoft Word](/files/296855fa1e781e638bb5f4d21ec6902af9e4a87f) Hvis vi ber Word om å lagre dette dokumentet som en PDF ved hjelp av den innebygde eksportfunksjonen—ikke Acrobat PDFMaker-pluginen—kan vi be den om å opprette en tagget PDF: ![Alternativer-dialogboksen i Microsoft Words eksportprosess](/files/7bb5ab27d3bd974f6f12e9f47017f17987c44172) Så, hvordan tagger Word dette oppsettet? I den følgende svært korte videoen (14 sekunder) bruker vi Adobe Acrobat Pro DC til å undersøke taggestrukturen som produseres av Microsoft Word. {% embed url="" %} For dette dokumentet har Word opprettet et tagget PDF-dokument som bruker en `Tabell` tagg som inneholder to undertagger: `THead` for tabellens overskriftsradgruppe og og `TBody` for å representere gruppen av rader for tabellens brødtekst. `THead` og `TBody` begge inneholder `TR` tagger for å representere enkeltstående rader med innhold. De `TR` taggene inneholder ytterligere tagger for å representere det nummererte listeelementet som finnes i hver celle. Det følgende skjermbildet viser den dypt nestede taggestrukturen og den tilsvarende komplekse logiske strukturen som trengs for å representere selv dette ekstremt grunnleggende dokumentet! ![Bilde som viser dypt nestet taggestruktur og logisk struktur i en enkel tabell opprettet i Microsoft Word](/files/6930a3eb3e61154fe0b713065a65221be63c0ceb) Sammenlignet med PDF-er generert av TeX og LaTeX er dette Word-eksempelet et ekstremt enkelt dokument, men det krever likevel en kompleks logisk struktur for å representere det. Tenk deg nivået av taggekompleksitet som kreves for å representere LaTeX-genererte PDF-er som inneholder kompleks matematikk og tabeller! #### Tagget, ja, men leserekkefølgen er feil Selv om Word faktisk produserer en [tagget PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) viser det en av de grunnleggende utfordringene som enhver applikasjon som prøver å produsere fullt tilgjengelige PDF-er står overfor: å gjengi den tiltenkte leserekkefølgen til innholdet korrekt. Under opprettelsen av den taggede PDF-en bestemte Words interne prosesser seg for å skrive den tilsvarende innholdsstrømmen ved å sende ut tabellen rad for rad, ikke kolonne for kolonne. For en fullt seende leser som ser PDF-en, gjør disse lavnivådetaljene ingen forskjell: tabellen vises riktig. Men for synshemmede personer produserer Words logiske dokumentstruktur feil resultat fordi den ønskede leserekkefølgen (kolonne for kolonne) ikke bevares: innholdet leses høyt opp i feil rekkefølge. Følgende lydopptak ble produsert ved hjelp av Adobe Reader DCs funksjon «Read Out Loud». Som det tydelig fremgår, leses teksten opp i feil rekkefølge: rad for rad, ikke kolonne for kolonne: ![En tabell opprettet i Microsoft Word](/files/d63aaabb6fe71f992c5a4a183af6d6a1d26200b2) Som nevnt ovenfor er dette eksemplet noe konstruert, men det viser hvor lett det er å bruke kombinasjoner av programvarefunksjoner som utløser tilgjengelighetsproblemer—men hvordan kan dokumentforfatteren forventes å vite dette på forhånd? Det er sannsynlig at dette problemet bare ville bli oppdaget hvis den resulterende PDF-en gjennomgikk praktiske tester av tilgjengelig bruk—f.eks. ved bruk av hjelpeteknologi. Slike dokumenter kunne potensielt bestå PDF/A-samsvars-/valideringstester, men mislykkes i «virkelig» bruk. Å sikre riktig leserekkefølge i en PDF-fil som denne ville kreve dyktig manuell inngripen ved bruk av avanserte PDF-redigeringsverktøy som Adobe Acrobat Pro DC: en tidkrevende og kostbar prosess. Alternativt kunne dokumentets forfatter avstå fra å bruke nettopp denne formen for innholdsuttrykk eller oppsett—men bare hvis de visste at den var problematisk! ### Bruk av mellomromstegn for å skille ord Når du skriver inn tekst i tekstbehandlingsprogrammer eller tekstredigerere, bruker du mellomromstegnet til å markere slutten på ett ord og starten på det neste. Hvis du senere oppretter en PDF fra et slikt dokument, vil mellomromstegnene du skrev inn selvfølgelig bli skrevet ut og utgjøre en del av teksten som er lagret i PDF-en. TeX-motorer bruker imidlertid ikke mellomromstegn til å skille ord i satt tekst; i stedet omgjør de mellomromstegn til en form for fleksibel avstand kalt glue (se denne [Overleaf-artikkelen](/latex/no/dybdeartikler/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) for mer informasjon om TeX-bokser og glue). I innholdsstrømmen til PDF-sider opprettet av TeX-motorer oppnås separasjonen av enkeltord ved å flytte til en annen posisjon på siden og starte teksten for det neste ordet—i stedet for å skrive ut et mellomromstegn for å oppnå den avstanden. Videre varierer mengden mellomrom mellom ord i avsnitt satt med TeX-motorer fra linje til linje på grunn av TeX' linjebrytingsalgoritme. Denne variasjonen gjenspeiles i de posisjonsdataene som skrives ut til innholdsstrømmen i PDF-sidene. Dette aspektet ved TeXs satsing har konsekvenser for kopiering/innliming av tekst fra PDF-ene og for hjelpeteknologi som prøver å lese opp den satte teksten i PDF-er produsert av TeX-motorer. Hjelpeteknologi må tolke innholdsstrømmen på en PDF-side for å trekke ut teksten den trenger å behandle. Tydeligvis trenger slik programvare en mekanisme for å oppdage starten og slutten på ord—den mest åpenbare løsningen er å bruke et mellomromstegn. Med dette i tankene krever tilgjengelighetsstandarder at enkeltord avsluttes tydelig (f.eks. med mellomromstegn), noe som er problematisk for TeX-motorer på grunn av bruken av interword glue. #### Men alt er ikke tapt! I 2014 introduserte pdfTeX to nye primitiver for å forbedre støtte for tilgjengelighet ved å muliggjøre bruk av mellomromstegn mellom ord i PDF-ene den skriver ut: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Disse kommandoene bruker en «dummy font» som bare inneholder et mellomromsglyf. Detaljer og et eksempel finnes på side 29 i [pdfTeX User Manual](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Bruk av LuaTeX: Et eksempel i Overleaf-galleriet LuaTeX støtter ikke disse pdfTeX-primitivene, men det kan programmeres til å oppnå resultater som ligner svært på pdfTeX ved hjelp av LuaTeXs såkalte callback-mekanisme. Et Overleaf-prosjekt for å konvertere glue til mellomromstegn er tilgjengelig i Overleaf-galleriet under tittelen [Bruk av LuaTeX til å konvertere interword glue til mellomrom og kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Hvis du setter LaTeX-koden din med LuaTeX (dvs. LuaLaTeX-kompileringsalternativet på Overleaf), kan du ved å bruke Lua-kode etterbehandle et satt avsnitt for å finne eventuell interword glue og erstatte den med et mellomromstegn pluss en passende kern. Avstanden som gis av bredden på mellomromstegnet kan legges til (eller reduseres) ved å beregne en passende kern-verdi for å bevare mengden avstand som interword glue ga, noe som resulterer i ingen visuell forskjell i det satte resultatet. For å forstå forskjellen dette gjør for brukere av tilgjengelighetsprogramvare, lytt til dette lydopptaket tatt opp fra Adobe Reader DCs *Read Out Loud* funksjon. Det tar opp at de to linjene med tekst i det prosjektet leses høyt opp, før og etter konvertering av glue til mellomrom. Legg merke til hvordan den andre opplesningen av linjen, som bruker mellomrom, leses opp raskt og flytende sammenlignet med linjen som bruker interword glue. Overleaf-prosjektet er en ren TeX-fil kompilert med LuaTeX og levert kun for eksperimentell bruk; det er ikke ment som en fullverdig løsning av produksjonskvalitet. Primært er det utformet for å bidra til å forstå tekniske problemer knyttet til tilgjengelige PDF-er. Lua-koden som brukes i det prosjektet er basert på arbeid som finnes i en langt tidligere Overleaf-artikkel [Bokser og lim: En kort, men visuell, introduksjon med LuaTeX](/latex/no/dybdeartikler/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Merk: For enkelhets skyld bruker prosjektet sin egen svært minimale OpenType-fontlaster avledet fra denne koden: . ### Andre tilgjengelighetsproblemer og tagget PDF Selv om tagging gjør det mulig å identifisere innholdselementer som finnes i en PDF, krever noen typer innhold, som grafikk eller kompleks matematikk, ytterligere data eller informasjon hvis de skal gjøres tilgjengelige via programvare utviklet for å støtte synshemmede. For å tilby og støtte tilgjengelighet for et bredt spekter av innholdstyper, gir PDF-spesifikasjonen muligheten til å knytte «Alternative beskrivelser» eller «ActualText» til innholdselementer, slik at det gis passende tekstlige beskrivelser eller andre maskinlesbare representasjoner. For eksempel er MathML utpekt til dette formålet i PDF 2.0-spesifikasjonen. #### Er det «virkelig innhold» eller bare en artefakt? For personer med nedsatt syn har prosessen med å dele opp og vise innhold i rektangulære sideruter uønskede bivirkninger, som orddeling. Videre er aspekter ved sidedesign eller oppsett som brukes for å forbedre den visuelle presentasjonen, stort sett meningsløse for dem som ikke kan se det. Av disse grunnene må tagging av PDF-innhold erkjenne at noe innhold i en PDF bør behandles som en *artefakt* av visuell presentasjon eller paginering. For eksempel må sidetall, sidehoder og bunntekster, skyggebakgrunner eller andre designelementer identifiseres slik at tilgjengelighetsprogramvare som behandler innholdet vet å ignorere dem. ## Oversikt over PDF/A-standardene Forespørsler om å produsere tilgjengelige PDF-er viser vanligvis til en ISO-standard kalt [ISO 19005](https://www.iso.org/standard/38920.html), oftere omtalt som PDF/A. Men fordi PDF/A er en *familie* av standarder, vil en enkel forespørsel om «PDF/A-samsvar» kanskje ikke fullt ut spesifisere de faktiske kravene. For å se hvorfor, la oss begynne med en kort oversikt over PDF/A fra [PDF Associations nettside](https://www.pdfa.org/resource/iso-19005-pdfa/) (åpnet 21. mai 2020) som beskriver ISO 19005 (PDF/A) som følger: > «Hovedformålet med ISO 19005 er å definere et filformat basert på PDF, kjent som PDF/A, som gir en mekanisme for å representere elektroniske dokumenter på en måte som bevarer deres statiske visuelle utseende over tid, uavhengig av verktøyene og systemene som brukes til å opprette, lagre eller gjengi filene. > > Et sekundært formål med ISO 19005 er å definere et rammeverk for å representere den logiske strukturen og annen semantisk informasjon i elektroniske dokumenter innenfor filer som er i samsvar. > > Et annet formål med ISO 19005 er å gi et rammeverk for å registrere konteksten og historikken til elektroniske dokumenter i metadata i samsvarende filer.» Tydeligvis har PDF/A flere kjerneformål. ### Evolusjon og vekst av PDF Den [PDF 1.0-spesifikasjonen](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) ble publisert i 1993 og besto av bare 230 sider. Imidlertid var spesifikasjonen for 13 år senere [Adobes PDF-versjon 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) godt over 1000 sider! Over tid har størrelsen og kompleksiteten til PDF-spesifikasjonen vokst ved å utvide det støttede funksjonssettet: det omfatter nye teknologier og kravene fra stadig mer sofistikerte PDF-baserte arbeidsflyter og brukstilfeller i ulike markeder og miljøer. Det er imidlertid sannsynlig at ingen bruker, eller gruppe brukere, noen gang utnytter alle mulighetene: PDF må «dekke alle behov» for å sikre at det kan betjene behovene til det bredest mulige markedet. For eksempel er mange PDF-funksjoner som er utformet for å støtte høykvalitetstrykking, ikke nødvendige for typisk daglig kontorbruk som format for lagring eller deling av dokumentasjon. ### PDF/A: «tilbake til det grunnleggende» for PDF Hovedmålet med PDF/A er å sikre at samsvarende PDF-er er egnet for langtidsarkivering eller inneholder innhold som er tilgjengelig for personer som bruker ulike hjelpeteknologier for å «konsumere» disse PDF-ene. For å oppnå disse målene begrenser PDF/A settet av PDF-funksjoner som er tillatt i samsvarende PDF-filer, og forbyr bruk av funksjoner som kan kompromittere arkiverbarhet eller tilgjengelighet. Du kan tenke på PDF/A som et sett standarder som spesifiserer hvordan samsvarende PDF-filer bruker en *utvalg* del av den fulle PDF-spesifikasjonen for å produsere filer som er egnet for langtidsarkivering eller for å sikre at innholdet deres er tilgjengelig. PDF/As begrensninger gjør det mulig å bruke PDF-er som «arkivert digitalt papir» som er uavhengig av PDF-leseteknologien og datamiljøet som brukes til å få tilgang til innholdet. Samsvarende PDF-er skal ikke inneholde noe hvis oppførsel er «implementeringsavhengig»—dvs. avhenger av den spesifikke programvaren eller operativsystemene som brukes til å vise eller behandle dem. PDF-er må også være *komplette*: viktige dokumentressurser må være innebygd i filen—for eksempel fonter eller fargeprofiler. ### PDF/A-versjoner og samsvarsnivåer Det finnes forskjellige *versjoner* av PDF/A-standarden, hver som gjenspeiler en bestemt versjon av den formelle PDF-spesifikasjonen (PDF 1.4, 1.7 og 2.0). I tillegg finnes det ulike *samsvarsnivåer* som spesifiserer hvilket aspekt/hvilke aspekter av PDF/A-standarden en PDF-fil er i samsvar med. Følgelig, når du hevder eller krever «PDF/A-samsvar», bør du tenke på PDF-filer som er i samsvar med **PDF/A-** For eksempel * PDF/A-1a: betyr PDF/A-versjon 1, samsvarsnivå a * PDF/A-2b: betyr PDF/A-versjon 2, samsvarsnivå b Vi utforsker disse litt mer detaljert. #### PDF/A-versjoner PDF/A-standarden er underlagt ISO, og publiseres som en standard kalt ISO 19005. Som nevnt har PDF-spesifikasjonen utviklet seg over tid, og det gjorde igjen oppdateringer av ISO 19005 nødvendige, noe som resulterte i tabellen nedenfor: | | | | | ----------------- | ---------------- | ------------------------- | | **PDF/A-versjon** | **ISO-standard** | **Basert på PDF-versjon** | | 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) | På tidspunktet for skrivingen (april/mai 2020) er en oppdatert PDF/A-4 (ISO 19005-4) [under utarbeidelse](https://www.iso.org/standard/71832.html). #### PDF/A-samsvarsnivåer I tillegg til tre PDF/A-versjoner (PDF/A-1, PDF/A-2 og PDF/A-3) finnes det tre *samsvarsnivåer*: * Nivå A (tilgjengelig) for tilgjengelighet (inkluderer arkiveringskravene til nivå B) * Nivå B (grunnleggende) for arkivering * Nivå U (Unicode) (= arkivering pluss bruk av Unicode for tekst) Her er en kort beskrivelse av disse samsvarsnivåene: * **Nivå B (grunnleggende)** er minstekravet for samsvar under PDF/A. Det definerer krav for å sikre at samsvarende PDF-dokumenter er egnet for langtidsarkivering—at de alltid kan vises eller skrives ut pålitelig uavhengig av spesifikk programvare, verktøy eller operativsystemer. * **Nivå A (tilgjengelighet)** inkluderer kravene til nivå B-samsvar, men krever i tillegg bruk av tagget PDF for å gi informasjon om logisk struktur og leserekkefølge, sammen med bruk av Unicode for å muliggjøre tilgang til dokumentets tekst. * **Nivå U (Unicode)** samsvar ble lagt til i PDF/A-2 og bygger på nivå B ved i tillegg å kreve bruk av Unicode for dokumenttekst, men går ikke så langt som nivå A ved å kreve strukturell informasjon. PDF/A-versjoner og samsvarsnivåer kan oppsummeres i en tabell: | | | | | | ---------------------- | --------------------------------------- | -------- | -------- | | **Samsvarsnivå** | **PDF/A-** | | | | Nivå A (tilgjengelig) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Nivå B (grunnleggende) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Nivå U (Unicode) | Ikke relevant (fantes ikke for PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA («Universell tilgjengelighet») Selv om samsvar på nivå A i PDF/A-standarden et stykke på vei definerer kravene til tilgjengelige PDF-er, går en annen ISO-standard kalt [ISO 14289](https://www.iso.org/standard/64599.html), omtalt som PDF/UA, lenger. PDF/UA styrker tilgjengelighetskravene og klargjør veiledningen i PDF/A-standardene og har blitt den foretrukne standarden for tilgjengelige PDF-er. #### Matterhorn-protokollen Lesere med stor interesse for å lære mer om PDF/UA-samsvar kan være interessert i [Matterhorn-protokollen](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) som er «en liste over alle mulige måter å mislykkes med PDF/UA-samsvar på». ### Valideringsprogramvare For å sjekke om en PDF-fil er i samsvar med en bestemt standard, må den være *valideres* ved hjelp av samsvarsprogramvare som skanner gjennom PDF-en for å kontrollere om innholdet og strukturen er i samsvar med kravene i den standarden—som PDF/UA eller PDF/A-*x*a (der *x* = 1, 2 eller 3). Merk at validering av PDF-er—å behandle dem med et foretrukket valideringsverktøy—kan gi diagnostiske meldinger eller advarsler som kan være ganske kryptiske for den uerfarne brukeren—kanskje på grunn av noen lavnivå PDF-data (eller struktur) som ikke oppfyller den relevante standarden. For mange forfattere kan det være ganske utfordrende å tolke disse advarslene og omsette dem til en konkret løsning for dokumentet/dokumentene deres. #### Gratis valideringsprogramvare * [veraPDF](https://verapdf.org/) som ifølge nettsiden deres (åpnet 28. mai 2020) er en «spesialutviklet validerer for filformat med åpen kildekode som dekker alle PDF/A-deler og samsvarsnivåer». * (kun Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) som er et «...gratis verktøy for kontroll av PDF-tilgjengelighet som har vært prøvd og testet siden 2010». #### Kommersiell valideringsprogramvare * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) tilbyr en pakke med PDF-valideringstester sammen med verktøy for å redigere og rette opp tagger i PDF-filer som ikke er i samsvar. ### PDF Association: en flott informasjonskilde Den [PDF Association](https://www.pdfa.org/) produserer mange *utmerkede* ressurser om PDF/A, PDF/UA og mange andre PDF-relaterte emner—inkludert videoer på deres [YouTube-kanal](https://www.youtube.com/user/ThePDFAssociation/playlists) sammen med artikler og gratis tekniske publikasjoner tilgjengelig på nettsiden deres. En slik publikasjon er [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) som gir en uvurderlig introduksjon til PDF/UA-standarden og dens krav. ## Tilgjengelige PDF-er fra TeX-motorer og LaTeX Forhåpentligvis har de foregående diskusjonene vist at produksjon av fullt tilgjengelige og korrekt taggede PDF-filer er en krevende teknisk utfordring. Videre viste selv det enkle Microsoft Word-eksemplet at forfattere svært lett kan bruke kombinasjoner av programvarefunksjoner som resulterer i taggede PDF-dokumenter som ikke oppfyller tilgjengelighetskriterier. Som et forfatterverktøy gir LaTeX forfattere nesten ubegrenset fleksibilitet når det gjelder rekkevidden og kompleksiteten til dokumenter du kan lage—noe som kanskje er nettopp grunnen til å velge det i utgangspunktet. LaTeX støtter også utvidbarhet via tusenvis av tilleggspakker som forfattere kan bruke som en del av dokumentene sine. Oppå alt dette har forfattere friheten til å skrive nye TeX- eller LaTeX-makroer, eller definere eksisterende på nytt, for å oppnå bestemte effekter. Men kanskje har denne friheten og fleksibiliteten en pris, fordi innholdet som produseres av de utallige samspillene mellom alle disse LaTeX-pakkene og makroene «på en eller annen måte» må orkestreres hvis LaTeX automatisk skal generere korrekt tagget og tilgjengelig PDF-utdata. I praksis innebærer utvidbarheten, kraften, allsidigheten og forfatterfriheten som LaTeX gir, tekniske utfordringer for sømløs og transparent («automatisk») produksjon av fullt tilgjengelige taggede PDF-dokumenter som er i samsvar med standardene PDF/UA eller PDF/A-{1|2|3}a. Det bredere TeX- og LaTeX-miljøet arbeider hardt for å møte disse utfordringene, og TeX User Group (TUG) koordinerer forsknings- og utviklingsinnsats gjennom arbeidsgruppen for PDF-tilgjengelighet og PDF-standarder [arbeidsgruppe](https://www.tug.org/twg/accessibility/). Det finnes en [diskusjonsliste](https://tug.org/mailman/listinfo/accessibility) som gir interesserte parter en måte å diskutere produksjon av taggede PDF-filer ved hjelp av TeX og LaTeX. I disse diskusjonene er det verdt å huske at LaTeX faktisk ikke er et kjørbart satsprogram, men en stor samling sofistikerte makroer (kommandoer) skrevet i et lavere nivå-språk kalt TeX. Mellom ditt nøye utformede LaTeX-dokument og den endelige satte PDF-en ligger et stykke programvare kalt en TeX-motor, hvis jobb er å «utføre» samlingen av LaTeX-kommandoer (dvs. makroer) som brukes til å skrive og konstruere dokumentet ditt—og omdanne dem til den satte representasjonen av dokumentet ditt lagret som en PDF-fil. De som er nye i TeX/LaTeX-økosystemet blir ofte, og forståelig nok, forvirret av mengden kryptisk klingende navn som brukes for verktøyene de møter: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX og LuaLaTeX. Hvis du føler det samme, finnes det hjelp i Overleaf-artikkelen [Hva er i et navn: En guide til de mange variantene av TeX](/latex/no/dybdeartikler/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) som forklarer opprinnelsen til og betydningen av alle disse termene. TeX-motorer som pdfTeX, XeTeX eller LuaTeX er en klasse programvare kalt *dokumentkompilatorer*: de tar LaTeX-koden din og kompilerer den til dens satte form ved å «konvertere» LaTeX-makroer (kommandoer) tilbake til deres instruksjoner i TeX-språket på lavere nivå, som «utføres» for å produsere det satte resultatet. TeX-baserte satsingssystemer er i stand til å produsere usedvanlig komplekst innhold—inkludert avansert matematikk, musikkskriving, kjemiske strukturer, grafikk og sofistikert flerspråklig satt tekst. For å sikre at disse komplekse dokumentene er i samsvar med tilgjengelighetsstandarder og regelverk, må TeX-motorer, sammen med LaTeX-makrosamlingen og LaTeX-pakkene, generere passende taggede PDF-filer ved å bygge inn en stor mengde tilleggsdata i PDF-filene de genererer. Selv om TeX-motorer kan generere ekstremt komplekse PDF-filer, har deres interne prosesser, algoritmer og funksjoner ikke *innebygd* funksjoner *spesifikt utformet* for å støtte produksjonen av taggede og tilgjengelige PDF-er. I stedet må støtte for tagging og tilgjengelighet oppnås gjennom kompleks makroprogrammering som «injiserer» tilleggsdata i PDF-ene generert av TeX-motorer—og oppretter de markerte innholdssekvensene, struktur-elementene og datastrukturene for logisk struktur som lagres i `StructTreeRoot`. Og her blir denne «orkestreringen» tydelig: kode i LaTeXs kjerne (kernel), sammen med kode i tusenvis av pakker og utallige forfatteropprettede makroer, måtte samarbeide svært nøye for å sikre at kjøring av makroer gir korrekt tagging av innholdet i de resulterende dokumentene. Denne «orkestreringen» måtte være pålitelig—uansett hvordan forfattere velger å kombinere og bruke funksjonene, kommandoene og funksjonaliteten i LaTeX, pakkesystemet og kraften i TeX-makroer. ### Forfatternes behov For de fleste er LaTeX bare et verktøy som lar deg lage vakkert satte dokumenter med frihet til å velge pakker som hjelper deg å oppnå det. Det store flertallet av LaTeX-forfattere ønsker ganske enkelt at dokumentene deres skal «fungere»: satses uten feil slik at de kan levere inn avhandlingen, artikkelen, rapporten eller fullføre den lenge ventede boken. Ikke urimelig forventer brukere av LaTeX at den valgte samlingen av LaTeX-pakker skal sameksistere fredelig, sømløst og transparent samhandle for å tilby de kommandoene og funksjonene som er nødvendige for å produsere dokumentene deres. De samme ønskene vil trolig også finnes når man står overfor kravet om å produsere tagget PDF fra LaTeX: det skal «bare fungere», transparent og med minimal inngripen fra forfatteren. Dessverre er vi et godt stykke unna opplevelsen av «Se der! tagging skjer bare, uansett hva slags rare ting jeg gjør». Å kombinere de tekniske kravene til tilgjengelighet pluss tagget PDF med LaTeX og forfatterfrihet er i seg selv komplekst, og kanskje er det uunngåelig at en form for «forfatterdisiplin» kan være nødvendig hvis de tekniske utfordringene skal bli praktisk gjennomførbare og løselige. Et eget, men beslektet, problem er at feil tagging kanskje ikke har noen visuell innvirkning på den endelige PDF-en: visuelt kan den se perfekt ut, og den vil sannsynligvis også kunne skrives ut uten problemer, men uten at forfatteren vet det, kan taggingen være «ødelagt», og først oppdages gjennom senere feil i PDF/A-samsvars-/valideringskontroller og/eller videre praktisk testing via tilgjengelighetsprogramvare som skjermlesere. ### PDF-filer produsert på Overleaf Overleaf gir brukerfellesskapet sitt en nettleserbasert LaTeX-editor sammen med prosjekt- og dokumentadministrasjonsverktøy som legger til rette for samarbeidende forfatting—alt bygget oppå en standard TeX Live-installasjon. I praksis lar Overleaf brukere «kjøre LaTeX på avstand» via en nettleser, og gir et beskyttende lag mot kompleksiteten ved å administrere og vedlikeholde et fullstendig TeX Live-system. En konsekvens av at Overleaf bruker en standard TeX/LaTeX-installasjon er at PDF-er produsert fra LaTeX-kode skrevet i Overleafs editor, opprettes ved hjelp av nøyaktig de samme teknologiene som finnes i enhver annen TeX Live-installasjon av samme versjon—inkludert oppsett som brukerne har installert på sine lokale enheter. Den eneste forskjellen er at TeX-motorene som kompilerer og behandler Overleafs LaTeX-kode, kjører på eksterne servere, ikke på lokale maskiner. Overleaf lineæriserer PDF-en som genereres av TeX for effektiv nedlasting/visning i en nettleser, men den prosessen er ikke relatert til tilgjengeligheten til selve PDF-innholdet. Produksjon av tilgjengelige PDF-er via Overleaf er avhengig av funksjonene og egenskapene som er innebygd i standard TeX-motorer, sammen med tilgjengeligheten av egnede LaTeX-makropakker som brukerne kan bruke som del av dokumentet sitt. LaTeX-dokumenter opprettet ved hjelp av Overleaf må forbli kompatible med andre TeX- og LaTeX-installasjoner, fordi brukere ofte må eksportere LaTeX-prosjektet sitt fra Overleaf for innsending til et bredt spekter av forlag- og journalsystemer. Å introdusere Overleaf-spesifikke funksjoner i LaTeX-dokumentene deres, eller i de underliggende TeX-motorene, ville alvorlig hindre brukernes frihet til å bruke arbeidet sitt andre steder. Overleaf anerkjenner og støtter behovet for fullt tilgjengelige PDF-er generert fra TeX/LaTeX-forfattersystemer: vi bruker tid på å forske på tilgjengelighetsproblemer, utforske de nyeste utviklingene i TeX-motorer og eksperimentelle LaTeX-pakker som støtter tagget PDF. Til syvende og sist, på tidspunktet for skrivingen, finnes det ingen «ferdig løsning» som LaTeX-forfattere kan bruke (via `\usepackage`) for sømløst og transparent å generere fullt tilgjengelige og PDF/UA-kompatible PDF-er fra generiske LaTeX-dokumenter. Når disse løsningene blir tilgjengelige gjennom TeX Live-oppdateringer, vil de selvfølgelig bli tilgjengelige for Overleaf-brukerfellesskapet. ### Noen LaTeX-pakker for å utforske tagging og tilgjengelighet For mange er [tex.stackexchange](https://tex.stackexchange.com/) det første stedet man går for hjelp med TeX, LaTeX eller ConTeXt. Det er en fantastisk ressurs og har mange spørsmål om temaet [tilgjengelighet](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) og produksjon av tilgjengelige PDF-er via LaTeX. Hvis du leser og blar gjennom disse spørsmålene, og den påfølgende strømmen av svar og kommentarer, er det bare én konklusjon som er uunngåelig: for øyeblikket finnes det ingen fullverdig løsning på produksjonsnivå for automatisk å lage fullt tilgjengelige, standardskompatible, taggede PDF-er fra alle typer LaTeX-dokumenter. Det finnes imidlertid noen pakker som støtter tagging—selv om det kanskje er innenfor et begrenset spekter av brukstilfeller og dokumenttyper. Følgende liste er gitt for lesere som ønsker å utforske LaTeX-basert PDF-tagging: * [`tagpdf` pakken](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): en svært kapabel pakke utviklet for eksperimentering med PDF-tagging. Støtter pdfTeX og LuaTeX og gir ekstremt nyttig og interessant dokumentasjon som inneholder noen utmerkede notater om de tekniske utfordringene ved å lage taggede PDF-er via TeX-motorer; den anbefales sterkt for alle som er interessert i å forstå problemene bedre. Fremtidig retning vil sannsynligvis være LuaTeX. * [`axessibility` pakken](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov og Universitetet i Torino): gir tilgang til formler i PDF-filer via hjelpeteknologier. * [`tilgjengelighet` pakken](https://ctan.org/pkg/accessibility) (Andy Clifton): oppretter taggede og strukturerte PDF-filer. CTAN-notatene sier at denne pakken er «rettet mot brukere av dokumentklassene i KOMA-Script». * [`accsupp` pakken](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): eksperimentell pakke for å gi bedre støtte for tilgjengelighet i PDF-filer. En ytterligere verdt å merke seg referanse er en artikkel fra 2018 [Implementering av PDF-standarder for matematisk publisering](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) av Dr. Ross Moore fra Institutt for matematikk ved Macquarie University. I den artikkelen inkluderer Dr. Moore en kort oversikt over utfordringene ved tagging av PDF-er i LaTeX: > «Den viktigste kilden til vanskeligheter ligger i måten ulike miljøer kan samhandle med hverandre på. Det finnes mange situasjoner i LaTeX der ett miljø eller én struktur egentlig ikke er fullført før det neste har begynt. Så det er ikke bare et spørsmål om å legge start- og slutt-tagger rundt hver enkelt del av levert innhold. I stedet må man forstå nyansene i hvordan ulike miljøer og andre strukturer faktisk starter og slutter, innenfor konteksten som er etablert av omkringliggende materiale.» Dr. Moore er også den nåværende vedlikeholderen av [`pdfx`](https://ctan.org/pkg/pdfx) pakken og en ekspert og pioner innen tagget PDF ved bruk av TeX/LaTeX. Arbeidet hans er absolutt verdt å søke etter—inkludert denne videoen på YouTube som gir interessante innblikk: {% embed url="" %} #### Merk om pakken pdfx Den [`pdfx`](https://ctan.org/pkg/pdfx) pakken (Ross Moore et al.) gir utmerket støtte for PDF/A-1|2|3b (arkivering), og andre alternativer, men produserer ennå ikke tagget PDF. --- # 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/no/flere-emner/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.