> 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/da/flere-emner/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # En introduktion til taggede PDF-filer: indre opbygning og udfordringerne ved tilgængelighed ## Opdatering: januar 2026 Se venligst [Overleafs vejledning til at oprette taggede PDF-filer](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Den [LaTeX-teamet](https://latex-project.org/) har udgivet nye funktioner, der muliggør automatisk PDF-tagging, det centrale krav for PDF-tilgængelighed. Disse nye funktioner er tilgængelige i Overleaf i [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), med nyere opdateringer tilgængelige i den rullende TeX Live-udgave, som er tilgængelig gennem [Overleaf Labs](https://www.overleaf.com/labs/participate). Det er nu muligt at producere en tagget PDF fra LaTeX-kilde, der er i overensstemmelse med WCAG 2.1 niveau AA, ved at følge [vores brugerdokumentation](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) ved at bruge TeX Live-udgaver, der er tilgængelige i Overleaf. Artiklen nedenfor fra 2020 er, selv om den ikke er opdateret med de nyeste oplysninger om LaTeX-tilgængelighed, stadig værd at læse for interessens og baggrundsviden om PDF-tagging. *** ## Hvad dækker denne artikel? Formålet med denne artikel er at give en introduktion til taggede PDF-filer sammen med et overblik over nogle tekniske udfordringer, som software står over for, herunder TeX-motorer og LaTeX, som har til formål at producere taggede og tilgængelige PDF-filer. Tilgængelighed, især for PDF-filer, er et bredt og komplekst emne, som også rummer tekniske udfordringer, der ikke altid har én enkelt, universelt anerkendt eller accepteret løsning—såsom hvordan man repræsenterer kompleks matematik i PDF-filer på en tilgængelig måde: ved brug af MathML eller LaTeX-kode? Selvom vi ikke kan gå i dybden med hvert emne og må forenkle mange detaljer, kan vi se ind i PDF-filerne for at vise, hvad det egentlig indebærer at tagge en PDF. Overleaf håber, at denne artikel vil fungere som en nyttig introduktion, der giver tilstrækkelig baggrund til at hjælpe læserne med bedre at forstå de tekniske udfordringer og understøtte videre læsning og udforskning af taggede PDF-filer og tilgængelighed. Ressourcer i denne artikel omfatter: * [en 8-minutters video](#video-showing-the-logical-structure-of-a-tagged-pdf) der udforsker en tagget PDF oprettet med LaTeX; * [et Overleaf-projekt](#using-luatex-an-example-in-the-overleaf-gallery) til at udforske brugen af mellemrumstegn i LuaTeX; * [lydoptagelser](#tagged-yes-but-the-reading-order-is-incorrect) der demonstrerer problemer med PDF-tilgængelighed. ## Introduktion At sikre tilgængelighed af digitalt indhold anerkendes med rette som et vigtigt aspekt af produktion og formidling af indhold. Desuden vedtager regeringer, herunder [Storbritannien](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), love, som kræver, at indhold produceret under deres jurisdiktion overholder definerede tilgængelighedskriterier. Overholdelse gennem formidling af indhold i HTML er ikke urimeligt byrdefuldt, men det kan være en betydelig teknisk udfordring at sikre det nødvendige tilgængelighedsniveau for dokumenter, der distribueres i PDF-format—afhængigt af den software, der bruges til at forfatte indhold, der skal udgives som en PDF-fil. PDF opstod i begyndelsen af 1990'erne som en løsning på problemerne omkring pålidelig dokumentoverførsel, og historien har vist, at det har været en enorm succes. PDF er dog også et komplekst filformat, som opstod før den brede anerkendelse og accept af behovet for at fremme tilgængelighed af dokumentindhold. Ikke desto mindre har PDF-specifikationen over tid udviklet sig til at levere funktioner, som muliggør og understøtter produktion af tilgængelige PDF-dokumenter ved hjælp af en “stiliseret” variant af PDF, som Adobe kalder *tagget PDF*. I praksis stiller produktionen af taggede—*og fuldt tilgængelige*—PDF-filer betydelige ekstra tekniske krav til software, der udskriver PDF—og det omfatter TeX-motorer og LaTeX-økosystemet af makroer og ekstra LaTeX-pakker. ## Tilblivelsen af PDF som digitalt papir i slutformat Den [tilblivelsen af Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) stammer fra en tid, hvor overførsel af dokumenter mellem computere var forbundet med vanskeligheder, ofte forårsaget af filkonverteringer, som resulterede i ombrydning af sider og andre afvigelser, forværret af inkompatible skrifttyper og tekstkodninger brugt på forskellige operativsystemer (især Windows og Macintosh). Denne artikels forfatter arbejdede dengang inden for udgivelse og har levende minder om at håndtere disse udfordringer! PDF blev designet til at løse problemer med fildeling gennem introduktionen af et universelt digitalt papir i endelig form (ikke-redigerbart), hvilket muliggjorde problemfri overførsel af selvstændige dokumenter, som indeholdt de skrifttyper, der krævedes for at vise dem. Brugere kunne endelig overføre alle slags dokumenter med rimelig sikkerhed for, at modtagerne, uanset computerplatform, kunne åbne og læse dem—dokumenttrofasthed blev bevaret, og rodede sideombrydninger samt skrifttypekompatibilitet/-tilgængelighed hørte fortiden til. ### Digitalt papir: godt for alle brugere? PDF's slægt som en form for digitalt papir tog naturligt udgangspunkt i brugen af trykte sidenumre, typografi eller designelementer som pejlemærker for visuel navigation i indholdet—på skærm eller på papir. Men disse visuelle pejlemærker/mekanismer er selvfølgelig meningsløse for mennesker med alvorlig synsnedsættelse. I dag anerkendes forbedret tilgængelighed af digitalt indhold med rette som et vigtigt aspekt af produktion og formidling af indhold. Udfordringen for PDF var at levere mekanismer, der muliggør ikke-visuel adgang til indhold låst inde i en “beholder”, der oprindeligt var designet til at genskabe det visuelle medium fra den trykte side. Den første version af PDF-specifikationen (PDF 1.0) blev [officielt udgivet den 15. juni 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) fulgt af nye versioner med opdateringer, som i 2001 (PDF 1.4) omfattede introduktionen af “tagget PDF”, som [“...gjorde det muligt for brugere af hjælpemidler”](https://www.adobe.com/accessibility/pdf.html). Efterfølgende udgivelser af PDF-specifikationen har udvidet og forbedret PDF's funktioner, hvilket kulminerede i den seneste udgave (PDF 2.0), som ifølge [rapporter](https://www.pdfa.org/tagged-pdf-2-0/), har gennemgået en omfattende overhaling af tilgængelighedsfunktioner—selvom PDF 2.0 endnu ikke understøttes særligt godt af TeX-motorer. ## Indhold i PDF-filer For at forstå de involverede problemer er det værd at undersøge, hvordan PDF-filer faktisk repræsenterer det sideindhold, de indeholder. Dybt inde i en PDF-fil ligger indholdet for hver side i den pågældende sides *indholdsstrøm*: en sekvens af PDF-operatorer (“kommandoer”), som placerer tekst eller grafik på en bestemt position på siden til rendering (visning) af den software, der bruges til at *vise* PDF'en. I praksis giver indholdsstrømmen en grafisk beskrivelse eller en “opskrift”, som fortæller PDF-visningsprogrammer, hvordan hver side skal “tegnes”—hvad der skal vises på siden, og hvor. Naturligvis omfatter denne række af operatorer instruktioner til at vælge bestemte skrifttyper i en specifik størrelse, vælge farver, definere linjebredder, tegne linjer, kurver og så videre—alt, hvad der kræves for at give en fuldstændig grafisk beskrivelse til visuel præsentation af en side. For at reducere filstørrelsen komprimeres PDF-indholdsstrømme og gemmes i et kompakt binært format, men hvis du har adgang til passende software, såsom Adobe Acrobat Pro DC, kan du bruge den til at se en “dekomprimeret” ren tekst-version af sideindholdsstrømme. Lad os overveje, hvordan PDF-operatorer kan “tegne” en tabel: PDF-indholdsstrømmen ville indeholde en passende sekvens af operatorer til at producere vandrette/lodrette linjer, vælge forskellige skrifttyper og outputte tekst placeret på forskellige positioner på siden for at producere tabellens indhold. For at demonstrere dette, lad os se på et meget enkelt utaggede PDF-dokument, der ikke indeholder andet end en grundlæggende tabel med lidt tekst—oprettet i Microsoft Word af grunde, som bliver tydelige senere i artiklen. Her er et skærmbillede, der viser vores enkle PDF: ![En tabel oprettet i Microsoft Word](/files/164dfb314ddea6b004398d4040c9f8babd436807) Hvis vi udtrækker den (dekomprimerede) sideindholdsstrøm for denne fil og indsætter de første få linjer i en teksteditor, kan vi opsummere nogle af PDF-operatorerne for at få en “fornemmelse” af, hvordan PDF-filer “beskriver” indholdet, der vises på denne side. ![Billede af indholdsstrøm i en PDF-fil](/files/55d32bee3bcaaa8248a2518fea7327dadb19b116) Hvis du har adgang til Adobe Acrobat Pro DC, kan du bruge det til at liste de operatorer, der findes i en PDF-sides indholdsstrøm. Her er Acrobats *Intern PDF-struktur* visning af den samme PDF, som hjælpsomt giver en enlinjers beskrivelse af hver operator, der bruges til at “tegne” vores ene side med en simpel tabel—bemærk, at disse korte beskrivelser leveres af Adobe Acrobat Pro DC, de er *ikke* til stede i selve PDF-filen: ![Billede af en PDF-indholdsstrøm vist i Adobe Acrobat Pro DC](/files/c2d2b80c78737ec153e8a9b0bb2c19edddc5f3f3) Bemærk dog, at ingen af disse tegningsinstruktioner (operatorer) lagrer nogen “betydning” eller “beskrivelse” af, hvad de faktisk producerer: de er blot et sæt grafikoperatorer, som resulterer i opbygningen af det, som en *seende observatør genkender* som en tabel. Det er tydeligt, at for personer med alvorlig synsnedsættelse er det ikke en brugbar metode til at få adgang til indholdet at vise tabellen, som disse grafiske operatorer i PDF'ens indholdsstrøm resulterer i. Det, der kræves, er en mekanisme, hvor PDF-filer kan indeholde en passende ikke-visuel (maskinlæsbar) beskrivelse af den tabel—og naturligvis alt andet indhold på siderne i en PDF-fil. For at muliggøre ikke-visuel adgang til indhold skal PDF-filer indeholde yderligere data, som knytter “betydning” eller semantik til samlinger eller grupper af operatorer, der bruges til at “tegne” et bestemt stykke indhold. Denne principielle tildeling eller levering af “betydning” må nødvendigvis udvides til alle former for indhold i en PDF: den mekanisme findes og kaldes *tagging* af PDF'en for at producere en “variant” af PDF kaldet, ikke overraskende, *tagget PDF*. ## Introduktion til tagget PDF Tagged PDF er navnet på en bestemt type PDF-fil, som indeholder yderligere data (og datastrukturer), der ikke findes i utaggede PDF-filer. Selvom principperne/idèerne bag tagged PDF kan beskrives overordnet, er detaljerne komplekse og fylder mange sider i den formelle PDF-specifikation. Adobe designede tagged PDF for at opfylde en række mål, som inkluderede at gøre indhold tilgængeligt for brugere med synsnedsættelser, men det omfatter også den følgende liste fra afsnit 10.7 i [Adobes PDF 1.7-specifikation](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * simpel udtrækning af tekst og grafik til indsættelse i andre programmer; * automatisk ombrydning af tekst og tilhørende grafik, så de passer til en side af en anden størrelse end den, der blev antaget for det oprindelige layout; * behandling af tekst til formål som søgning, indeksering og stavekontrol; * konvertering til andre almindelige filformater (såsom HTML, XML og RTF) med dokumentstruktur og grundlæggende formateringsoplysninger bevaret. Derudover kræver tagged PDF også: * at tekst i PDF-indhold repræsenteres i en form, der kan konverteres til Unicode; * ordskift skal repræsenteres eksplicit—bemærk, at TeX-motorer ikke bruger mellemrumstegn til at adskille ord, de bruger TeX's fleksible afstand kaldet glue (se nedenfor); * faktisk (“rigtigt”) indhold adskilles fra layout- og pagineringsartefakter. Bag tagged PDF ligger to nøglebegreber, som vi gennemgår: * at definere den logiske struktur af indhold i en PDF-fil; * markering (tagging) af PDF-indhold med et sæt standardindholdstyper. ## Logisk struktur I længere dokumenter opdeles indhold normalt i en sekvens af mindre indholdselementer; for eksempel er bøger typisk opdelt i kapitler, som selv er opdelt i sektioner og undersektioner, der indeholder afsnit, tabeller, figurer/diagrammer, punkt- eller nummerlister, fodnoter og referencer og så videre. Strukturen og organiseringen af indholdet i en sådan bog eller enhver anden dokumenttype kaldes dens *logiske struktur*. Forestillingen om et dokuments logiske struktur spiller en vigtig rolle for PDF-tilgængelighed, men som begreb kan logisk struktur virke lidt vag og vanskelig at forstå. Den følgende definition fra [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) giver nyttig indsigt: > “Logisk struktur henviser til den måde, information i et dokument er organiseret på; den definerer informationshierarkiet og relationen mellem forskellige dele af dokumentet. Logisk struktur angiver, hvordan et dokument er opbygget, i modsætning til hvad et dokument indeholder.” Bemærk, at denne definition af logisk struktur ikke henviser til præcist *hvordan* hvor disse strukturelle oplysninger er fysisk gemt; blot at de giver en repræsentation af et dokuments struktur og organisering. De præcise detaljer om, hvordan et dokuments logiske struktur gemmes eller repræsenteres, afhænger af implementeringen: en funktion af den software, der bruges til at generere og behandle den. ### Logisk struktur i PDF-filer PDF-specifikationen giver mekanismer, hvorigennem et dokuments logiske struktur kan registreres i en PDF-fil—til brug for software, som for eksempel måske vil eksportere PDF'ens indhold til andre formater såsom XML, HTML eller Microsoft Word. Disse eksportprocesser skal producere et korrekt struktureret tekstdokument, der overholder reglerne for det målrettede eksportfilformat—that kan bedst opnås, når eksportbehandlingen styres af de logiske strukturinformationer, der findes i PDF'en. Derudover er den logiske struktur i en PDF-fil afgørende for tilgængelig software, som for eksempel måske vil udføre tekst-til-tale-funktioner og læse indhold højt for en person med synsnedsættelse. Tekst-til-tale-processen skal sikre, at indhold læses højt i den korrekte rækkefølge/sekvens, ellers vil den producere meningsløse resultater. Bemærk også, at selve begrebet en side måske slet ikke giver mening for tilgængelighedsapplikationer, der kun er interesserede i PDF'ens indhold og dokumentets struktur, ikke den visuelle opdeling og præsentation i sideformaterede blokke. #### Navngivning af indholdselementer Registrering (lagring) af et PDF-dokuments logiske struktur kræver et sæt meningsfulde navne tildelt de forskellige *typer* af indholdselementer, som sandsynligvis findes som en del af et typisk PDF-dokument—hvilket identificerer indholdssektioner, der repræsenterer overskrifter, afsnit, tabeller, lister og så videre. Derudover har nogle indholdselementer såsom indholdsfortegnelser, nummererede/punktlister og tabulært materiale ganske komplekse egne strukturer, så der er også behov for en form for vejledning/regler, der angiver, hvordan disse mere komplekse indholdselementer er opbygget—deres understruktur. Et yderligere krav er klart at identificere alt PDF-indhold, som bør ignoreres af hjælpesoftware, der behandler PDF'en; for eksempel er sidehoveder og sidefødder pagineringsartefakter, der indeholder tekst, som er overflødig for personer med alvorlig synsnedsættelse: det indhold bør ignoreres. De mekanismer, som PDF bruger til at definere et dokuments logiske struktur, er designet til at være fleksible, så i princippet kunne forskellige programmer, der genererer og behandler PDF-filer, bruge navne til indholdstyper efter enhver konvention, de ønsker. Men for at maksimere dokumentudveksling og gøre det muligt for forskellige PDF-behandlingsprogrammer at give ensartede resultater definerede Adobe et sæt standardnavne for typer af indholdselementer, som PDF-genereringssoftware bør følge. I PDF-specifikationen omtales disse standardnavne som tags, hvilket giver anledning til begrebet *tagget* PDF. ### Markering af PDF-indhold: Et kig “under motorhjelmen” For at gøre diskussionen lidt mindre abstrakt vil vi kort se på internals i taggede PDF-filer—selvom vi ikke kan dække alle detaljerne, fordi tagged PDF er et så stort og komplekst emne. #### Markerede indholdssekvenser: byggesten for tagged PDF På laveste niveau begynder processen med at registrere betydningen af indhold i en PDF-side (dvs. i dens indholdsstrøm) med *markerede indholdssekvenser* som bruges til at identificere (give “betydning” til) klynger eller grupper af PDF-operatorer. Markerede indholdssekvenser tildeles en numerisk identifikator kaldet dens `MCID` (*marked content identifier*) som er et heltal, der løber fra 0 til en maksimal N på hver side. Disse `MCID` værdier giver en måde at entydigt identificere sekvenser af operatorer indeholdt i indholdsstrømmen for en bestemt side. For at præcisere: for hver side starter `MCID` identifikatorerne ved 0 og stiger sekventielt op til en maksimal værdi, som afhænger af, hvor mange markerede indholdssekvenser der er indeholdt i en bestemt sides indholdsstrøm. Markerede indholdssekvenser er i praksis fundamentale “byggesten”, som bruges til at samle datastrukturer på højere niveau kaldet *struktur-elementer*. Disse struktur-elementer indeholder et tag, som er det navn, der bruges til at identificere, hvilken type indholdselement de repræsenterer. #### Eksempel på struktur-elementer Her springer vi en smule frem, men det er værd at gennemgå et eksempel. Antag, at du har 3 små tekstfragmenter af sideindhold, og at hvert af dem er identificeret i indholdsstrømmen ved en forskellig markeret indholdssekvens. Hvert af disse 3 tekstfragmenter kan pakkes ind i sit eget struktur-element med et tag, og alle tre kan “kobles sammen” ved hjælp af et andet struktur-element for at repræsentere et indholdselement på højere niveau, såsom en linje i en indholdsfortegnelse. ![Billede, der forklarer struktur-elementer og markerede indholdssekvenser](/files/3679191880c2550bae970a533ae7100b8daa22df) Gennem en form for forælder-barn-datalrelation kombineres samlinger af struktur-elementer for at skabe sammenkædede datastrukturer, der repræsenterer mere komplekse dataelementer såsom nummererede og punktopstillede lister, tabeller, matematik og så videre. I sidste ende forbindes hele samlingen af struktur-elementer i hele PDF-filen yderligere og kombineres for at skabe dokumentets logiske struktur—vi vender tilbage til dette senere i artiklen. ### Hvad er en markeret indholdssekvens? I diskussionen ovenfor brugte vi et enkelt utaggede PDF-dokument indeholdende en tabel (oprettet i Microsoft Word), men hvis vi beder Word om at oprette en tagget PDF, kan vi se, at noget ekstra markering er dukket op i sidens indholdsstrøm. Her ser vi kun på de første få linjer af indholdsstrømmen (der er hundredvis af linjer), men bemærk tilstedeværelsen af yderligere operatorer såsom `/P <> BDC` og `EMC` som bruges til at identificere en markeret indholdssekvens. Vi vil ikke udforske den fulde syntaks for markerede indholdssekvenser, men henviser læseren til side 862 i [Adobes officielle PDF 1.7-specifikation](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Billede, der viser markerede indholdssekvenser i en tagget PDF-indholdsstrøm](/files/95c13ee2883cbf3eef6fc5c0bf16d708c9120b4a) For nem reference viser vi igen den utaggede version: ![Billede, der viser PDF-indholdsstrøm](/files/55d32bee3bcaaa8248a2518fea7327dadb19b116) I *utaggede* PDF, operatorer såsom `/P <> BDC` og `EMC` er fraværende, men de resterende operatorer er uændrede: den utaggede PDF mangler den ekstra markering, der bruges til at identificere visse sekvenser/samlinger af operatorer. Igen kan vi også bruge Adobe Acrobats *Intern PDF-struktur* funktion til at vise de markerede indholdssekvenser i en indholdsstrøm—her har vi fremhævet dem med en grøn kant: ![Billede, der viser markerede indholdssekvenser i en tagget PDF-indholdsstrøm set i Adobe Acrobat Pro DC](/files/890201164ee73ebb2022395f8a6850ab25f67a72) Bemærk, at nogle indholdselementer er markeret med `/Artifact` som identificerer materiale på PDF-siden, der bør være *ignoreret* af hjælpesoftwareapplikationer, såsom dem der læser højt for synshæmmede personer. Det følgende skærmbillede viser en udvidet visning af den første markerede indholdssekvens—den med `MCID` værdi `0`. Slutningen af den markerede indholdssekvens identificeres af PDF-operatoren `EMC`. ![Billede, der viser detaljer om de operatorer, der er omfattet af en markeret indholdsstrøm](/files/a6bddc588c668ce0eb936fc2a5687a2f36340123) ### Lagring af den logiske struktur Som nævnt er det, ud over at give en beskrivelse af enkelte indholdselementer (afsnit, lister, tabeller osv.), nødvendigt for tilgængelige PDF-filer at indeholde en repræsentation af hele dokumentet i form af dets logiske struktur. Enkelte dele af tilgængeligt indhold skal forbindes for at skabe et komplet, navigerbart og tilgængeligt dokument—på samme måde som et enkelt HTML-dokument konstrueres af afsnit, grafik og tabeller for at skabe en webside. Desuden er det afgørende, at et PDF-dokuments logiske struktur sikrer, at alt indhold kan navigeres i den korrekte *læserækkefølge*, uafhængigt af den rækkefølge, hvori sideindholdet blev skrevet ud til sidens indholdsstrømme i PDF'en. Vi undersøger læserækkefølgen mere detaljeret nedenfor. #### Logisk struktur: et “træ” af struktur-elementer Vi bemærkede, at PDF-filer bruger noget kaldet et *struktur-element* til at repræsentere enkelte indholdselementer, og at et struktur-element indeholder et tag til at identificere, hvilken indholdstype det repræsenterer. For at give en repræsentation af dokumentets logiske struktur er alle struktur-elementer bundet sammen ved hjælp af forælder-barn-relationer og organiseret i et “strukturtræ”. Internt indeholder taggede PDF-filer et objekt kaldet `StructTreeRoot` som indeholder (peger på) struktur-elementer, der fungerer som udgangspunkt eller “rod” i dokumentets logiske strukturtræ. Normalt begynder “roden” i strukturtræet med et enkelt struktur-element, der er tagget `Document` som indeholder adskillige *underordnede* struktur-elementer, som samlet repræsenterer hele dokumentets indhold. Enhver software, der er designet til at producere tilgængelige PDF-filer via tagging, må opbygge denne meget komplekse datastruktur (og andre!)—og det omfatter TeX-motorer og LaTeX. Et eksempel på et sådant dokumentstrukturtræ (`StructTreeRoot`) vises i det følgende skærmbillede af en tagget PDF åbnet i Adobe Acrobat Pro DC: ![Billede, der viser StructTreeRoot i en tagget PDF](/files/3209d7eb3a4fc453d9925d7ef2de9b26c7a619c1) Sammenlign ovenstående struktur med den utaggede PDF-version: ![Billede, der viser fraværet af StructTreeRoot i en utaggede PDF](/files/7013f55623ee68265e1d87ccd29f9ff45c1dcd6a) ### Udforskning af PDF-filers logiske struktur Vi begynder med nogle grafikopslag, der opsummerer det, vi har gennemgået, og afslutter med en video, der bruger Adobe Acrobat Pro DC til at vise flere detaljer om den logiske struktur i en tagget PDF-fil. Først starter vi med en skitse, der viser de generelle principper: en PDF-side med sin indholdsstrøm markeret med markerede indholdssekvenser (MCS). ![Grafik, der viser begrebet markerede indholdssekvenser i PDF-dokumentsider](/files/87ee921edf98b472595e42c51ea15cbefb852455) Disse MCS kombineres efterfølgende til *struktur-elementer* som danner grundlaget for større indholdstyper, der selv yderligere forbindes for at lagre PDF'ens logiske struktur i et objekt kaldet `StructTreeRoot`. ![Grafik, der viser den logiske struktur i en tagget PDF-fil](/files/a516ddcd3613a886ffc56dd7b8701a93b6fa4721) #### Video, der viser den logiske struktur i en tagget PDF Den følgende video (8 minutter) bruger Adobe Acrobat Pro DC til at tage dig med på en “guidet tur” for at udforske detaljer i den logiske struktur af en tagget PDF-fil oprettet med LaTeX. Den taggede PDF-fil, der bruges i videoen, hedder `tagpdf.pdf`, som er et glimrende eksempel og indeholder dokumentation for den eksperimentelle LaTeX-pakke [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Formålet med `tagpdf` pakken er at levere “værktøjer til at eksperimentere med tagging og tilgængelighed ved hjælp af pdfLaTeX og LuaTeX”. {% embed url="" %} ### En bemærkning om tagging og fleksibilitet HTML-specifikationen giver et stort antal foruddefinerede tags til brug ved opbygning af websider, men den tillader også fleksibilitet i, hvordan du kombinerer dem for at skabe det ønskede HTML-dokument. På samme måde giver Adobes tagged PDF-specifikation et sæt foruddefinerede tagnavne, men pålægger meget få begrænsninger for, hvordan du kombinerer disse tags for at repræsentere komplekse indholdselementer i en PDF—af design er der stor fleksibilitet. Derudover er det med enhver specifikation så stor og kompleks som PDF uundgåeligt, at nogle tvetydigheder eller klarhedsproblemer sniger sig ind i den skrevne specifikation. Softwareudviklere, der får til opgave at implementere en så kompleks specifikation, må måske foretage “skønsmæssige vurderinger”, når de fortolker den, fordi de står over for at omsætte skriftlige beskrivelser til fungerende kode. Den iboende fleksibilitet i tagged PDF sammen med fortolkning af specifikationer (eller tilgængelighedsstandarder) påvirker naturligvis udviklere af dokumentforfatterprogrammer: hvilke kombinationer af tags skal bruges til at repræsentere brugeroprettet indhold, når det outputtes til en tagget PDF-fil? Hvis man medregner brugernes ubegrænsede mulighed for at konstruere al slags indhold ved hjælp af funktionerne i dokumentforfattersoftwaren, kan man se, at automatisk produktion af tilgængelige taggede PDF-filer er noget af en udfordring! Måske som en afspejling af de uundgåelige kompleksiteter ved at producere taggede PDF-filer, der fuldt ud overholder tilgængelighedsstandarder, er internettet fyldt med “how to”-vejledninger, “tips” og råd om “best practice” til at oprette taggede PDF-filer via software såsom Adobe InDesign eller Microsoft Word. Derudover har PDF Association udgivet et nyttigt dokument kaldet [Tagged PDF Best Practice Guide](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) skrevet for at hjælpe udviklere, der står over for udfordringerne ved at implementere tagged PDF og PDF/UA. ## Har du en PDF, men er den tilgængelig? For at afgøre, om en given PDF-fil overholder krævede tilgængelighedsstandarder såsom PDF/A eller PDF/UA (se nedenfor), skal den *valideres* ved hjælp af en aftalt valideringsproces eller et softwareværktøj. Validering finder dog normalt sted, efter at dokumentet er færdigt, men denne proces udføres måske ikke af dokumentets forfatter, men af tilgængelighedsspecialister i den organisation eller det organ, som krævede overholdelse. Hvis PDF'en ikke består valideringen, kan det være nødvendigt med dygtig manuel indgriben via Adobe Acrobat Pro DC for at rette taggene (hvis det er muligt). Alternativt kan den endda skulle sendes tilbage til forfatteren for at ændre deres oprindelige dokument, muligvis ved at undgå brug af de funktioner i forfattersoftwaren, som forårsagede problemerne—noget der kan være ekstremt vanskeligt at opnå, fordi det kan ligge uden for forfatterens kontrol. ### Læsrækkefølge og indholdsordning Som nævnt stiller produktionen af virkelig tilgængelige PDF-filer yderligere tekniske krav til forfattersoftwaren og potentielt også til dokumentforfattere ved at håndhæve “forfatterdisciplin” i, hvordan de bruger/anvender funktionerne i forfattersoftwaren. Selvom tagged PDF er den mekanisme, der *muliggør* produktionen af fuldt tilgængelige PDF-filer, betyder det, blot fordi en PDF er tagget, ikke *ikke* automatisk, at den er fuldt tilgængelig, som vi vil se i et eksempel nedenfor. For at producere fuldt tilgængelige PDF-filer bør alle indholdselementer i PDF'en tagsættes for at skabe en logisk struktur, som sikrer, at indholdet kan tilgås og læses i den korrekte rækkefølge—kaldet *læserækkefølge*. Dette kan synes “indlysende”, men når software skriver en PDF-fil ud, kan den outputte grafik og tekst til sidens indholdsstrømme i hvilken som helst rækkefølge, den vælger. Antag for eksempel, at en side startede med noget tekst, efterfulgt af en tabel og afsluttes med en grafik, hvilket giver en naturlig *læserækkefølge* af: 1. text 2. table 3. grafik Når den skrives til en PDF, kan software, der genererer en indholdsstrøm for den side, starte med operatorer til at tegne tabellen, derefter outputte operatorer til at producere grafikken efterfulgt af operatorer til teksten, hvilket i indholdsstrømmen ville give en *indholdsordning* af: 1. table 2. grafik 3. text Naturligvis vil alt blive placeret på den korrekte position, når siden vises. For en fuldt seende læser er den rækkefølge, hvori disse elementer er gemt i sidens indholdsstrøm, uden interesse: de oplever en fuldt gengivet side, hvor alt er placeret korrekt. Men hvis hjælpesoftware skulle basere sig på rækkefølgen af elementer i en indholdsstrøm (indholdsordningen), ville den møde problemer, hvis indholdsordningen var anderledes end den naturlige læserækkefølge; for eksempel ville værktøjer til oplæsning læse materialet i den forkerte sekvens. Heldigvis kan hjælpesoftware bruge en tagget PDFs logiske rækkefølge (struktur), som skal organiseres, så den afspejler den sekvens, hvori indholdet bør læses. Det er af disse grunde, at data, der repræsenterer dokumentets logiske struktur, gemmes separat fra det faktiske indhold, der vises på de synlige sider, for at tillade > “... at ordningen og indlejringen af logiske indholdselementer er helt uafhængig af rækkefølgen og placeringen af grafiske objekter på dokumentets sider.” (side 856 i [The PDF Reference, sjette udgave, 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 mere udfordrende, end det måske ser ud, at garantere en logisk orden, som bevarer læserækkefølgen, så lad os bruge et enkelt, om end opdigtet, eksempel, som giver en indikation af de involverede problemer. #### Forkert læserækkefølge: Et eksempel med Microsoft Word En forfatter til et dokument kan bruge funktionerne i den valgte forfattersoftware til at opnå en bestemt visuel effekt—såsom at bruge tabeller til at skabe et bestemt tekstlayout. For eksempel viser det følgende skærmbillede Microsoft Word-dokumentet, der blev brugt i tidligere eksempler. Det indeholder en tabel, som er blevet brugt til at skabe et sæt nummererede afsnit side om side. Men når det kommer til tagging af dette indhold, hvordan skal det så behandles: tagget som en tabel eller en nummereret liste? Begge disse indholdstyper kræver en kompleks tagsætningsstruktur for at repræsentere dem korrekt. I det følgende billede skal du lægge mærke til den rækkefølge, som de nummererede afsnit er tænkt læst i: kolonne for kolonne, ikke række for række. ![Billede af en tabel oprettet i Microsoft Word](/files/32a0add6d7882e3e6381b9dd567ee292b8dc8106) Hvis vi beder Word om at gemme dette dokument som en PDF ved hjælp af den indbyggede eksport—ikke Acrobat PDFMaker-plugin'et—kan vi bede det om at oprette en tagget PDF: ![Indstillingsdialogboksen i Microsoft Words eksportproces](/files/3b98144fc541e1f35b6e4c02bd4c8940e5a17315) Så hvordan tagger Word dette layout? I den følgende meget korte video (14 sekunder) bruger vi Adobe Acrobat Pro DC til at inspicere tag-strukturen, som Microsoft Word har produceret. {% embed url="" %} For dette dokument har Word oprettet et tagget PDF-dokument, som bruger en `Table` tag, der indeholder to undertags: `THead` for tabelhovedets rækkegruppe og og `TBody` til at repræsentere gruppen af rækker for tabelkroppen. `THead` og `TBody` begge indeholder `TR` tags til at repræsentere de enkelte indholds-rækker. De `TR` tags indeholder yderligere tags til at repræsentere det nummererede listeelement, der findes i hver celle. Det følgende skærmbillede viser den dybt indlejrede tag-struktur og den tilsvarende komplekse logiske struktur, der er nødvendig for at repræsentere selv dette ekstremt grundlæggende dokument! ![Billede, der viser dybt indlejret tag-struktur og logisk struktur af en enkel tabel oprettet i Microsoft Word](/files/7eaa9f9941fdfaa5df5299fd8c9551c5466382bc) Sammenlignet med PDF'er genereret af TeX og LaTeX er dette Word-eksempel et ekstremt enkelt dokument, men det kræver stadig en kompleks logisk struktur for at repræsentere det. Forestil dig det niveau af tagging-kompleksitet, der kræves for at repræsentere LaTeX-genererede PDF'er med kompleks matematik og tabeller! #### Tagget, ja, men læserækkefølgen er forkert Selv om Word faktisk producerer en [tagget PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) det demonstrerer en af de grundlæggende udfordringer, som enhver applikation, der forsøger at producere fuldt tilgængelige PDF'er, står overfor: at repræsentere indholdets tilsigtede læserækkefølge korrekt. Under oprettelsen af den taggede PDF besluttede Words interne processer at skrive den tilsvarende indholdsstrøm ved at outputte tabellen række for række, ikke kolonne for kolonne. For en fuldt seende læser, der ser PDF'en, gør disse detaljer på lavt niveau ingen forskel: tabellen vises korrekt. For synshæmmede giver Words logiske dokumentstruktur imidlertid det forkerte resultat, fordi den ønskede læserækkefølge (kolonne for kolonne) ikke bevares: indholdet læses op i forkert rækkefølge. Den følgende lydoptagelse blev produceret ved hjælp af Adobe Reader DC's “Read Out Loud”-funktion. Som det fremgår, læses teksten op i den forkerte rækkefølge: række for række, ikke kolonne for kolonne: ![En tabel oprettet i Microsoft Word](/files/a6f47595c3643a7ad49b717d3912c5cd25dd0741) Som nævnt ovenfor er dette eksempel noget konstrueret, men det demonstrerer, hvor let det er at anvende kombinationer af softwarefunktioner, som udløser tilgængelighedsproblemer—men hvordan forventes dokumentets forfatter at vide dette på forhånd? Det er sandsynligt, at dette problem kun ville blive opdaget, hvis den resulterende PDF gennemgik praktiske tilgængelighedsbrugstests—for eksempel ved hjælp af hjælpesoftware. Potentielt kunne sådanne dokumenter bestå PDF/A-overensstemmelses-/valideringstests, men fejle i brug i den virkelige verden. At sikre den korrekte læserækkefølge i en sådan PDF-fil ville kræve dygtig manuel indgriben ved hjælp af avancerede PDF-redigeringsværktøjer såsom Adobe Acrobat Pro DC: en tidskrævende og dyr proces. Alternativt kunne dokumentets forfatter afstå fra at bruge denne særlige form for indholdsudtryk eller layout—men kun hvis de vidste, at det var problematisk! ### Brug af mellemrumstegn til at adskille ord Når du skriver tekst i tekstbehandlingsprogrammer eller teksteditorer, bruger du mellemrumstegnet til at markere slutningen på et ord og begyndelsen på det næste. Hvis du senere opretter en PDF fra et sådant dokument, vil de mellemrumstegn, du skrev, naturligvis blive medtaget og udgøre en del af den tekst, der er gemt i PDF'en. Men TeX-motorer bruger ikke mellemrumstegn til at adskille ord i typograferet tekst; i stedet omdanner de mellemrumstegn til en form for fleksibel afstand kaldet glue (se denne [Overleaf-artikel](/latex/da/dybtgaende-artikler/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) for mere information om TeX-bokse og glue). Inden for indholdsstrømmen på PDF-sider oprettet af TeX-motorer opnås adskillelsen af individuelle ord ved at flytte til en anden position på siden og starte teksten for det næste ord—i stedet for at udskrive et mellemrumstegn for at opnå denne afstand. Desuden varierer mængden af mellemrum mellem ord i afsnit typograferet af TeX-motorer fra linje til linje på grund af TeX's linjebrydningsalgoritme. Denne variation afspejles i de positionsdata, der skrives ud til PDF-sidernes indholdsstrøm. Dette aspekt af TeX's typografering har konsekvenser for kopiering/indsættelse af tekst fra dets PDF'er og for hjælpesoftware, der forsøger at læse den typograferede tekst højt i PDF'er produceret af TeX-motorer. Hjælpesoftware skal analysere en PDF-sides indholdsstrøm for at udtrække den tekst, den skal behandle. Det er tydeligt, at sådan software har brug for en mekanisme til at registrere starten og slutningen af ord—den mest oplagte løsning er at bruge et mellemrumstegn. Med det in mente kræver tilgængelighedsstandarder, at de enkelte ord tydeligt afsluttes (f.eks. med mellemrumstegn), hvilket er problematisk for TeX-motorer på grund af deres brug af interword glue. #### Men alt er ikke tabt! I 2014 introducerede pdfTeX 2 nye primitiver for at forbedre understøttelsen af tilgængelighed ved at gøre det muligt at bruge mellemrumstegn mellem ord i de PDF'er, den genererer: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Disse kommandoer gør brug af en “dummy font” med kun et mellemrumsglyf. Detaljer og et eksempel findes på side 29 i [pdfTeX-brugermanualen](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Brug af LuaTeX: Et eksempel i Overleaf-galleriet LuaTeX understøtter ikke disse pdfTeX-primitiver, men det kan programmeres til at opnå resultater, der ligner pdfTeX meget, ved hjælp af LuaTeX's såkaldte callback-mekanisme. Et Overleaf-projekt til at konvertere glue til mellemrumstegn er tilgængeligt i Overleaf-galleriet under titlen [Brug af LuaTeX til at konvertere glue mellem ord til mellemrum og kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Hvis du sætter dit LaTeX-kode med LuaTeX (dvs. LuaLaTeX-kompilatorindstillingen på Overleaf), kan du ved hjælp af Lua-kode efterbehandle et typograferet afsnit for at finde eventuel glue mellem ord og erstatte den med et mellemrumstegn plus en passende kern. Den afstand, som bredden af mellemrumstegnet giver, kan lægges til (eller reduceres) ved at beregne en passende kern-værdi for at bevare den afstand, som den mellemordlige glue giver, hvilket resulterer i ingen visuel forskel i det typograferede resultat. For at forstå den forskel dette gør for brugere af tilgængelighedssoftware, kan du lytte til denne lydoptagelse optaget fra Adobe Reader DC's *Read Out Loud* funktion. Den optager de to linjer tekst i det projekt, der læses højt, før og efter konvertering af glue til mellemrum. Bemærk, hvordan den anden oplæsning af linjen, som bruger mellemrum, læses hurtigt og flydende sammenlignet med linjen, der bruger mellemordlig glue. Overleaf-projektet er en ren TeX-fil kompileret med LuaTeX og kun stillet til rådighed til eksperimentel brug; det er ikke beregnet som en fuld løsning i produktionskvalitet. Først og fremmest er det designet til at hjælpe med at forstå tekniske problemer relateret til tilgængelige PDF'er. Den Lua-kode, der bruges i det projekt, er baseret på arbejde indeholdt i en meget tidligere Overleaf-artikel [Kasser og glue: En kort, men visuel, introduktion med LuaTeX](/latex/da/dybtgaende-artikler/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Bemærk: For enkelhedens skyld bruger projektet sin egen meget minimale OpenType-skrifttypeindlæser, der er afledt af denne kode: . ### Andre tilgængelighedsproblemer og tagget PDF Selv om tagging gør det muligt at identificere indholdselementer, der findes i en PDF, kræver visse typer indhold, såsom grafik eller kompleks matematik, yderligere data eller information, hvis de skal gøres tilgængelige via software, der er designet til at understøtte synshæmmede. For at give og understøtte tilgængelighed for en bred vifte af indholdstyper giver PDF-specifikationen mulighed for at knytte “Alternative beskrivelser” eller “ActualText” til indholdselementer, hvilket giver passende tekstbeskrivelser eller andre maskinlæsbare repræsentationer. For eksempel er MathML blevet udpeget til dette formål i PDF 2.0-specifikationen. #### Er det “rigtigt indhold” eller blot et artefakt? For synshæmmede har processen med at opdele og vise indhold i rektangulære sideinddelte bidder uønskede bivirkninger, såsom orddeling. Desuden er aspekter af sidelayout eller -design, der bruges til at forbedre den visuelle præsentation, ganske meningsløse for dem, der ikke kan se det. Af disse grunde må tagging af PDF-indhold erkende, at noget indhold i en PDF bør behandles som et *artefakt* af visuel præsentation eller sidesætning. For eksempel skal sidetal, sidehoveder og sidefødder, skraverede baggrunde eller andre designelementer identificeres, så den tilgængelighedssoftware, der behandler indholdet, ved at ignorere dem. ## Oversigt over PDF/A-standarderne Anmodninger om at producere tilgængelige PDF'er henviser normalt til en ISO-standard kaldet [ISO 19005](https://www.iso.org/standard/38920.html), som oftere omtales som PDF/A. Men fordi PDF/A er en *familie* samling af standarder [PDF Associations websted](https://www.pdfa.org/resource/iso-19005-pdfa/) (besøgt 21. maj 2020), som beskriver ISO 19005 (PDF/A) således: > “Det primære formål med ISO 19005 er at definere et filformat baseret på PDF, kendt som PDF/A, som giver en mekanisme til at repræsentere elektroniske dokumenter på en måde, der bevarer deres statiske visuelle udseende over tid, uafhængigt af de værktøjer og systemer, der bruges til at oprette, lagre eller gengive filerne. > > Et sekundært formål med ISO 19005 er at definere en ramme for repræsentation af den logiske struktur og anden semantisk information i elektroniske dokumenter i overensstemmende filer. > > Et andet formål med ISO 19005 er at give en ramme for registrering af konteksten og historikken for elektroniske dokumenter i metadata i overensstemmende filer.” Det er klart, at PDF/A har flere kerneformål. ### Udvikling og vækst af PDF Den [PDF 1.0-specifikationen](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) blev offentliggjort i 1993 og omfattede kun 230 sider. Men 13 år senere var specifikationen for [Adobes PDF-version 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) langt over 1000 sider! Over tid er størrelsen og kompleksiteten af PDF-specifikationen vokset ved at udvide det understøttede funktionssæt: med nye teknologier og kravene fra stadig mere sofistikerede PDF-baserede arbejdsprocesser og anvendelsesscenarier på tværs af forskellige markeder og fællesskaber. Men det er sandsynligt, at ingen bruger eller brugergruppe nogensinde udnytter alle mulighederne: PDF må “dække alle vinkler” for at sikre, at det kan imødekomme behovene hos den størst mulige markedsgruppe. For eksempel er mange PDF-funktioner, der er designet til at understøtte high-end kommerciel trykning, ikke nødvendige i typisk daglig kontorbrug som et format til lagring eller deling af dokumentation. ### PDF/A: “tilbage til det grundlæggende” for PDF PDF/A's kerneformål er at sikre, at PDF'er, der overholder standarden, er egnede til langtidsarkivering eller indeholder indhold, som er tilgængeligt for personer, der bruger forskellige hjælpeteknologier til at “forbruge” disse PDF'er. For at opnå disse mål begrænser PDF/A det sæt af PDF-funktioner, der er tilladt i PDF-filer, der overholder standarden, og forbyder brug af funktioner, der kan kompromittere arkiverbarhed eller tilgængelighed. Du kan tænke på PDF/A som et sæt standarder, der specificerer, hvordan PDF-filer, der overholder standarden, bruger en *delmængde* delmængde af den fulde PDF-specifikation til at producere filer, der er egnede til langtidsarkivering eller til at sikre, at deres indhold er tilgængeligt. PDF/A's restriktioner gør det muligt at bruge PDF'er som et “arkivmæssigt digitalt papir”, som er uafhængigt af den PDF-læsende teknologi og det computermiljø, der bruges til at få adgang til deres indhold. PDF'er, der overholder standarden, bør ikke indeholde noget, hvis opførsel er “implementeringsafhængig”—dvs. afhænger af den specifikke software eller de operativsystemer, der bruges til at vise eller behandle dem. PDF'er skal også være *komplette*: vigtige dokumentressourcer skal være indlejret i filen—såsom skrifttyper eller farveprofiler. ### PDF/A-versioner og overensstemmelsesniveauer Der findes forskellige *versioner* versioner *af PDF/A-standarden, som hver afspejler en bestemt version af den formelle PDF-specifikation (PDF 1.4, 1.7 og 2.0). Derudover er der forskellige* overensstemmelsesniveauer **der angiver, hvilke aspekter af PDF/A-standarden en PDF-fil er i overensstemmelse med. Derfor bør du, når du hævder eller kræver “PDF/A-overensstemmelse”, tænke på PDF-filer, der overholder** For eksempel * PDF/A- * PDF/A-1a: betyder PDF/A-version 1, overensstemmelsesniveau a PDF/A-2b: betyder PDF/A-version 2, overensstemmelsesniveau b #### Vi gennemgår disse lidt nærmere. PDF/A-versioner | | | | | ----------------- | ---------------- | -------------------------- | | **PDF/A-version** | **ISO-standard** | **Baseret på PDF-version** | | 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 skrivningen (april/maj 2020) er en opdateret PDF/A-4 (ISO 19005-4) under [udarbejdelse](https://www.iso.org/standard/71832.html). #### PDF/A-overensstemmelsesniveauer Ud over tre PDF/A-versioner (PDF/A-1, PDF/A-2 og PDF/A-3) er der tre *af PDF/A-standarden, som hver afspejler en bestemt version af den formelle PDF-specifikation (PDF 1.4, 1.7 og 2.0). Derudover er der forskellige*: * Niveau A (tilgængelig) for tilgængelighed (omfatter arkiveringskravene for Niveau B) * Niveau B (grundlæggende) til arkivering * Niveau U (Unicode) (= arkivering plus brug af Unicode til tekst) Her er en kort beskrivelse af disse overensstemmelsesniveauer: * **Niveau B (grundlæggende)** er minimumskravet for overensstemmelse under PDF/A. Det definerer krav til at sikre, at PDF-dokumenter, der overholder standarden, er egnede til langtidsarkivering—at de altid kan vises eller udskrives pålideligt uafhængigt af specifik software, værktøjer eller operativsystemer. * **Niveau A (tilgængelighed)** omfatter kravene til Niveau B-overensstemmelse, men kræver derudover brug af tagget PDF for at give logisk struktur og oplysninger om læserækkefølge sammen med brug af Unicode for at give adgang til dokumentets tekst. * **Niveau U (Unicode)** overensstemmelse blev tilføjet til PDF/A-2 og bygger videre på Niveau B ved desuden at kræve brug af Unicode til dokumenttekst, men den går ikke så langt som Niveau A ved at kræve strukturinformation. PDF/A-versioner og overensstemmelsesniveauer kan opsummeres i en tabel: | | | | | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------- | | **Overensstemmelsesniveau** | **der angiver, hvilke aspekter af PDF/A-standarden en PDF-fil er i overensstemmelse med. Derfor bør du, når du hævder eller kræver “PDF/A-overensstemmelse”, tænke på PDF-filer, der overholder** | | | | Niveau A (tilgængelig) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Niveau B (grundlæggende) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Niveau U (Unicode) | Ikke relevant (fandtes ikke for PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Universel tilgængelighed”) Selv om Niveau A-overensstemmelse med PDF/A-standarden går et stykke vej i at definere kravene til tilgængelige PDF'er, går en anden ISO-standard kaldet [ISO 14289](https://www.iso.org/standard/64599.html), omtalt som PDF/UA, videre. PDF/UA styrker tilgængelighedskravene og præciserer vejledningen i PDF/A-standarderne og er blevet den foretrukne standard for tilgængelige PDF'er. #### Matterhorn-protokollen Læsere med stor interesse for at lære mere om PDF/UA-overensstemmelse vil måske finde [Matterhorn-protokollen](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) interessant, som er “en liste over alle de mulige måder at fejle PDF/UA-overensstemmelse på”. ### Valideringssoftware For at kontrollere, om en PDF-fil overholder en bestemt standard, skal den være *valideres* ved hjælp af overensstemmelsessoftware, som gennemgår PDF'en for at kontrollere, om dens indhold og struktur er i overensstemmelse med kravene i den pågældende standard—såsom PDF/UA eller PDF/A-*x*a (hvor *x* = 1, 2 eller 3). Bemærk, at validering af PDF'er—behandling af dem med et foretrukket valideringsværktøj—kan producere diagnostiske meddelelser eller advarsler, som kan være ganske kryptiske for den ikke-ekspertbruger—måske på grund af nogle PDF-data på lavt niveau (eller struktur), som ikke opfylder den relevante standard. For mange forfattere kan det være en stor udfordring at fortolke disse advarsler og omsætte dem til en handlingsklar rettelse af deres dokument(er). #### Gratis valideringssoftware * [veraPDF](https://verapdf.org/) som, for at citere deres websted (besøgt 28. maj 2020), er en “specialbygget, open source filformatvalidator, der dækker alle PDF/A-dele og overensstemmelsesniveauer”. * (kun Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) som er et “...gratis værktøj til kontrol af PDF-tilgængelighed, som er blevet prøvet og testet siden 2010”. #### Kommerciel valideringssoftware * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) tilbyder en række PDF-valideringstests sammen med værktøjer til at redigere og rette tags i ikke-overensstemmende PDF-filer. ### PDF Association: en fantastisk informationskilde Den [PDF Association](https://www.pdfa.org/) producerer mange *den fremragende* ressourcer om PDF/A, PDF/UA og mange andre PDF-relaterede emner—herunder videoer på deres [YouTube-kanal](https://www.youtube.com/user/ThePDFAssociation/playlists) sammen med artikler og gratis tekniske publikationer tilgængelige på deres websted. En sådan publikation er [PDF/UA i en nøddeskal](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) som giver en uvurderlig introduktion til PDF/UA-standarden og dens krav. ## Tilgængelige PDF'er fra TeX-motorer og LaTeX Forhåbentlig har de foregående diskussioner vist, at produktionen af fuldt tilgængelige og korrekt taggede PDF-filer er en krævende teknisk udfordring. Desuden viste selv det enkle Microsoft Word-eksempel, at forfattere meget let kan bruge kombinationer af softwarefunktioner, som resulterer i taggede PDF-dokumenter, der ikke opfylder tilgængelighedskriterierne. Som værktøj til at skabe dokumenter giver LaTeX forfattere næsten ubegrænset fleksibilitet med hensyn til det udvalg og den kompleksitet af dokumenter, du kan oprette—hvilket meget vel kan være netop grunden til at vælge det i første omgang. LaTeX understøtter også udvidelsesmuligheder via tusindvis af tilføjelsespakker, som forfattere kan bruge som en del af deres dokumenter. Oven i alt dette har forfattere friheden til at skrive nye TeX- eller LaTeX-makroer eller omdefinere eksisterende for at opnå specifikke effekter. Men måske har denne frihed og fleksibilitet en pris, fordi det indhold, der skabes af de utallige interaktioner mellem alle disse LaTeX-pakker og makroer, “på en eller anden måde” skal orkestreres, hvis LaTeX automatisk skal generere korrekt tagget og tilgængeligt PDF-output. I praksis udgør den udvidelsesmulighed, styrke, alsidighed og den dokumentationsmæssige “frihed”, som LaTeX giver, tekniske udfordringer for en gnidningsfri og transparent (“automatisk”) produktion af fuldt tilgængelige taggede PDF-dokumenter, der overholder PDF/UA- eller PDF/A-{1|2|3}a-standarderne. Det bredere TeX- og LaTeX-fællesskab arbejder hårdt på at tackle disse udfordringer, og The TeX User Group (TUG) koordinerer forsknings- og udviklingsindsatsen gennem arbejdsgruppen for PDF-tilgængelighed og PDF-standarder [arbejdsgruppe](https://www.tug.org/twg/accessibility/). Der findes en [diskussionsliste](https://tug.org/mailman/listinfo/accessibility) som giver interesserede parter mulighed for at diskutere produktionen af taggede PDF-filer ved hjælp af TeX og LaTeX. I disse diskussioner er det værd at huske, at LaTeX faktisk ikke er et eksekverbart typograferingsprogram; det er en stor samling af sofistikerede makroer (kommandoer) skrevet i et lavere niveau-sprog kaldet TeX. Mellem dit omhyggeligt udarbejdede LaTeX-dokument og den endelige typograferede PDF står et stykke software kaldet en TeX-motor, hvis opgave er at “udføre” samlingen af LaTeX-kommandoer (dvs. makroer), der bruges til at skrive og konstruere dit dokument—og omdanne dem til den typograferede repræsentation af dit dokument gemt som en PDF-fil. De, der er nye i TeX/LaTeX-økosystemet, bliver ofte, og forståeligt nok, forvirrede af den overflod af kryptisk klingende navne, der bruges om de værktøjer, de møder: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX og LuaLaTeX. Hvis du føler det samme, er hjælpen nær i Overleaf-artiklen [Hvad ligger der i et navn: En guide til TeXs mange varianter](/latex/da/dybtgaende-artikler/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) som forklarer oprindelsen og betydningen af alle disse termer. TeX-motorer såsom pdfTeX, XeTeX eller LuaTeX er en klasse software kaldet *dokumentkompilatorer*: de tager din LaTeX-kode og kompilerer den til dens typograferede form ved at “konvertere” LaTeX-makroer (kommandoer) tilbage til deres instruktioner på det lavere TeX-sprogniveau, som “udføres” for at producere det typograferede resultat. TeX-baserede typograferingssystemer er i stand til at producere exceptionelt komplekst indhold—herunder avanceret matematik, nodeskrift, kemiske strukturer, grafik og sofistikeret flersproget typograferet tekst. For at sikre, at disse komplekse dokumenter overholder tilgængelighedsstandarder og -regler, skal TeX-motorer sammen med LaTeX-makrosamlingen og LaTeX-pakker generere passende taggede PDF-filer ved at indlejre en stor mængde yderligere data i de PDF-filer, de genererer. Selv om TeX-motorer kan generere ekstremt komplekse PDF-filer, har deres interne processer, algoritmer og funktioner ikke *indbygget* funktioner *specifikt designet* til at understøtte produktionen af taggede og tilgængelige PDF'er. I stedet må understøttelse af tagging og tilgængelighed opnås gennem kompleks makroprogrammering, som “indsprøjter” yderligere data i de PDF'er, der genereres af TeX-motorer—og skaber de markerede indholdssekvenser, strukturelementer og datastrukturer for den logiske struktur, der er gemt i `StructTreeRoot`. ### Forfatternes behov For de fleste mennesker er LaTeX blot et værktøj, der lader dig skabe smukt typograferede dokumenter med frihed til at vælge og vrage mellem pakker for at hjælpe dig med at opnå det. Langt de fleste LaTeX-forfattere ønsker simpelthen, at deres dokumenter “virker”: at de typograferes uden fejl, så de kan indsende deres speciale, artikel, rapport eller færdiggøre den længe ventede bog. Ikke urimeligt forventer LaTeX-brugere, at deres valgte samling af LaTeX-pakker sameksisterer fredeligt, gnidningsløst og gennemsigtigt interopererer for at levere de kommandoer og funktioner, der er nødvendige for at producere deres dokumenter. De samme ønsker vil sandsynligvis også gøre sig gældende, når man står over for kravet om at producere tagget PDF fra LaTeX: det skal bare “virke”, gennemsigtigt og med minimal forfatterindgriben. Desværre er vi et stykke fra oplevelsen af “Hey Presto! tagging sker bare, uanset hvilket mærkeligt rod jeg laver”. At koble de tekniske krav til tilgængelighed plus tagget PDF sammen med LaTeX og forfatterfrihed er i sagens natur komplekst, og måske er en form for “forfatterdisciplin” uundgåelig, hvis de tekniske udfordringer skal kunne omsættes til praktisk implementering og løsning. Et separat, men beslægtet problem er, at forkert tagging måske ikke har nogen visuel effekt på den endelige PDF: visuelt kan den se perfekt ud, og den vil sandsynligvis også udskrives uden problemer, men uden at forfatteren ved det kan tagningen være “ødelagt” og først blive opdaget gennem efterfølgende fejl i PDF/A-overensstemmelses-/valideringstjek og/eller yderligere praktisk test via tilgængelighedssoftware såsom skærmlæsere. ### PDF-filer produceret i Overleaf Overleaf giver sit brugerfællesskab en browserbaseret LaTeX-editor sammen med projekt- og dokumenthåndteringsværktøjer, som letter kollaborativ forfatterskab—alt sammen bygget oven på en standard TeX Live-installation. I praksis giver Overleaf brugerne mulighed for at “køre LaTeX på afstand” via en webbrowser, hvilket giver et lag af beskyttelse mod kompleksiteten ved at administrere og vedligeholde et komplet TeX Live-system. En konsekvens af Overleafs brug af en standard TeX/LaTeX-installation er, at PDF'er produceret ud fra LaTeX-kode skrevet i Overleafs editor oprettes ved hjælp af nøjagtig de samme teknologier, som findes i enhver anden TeX Live-installation i samme version—inklusive opsætninger, som brugerne har installeret på deres lokale enheder. Den eneste forskel er, at de TeX-motorer, som kompilerer og behandler Overleafs LaTeX-kode, kører på eksterne servere, ikke på lokale maskiner. Overleaf lineariserer godt nok den TeX-genererede PDF for effektiv download/visning i en browser, men den proces er ikke relateret til selve PDF-indholdets tilgængelighed. Produktion af tilgængelige PDF'er via Overleaf er afhængig af de muligheder og funktioner, der er indbygget i standard TeX-motorer, sammen med tilgængeligheden af passende LaTeX-makropakker, som brugerne kan anvende som en del af deres dokument. LaTeX-dokumenter oprettet ved hjælp af Overleaf skal forblive kompatible med andre TeX- og LaTeX-installationer, fordi brugere ofte har behov for at eksportere deres LaTeX-projekt fra Overleaf til indsendelse til et bredt udvalg af forlagssystemer til tidsskrifter. Hvis man indfører Overleaf-specifikke funktioner i dets LaTeX-dokumenter eller de underliggende TeX-motorer, ville det alvorligt begrænse brugernes frihed til at bruge deres arbejde andre steder. Overleaf anerkender og understøtter behovet for fuldt tilgængelige PDF'er genereret fra TeX/LaTeX-forfattersystemer: vi investerer tid i at forske i tilgængelighedsproblemer, udforske de seneste udviklinger i TeX-motorer og eksperimentelle LaTeX-pakker, som understøtter tagget PDF. I sidste ende, på tidspunktet for skrivningen, findes der ingen “ud af boksen”-løsning, som LaTeX-forfattere kan bruge (via `\usepackage`) til gnidningsløst og gennemsigtigt at generere fuldt tilgængelige og PDF/UA-kompatible PDF'er fra generiske LaTeX-dokumenter. Når disse løsninger bliver tilgængelige gennem TeX Live-opdateringer, vil de selvfølgelig blive tilgængelige for Overleafs brugerfællesskab. ### Nogle LaTeX-pakker til at udforske tagging og tilgængelighed For mange mennesker, [tex.stackexchage](https://tex.stackexchange.com/) er det første sted at søge hjælp til TeX, LaTeX eller ConTeXt. Det er en fantastisk ressource og har mange spørgsmål om emnet [tilgængelighed](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) og produktionen af tilgængelige PDF'er via LaTeX. Hvis du læser og gennemser disse spørgsmål og den efterfølgende strøm af svar og kommentarer, er kun én konklusion uundgåelig: på nuværende tidspunkt findes der ingen fuldstændig, produktionsklar løsning til automatisk at skabe fuldt tilgængelige, standardkompatible, taggede PDF'er fra enhver type LaTeX-dokument. Der er dog nogle pakker, som understøtter tagging—omend måske inden for et begrænset sæt anvendelsesscenarier og dokumenttyper. Følgende liste gives til læsere, der ønsker at udforske LaTeX-baseret PDF-tagging: * [`tagpdf` pakken](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): yderst kapabel pakke designet til eksperimenter med PDF-tagging. Understøtter pdfTeX og LuaTeX og giver yderst nyttig og interessant dokumentation, som indeholder nogle fremragende noter om de tekniske udfordringer ved at skabe taggede PDF'er via TeX-motorer; den anbefales varmt til alle, der er interesserede i bedre at forstå de involverede problemer. Den fremtidige retning vil sandsynligvis være LuaTeX. * [`axessibility` pakken](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov og University of Turin): giver adgang til formler i PDF-filer via hjælpeteknologier. * [`tilgængelighed` pakken](https://ctan.org/pkg/accessibility) (Andy Clifton): opretter taggede og strukturerede PDF-filer. CTAN-noterne angiver, at denne pakke er “Målrettet brugere af KOMA-Script-dokumentklasserne”. * [`accsupp` pakken](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): eksperimentel pakke, der giver bedre understøttelse af tilgængelighed for PDF-filer. En yderligere bemærkelsesværdig reference er en artikel fra 2018 [Implementering af PDF-standarder til matematisk publicering](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) af Dr. Ross Moore fra Department of Mathematics, Macquarie University. I den artikel giver Dr. Moore en kort oversigt over udfordringerne ved tagging af PDF'er i LaTeX: > “Hovedkilden til vanskeligheder ligger i den måde, hvorpå forskellige miljøer kan interagere med hinanden. Der er mange situationer i LaTeX, hvor et miljø eller en struktur ikke rigtig er afsluttet, før det næste er begyndt. Så det handler ikke bare om at sætte start- og slut-tags omkring hvert stykke leveret indhold. I stedet er man nødt til at forstå de finere nuancer i, hvordan forskellige miljøer og andre strukturer faktisk starter og slutter inden for den kontekst, der er etableret af det omkringliggende materiale.” Dr. Moore er også den nuværende vedligeholder af [`pdfx`](https://ctan.org/pkg/pdfx) pakken og ekspert og pioner inden for tagget PDF ved hjælp af TeX/LaTeX. Hans arbejde er bestemt værd at søge efter—herunder denne video på YouTube, som giver interessante indsigter: {% embed url="" %} #### Bemærkning om pdfx-pakken Den [`pdfx`](https://ctan.org/pkg/pdfx) pakken (Ross Moore et al.) giver fremragende understøttelse af PDF/A-1|2|3b (arkivering) og andre muligheder, men producerer endnu 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/da/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.