> 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/cs/dalsi-temata/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Úvod do tagovaných PDF souborů: interní fungování a výzvy přístupnosti ## Aktualizace: leden 2026 Vizte prosím [pokyny Overleafu k vytváření tagovaných PDF](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Ta [tým LaTeXu](https://latex-project.org/) vydal nové funkce, které umožňují automatické tagování PDF, což je klíčový požadavek pro přístupnost PDF. Tyto nové funkce jsou v Overleafu k dispozici v [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), přičemž novější aktualizace jsou k dispozici v průběžné verzi TeX Live dostupné prostřednictvím [Overleaf Labs](https://www.overleaf.com/labs/participate). Nyní je možné vytvořit tagované PDF ze zdrojového kódu LaTeX, které odpovídá WCAG 2.1 úrovně AA, podle [naší uživatelské dokumentace](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) pomocí vydání TeX Live dostupných v Overleafu. Níže uvedený článek z roku 2020, i když nebyl aktualizován o nejnovější informace o přístupnosti v LaTeXu, lze nadále číst pro zajímavost a jako podkladové informace o tagování PDF. *** ## Co tento článek pokrývá? Účelem tohoto článku je poskytnout úvod do tagovaného PDF spolu s přehledem některých technických výzev, kterým čelí software, včetně TeX enginů a LaTeXu, který má za cíl vytvářet tagované a přístupné soubory PDF. Přístupnost, zejména u PDF, je široké a složité téma, které má také technické výzvy, jež nemají vždy jediné, všeobecně dohodnuté nebo uznávané řešení — například jak v PDF přístupně reprezentovat složitou matematiku: pomocí MathML, nebo kódu LaTeXu? Ačkoli se nemůžeme ponořit do hloubky do každého tématu a musíme mnoho detailů zjednodušit, můžeme se podívat dovnitř PDF a ukázat, co tagování PDF ve skutečnosti obnáší. Overleaf doufá, že tento článek poslouží jako užitečný úvod, poskytne dostatek podkladů k tomu, aby čtenáři lépe porozuměli technickým výzvám, a podpoří jejich další četbu a zkoumání tagovaného PDF a přístupnosti. Zdroje v tomto článku zahrnují: * [8minutové video](#video-showing-the-logical-structure-of-a-tagged-pdf) zkoumající tagované PDF vytvořené pomocí LaTeXu; * [projekt Overleafu](#using-luatex-an-example-in-the-overleaf-gallery) pro zkoumání použití mezer v LuaTeXu; * [zvukové nahrávky](#tagged-yes-but-the-reading-order-is-incorrect) demonstrující problémy s přístupností PDF. ## Úvod Zajištění přístupnosti digitálního obsahu je právem uznáváno jako důležitý aspekt tvorby a šíření obsahu. Kromě toho vlády, včetně [Spojeného království](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) a [Spojených států](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), přijímají zákony, které vyžadují, aby obsah vytvořený v jejich jurisdikci splňoval definovaná kritéria přístupnosti. Dodržování při šíření obsahu v HTML není nepřiměřeně obtížné, ale zajištění požadované úrovně přístupnosti dokumentů distribuovaných ve formátu PDF může být značnou technickou výzvou — v závislosti na softwaru použitém k vytváření obsahu určeného pro výstup jako soubor PDF. PDF se objevilo počátkem 90. let jako řešení problémů spojených se spolehlivým přenosem dokumentů a historie ukázala, že bylo mimořádně úspěšné. PDF je však také složitý formát souboru, který vznikl dříve, než bylo široce uznáno a přijato, že je třeba usnadnit přístupnost obsahu dokumentů. Přesto se specifikace PDF v průběhu času vyvíjela tak, aby poskytovala funkce umožňující a podporující vytváření přístupných dokumentů PDF pomocí „stylizované“ varianty PDF, kterou Adobe nazývá *tagované PDF*. V praxi klade tvorba tagovaných—*a plně přístupných*—souborů PDF značné dodatečné technické nároky na software, který PDF vytváří — a to zahrnuje enginy TeX a ekosystém maker a doplňkových balíčků LaTeX. ## Zrod PDF jako finálního digitálního papíru Ta [zrození formátu Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) pochází z doby, kdy byl přenos dokumentů mezi počítači plný potíží, často způsobených převody souborů vedoucími k přelámání stránek a dalším nesrovnalostem, jež ještě zhoršovaly nekompatibilní písma a textová kódování používaná na různých operačních systémech (zejména Windows a Macintosh). Autor tohoto dokumentu tehdy pracoval v oblasti nakladatelství a má živé vzpomínky na řešení těchto výzev! PDF bylo navrženo tak, aby řešilo problémy se sdílením souborů zavedením univerzálního digitálního papíru v konečné podobě (neupravitelného), který umožňuje bezproblémový přenos samostatných dokumentů, jež nesly písma potřebná k jejich zobrazení. Uživatelé mohli konečně přenášet nejrůznější dokumenty s přiměřenou jistotou, že je příjemci bez ohledu na počítačovou platformu dokážou otevřít a přečíst — věrnost dokumentu byla zachována a o nepříjemném přelámání stránek i kompatibilitě/dostupnosti písem bylo rozhodnuto jako o věci minulosti. ### Digitální papír: dobrý pro všechny uživatele? Původ PDF jako formy digitálního papíru přirozeně předpokládal používání tištěných čísel stránek, typografie nebo designových prvků jako vodítek pro vizuální navigaci jeho obsahem — na obrazovce nebo na papíře. Tato vizuální vodítka/mechanismy jsou však samozřejmě pro lidi s těžkým zrakovým postižením bezvýznamná. Dnes je zlepšování přístupnosti digitálního obsahu právem uznáváno jako důležitý aspekt tvorby a šíření obsahu. Výzvou pro PDF bylo poskytnout mechanismy, které usnadňují nevizuální přístup k obsahu uzavřenému v „kontejneru“, původně navrženém tak, aby napodoboval vizuální médium tištěné stránky. První verze specifikace PDF (PDF 1.0) byla [oficiálně vydána 15. června 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) následovaná novými verzemi s aktualizacemi, které v roce 2001 (PDF 1.4) zahrnovaly zavedení „tagovaného PDF“, které [„...umožnilo uživatelům asistenčních technologií“](https://www.adobe.com/accessibility/pdf.html). Následná vydání specifikace PDF rozšířila a vylepšila funkce PDF, což vyústilo v nejnovější vydání (PDF 2.0), které podle [zpráv](https://www.pdfa.org/tagged-pdf-2-0/)zásadně přepracovalo funkce přístupnosti — ačkoli PDF 2.0 zatím není nástroji TeX příliš podporováno. ## Obsah uvnitř PDF Abychom si uvědomili související problémy, stojí za to prozkoumat, jak soubory PDF ve skutečnosti představují obsah stránek, které obsahují. Hluboko uvnitř souboru PDF spočívá obsah každé stránky v jejím *proudu obsahu*: posloupnosti operátorů PDF („příkazů“), které umísťují text nebo grafiku na konkrétní místo na stránce pro vykreslení (zobrazení) softwarem používaným k *prohlížení* PDF. Ve skutečnosti proud obsahu poskytuje grafický popis nebo „recept“, který aplikacím pro zobrazování PDF říká, jak mají každou stránku „nakreslit“ — definuje, co má být na stránce zobrazeno a kde. Tato posloupnost operátorů samozřejmě zahrnuje pokyny k výběru konkrétních písem v určité velikosti, volbě barev, definování šířky čar, kreslení čar, křivek a podobně — vše potřebné k poskytnutí úplného grafického popisu pro vizuální prezentaci stránky. Aby se zmenšila velikost souboru, proudy obsahu PDF se komprimují a ukládají v kompaktním binárním formátu, ale pokud máte k dispozici vhodný software, například Adobe Acrobat Pro DC, můžete jej použít k zobrazení „dekomprimované“ textové verze proudů obsahu stránek. Pojďme se podívat, jak by operátory PDF mohly „nakreslit“ tabulku: proud obsahu PDF by obsahoval odpovídající posloupnost operátorů pro vytvoření vodorovných/svislých čar, výběr různých písem a výstup textu umístěného na různých místech stránky, čímž by se vytvořil obsah tabulky. Abychom to demonstrovali, uvažujme velmi jednoduchý netagovaný dokument PDF, který neobsahuje nic víc než základní tabulku s nějakým textem — vytvořenou v Microsoft Wordu z důvodů, které se objasní později v článku. Zde je snímek obrazovky zobrazující naše jednoduché PDF: ![Tabulka vytvořená v Microsoft Wordu](/files/1cc125854663a822b4f281c5011b32d1e2c8a21b) Pokud extrahujeme (dekomprimovaný) proud obsahu stránky pro tento soubor a vložíme prvních několik řádků do textového editoru, můžeme shrnout některé operátory PDF a získat „pocit“ toho, jak soubory PDF „popisují“ obsah zobrazený na této stránce. ![Obrázek proudu obsahu v souboru PDF](/files/053a9bc2ce3b2d954bcd25ce13ebe33aaa737141) Pokud máte přístup k Adobe Acrobat Pro DC, můžete jej použít k vypsání operátorů obsažených v proudu obsahu stránky PDF. Zde je Acrobatův *interní struktura PDF* pohled na stejné PDF, který užitečně poskytuje jednořádkový popis každého operátoru použitého k „nakreslení“ naší jediné stránky obsahující základní tabulku — všimněte si, že tyto krátké popisy poskytuje Adobe Acrobat Pro DC, nejsou *ne* přítomny v samotném souboru PDF: ![Obrázek proudu obsahu PDF zobrazeného v Adobe Acrobat Pro DC](/files/71dae6e9954abaf3eb4d3879581a8f2066a03562) Všimněte si však, že žádný z těchto pokynů k vykreslování (operátorů) neukládá žádný „význam“ ani „popis“ toho, co vlastně vytvářejí: jsou to jen operátory grafiky, jejichž výsledkem je konstrukce toho, co *vidící pozorovatel rozpozná* jako tabulku. Je zjevné, že pro osoby s těžkým zrakovým postižením není zobrazení tabulky vzniklé z těchto grafických operátorů v proudu obsahu PDF použitelnou metodou přístupu k tomuto obsahu. Potřebný je mechanismus, aby soubory PDF obsahovaly vhodný nevizuální (strojově čitelný) popis této tabulky — a samozřejmě veškerého dalšího obsahu obsaženého na stránkách uvnitř souboru PDF. Aby soubory PDF umožnily nevizuální přístup k obsahu, musí obsahovat další data, která připojují „význam“ nebo sémantiku ke sbírkám či skupinám operátorů používaných k „nakreslení“ určité části obsahu. Tento princip přiřazování či poskytování „významu“ se musí nutně rozšířit na všechny formy obsahu obsažené v PDF: tento mechanismus existuje a nazývá se *tagování* PDF tak, aby vznikla „varianta“ PDF, která se kupodivu nazývá *tagované PDF*. ## Úvod do tagovaného PDF Tagované PDF je název pro specifický typ souboru PDF, který obsahuje dodatečná data (a datové struktury), jež nejsou přítomna v netagovaných souborech PDF. Ačkoli lze zásady/ideje za tagovaným PDF stručně popsat, úplné podrobnosti jsou složité a zabírají mnoho stran ve formální specifikaci PDF. Adobe navrhla tagované PDF tak, aby dosáhlo řady cílů, mezi něž patřilo zpřístupnění obsahu uživatelům se zrakovým postižením, ale zahrnuje také následující seznam převzatý z oddílu 10.7 [specifikace PDF 1.7 od Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * jednoduchá extrakce textu a grafiky pro vložení do jiných aplikací; * automatické přelévání textu a související grafiky, aby se vešly na stránku jiné velikosti, než s jakou se počítalo při původním rozvržení; * zpracování textu pro účely, jako je vyhledávání, indexování a kontrola pravopisu; * převod do dalších běžných formátů souborů (například HTML, XML a RTF) se zachováním struktury dokumentu a základních informací o stylování. Kromě toho tagované PDF také vyžaduje: * aby byl text v obsahu PDF reprezentován ve formě, kterou lze převést do Unicode; * zlomy slov musí být výslovně reprezentovány — všimněte si, že enginy TeX nepoužívají k oddělování slov mezery, používají flexibilní mezery TeXu nazývané glue (viz níže); * skutečný („reálný“) obsah je odlišen od artefaktů rozvržení a stránkování. Pod tagovaným PDF stojí dva klíčové koncepty, které si projdeme: * definice logické struktury obsahu v souboru PDF; * označování obsahu PDF sadou standardních typů obsahu. ## Logická struktura V delších dokumentech je obsah obvykle rozdělen do posloupnosti menších obsahových položek; například knihy jsou typicky členěny na kapitoly, které jsou samy rozděleny na sekce a podsekce obsahující odstavce, tabulky, obrázky/grafy, odrážkové nebo číslované seznamy, poznámky pod čarou a odkazy a tak dále. Struktura a uspořádání obsahu v takové knize nebo jakémkoli jiném typu dokumentu se označuje jako jeho *logická struktura*. Pojem logické struktury dokumentu hraje důležitou roli v přístupnosti PDF, ale jako koncept se logická struktura může zdát trochu vágní a obtížně pochopitelná. Následující definice z [Encyklopedie databázových systémů](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) poskytuje užitečný vhled: > „Logická struktura odkazuje na způsob, jakým jsou informace v dokumentu uspořádány; definuje hierarchii informací a vztah mezi různými částmi dokumentu. Logická struktura ukazuje, jak je dokument sestaven, na rozdíl od toho, co dokument obsahuje.“ Všimněte si, že tato definice logické struktury se přesně neodkazuje na *jak* to, kde je strukturální informace fyzicky uložena; pouze na to, že poskytuje reprezentaci struktury a uspořádání dokumentu. Přesné podrobnosti o tom, jak je logická struktura dokumentu uložena nebo reprezentována, závisí na implementaci: jsou funkcí softwaru použitého k jejímu generování a zpracování. ### Logická struktura v PDF Specifikace PDF poskytuje mechanismy, jejichž prostřednictvím lze logickou strukturu dokumentu zaznamenat uvnitř souboru PDF — pro použití softwarem, který by například mohl chtít exportovat obsah PDF do jiných formátů, jako jsou XML, HTML nebo Microsoft Word. Tyto exportní procesy musí vytvořit správně strukturovaný textový dokument, který odpovídá pravidlům cílového formátu exportního souboru — čehož lze nejlépe dosáhnout, když je exportní zpracování řízeno informacemi o logické struktuře poskytnutými v PDF. Kromě toho je logická struktura souboru PDF zásadní pro software pro přístupnost, který by například mohl chtít provádět převod textu na řeč a číst obsah nahlas někomu se zrakovým postižením. Proces převodu textu na řeč musí zajistit, že obsah bude čten nahlas ve správném pořadí/sekvenci, jinak by výsledky nedávaly smysl. Všimněte si také, že samotný pojem stránky nemusí mít pro aplikace pro přístupnost, které se zajímají pouze o obsah a strukturu dokumentu v PDF, nikoli o vizuální rozdělení a prezentaci do úseků o velikosti stránky, žádný smysluplný význam. #### Označování obsahových položek Zaznamenání (uložení) logické struktury dokumentu PDF vyžaduje určitou sadu smysluplných názvů přiřazených různým *typům* obsahových položek, které se pravděpodobně vyskytují jako součást typického dokumentu PDF — identifikující části obsahu představující nadpisy, odstavce, tabulky, seznamy a tak dále. Kromě toho mají některé obsahové položky, jako je obsah, číslované/odrážkové seznamy a tabulkové materiály, vlastní poměrně složité struktury, takže jsou zapotřebí také určitá vodítka/pravidla určující, jak jsou tyto složitější obsahové položky sestaveny — jejich podstruktura. Dalším požadavkem je jasně identifikovat jakýkoli obsah PDF, který by měl být při zpracování PDF asistenčním softwarem ignorován; například záhlaví a zápatí stránek jsou artefakty stránkování obsahující text, který je pro osoby s těžkým zrakovým postižením nadbytečný: tento obsah by měl být ignorován. Mechanismy, které PDF používá k definování logické struktury dokumentu, jsou navrženy tak, aby byly flexibilní, takže v zásadě by různé aplikace, které generují a zpracovávají soubory PDF, mohly používat názvy pro typy obsahu podle libovolné konvence, kterou si zvolí. Aby se však maximalizovala výměna dokumentů a umožnilo různým aplikacím pro zpracování PDF poskytovat konzistentní výsledky, Adobe definovala sadu standardních názvů pro typy obsahových položek, které by software pro generování PDF měl dodržovat. Ve specifikaci PDF jsou tyto standardní názvy označovány jako tagy, z čehož vyplývá pojem *tagované* PDF. ### Označování obsahu PDF: pohled „pod kapotu“ Abychom diskusi trochu méně abstrahovali, stručně se podíváme na vnitřní fungování tagovaných souborů PDF — ačkoli nemůžeme pokrýt všechny podrobnosti, protože tagované PDF je tak rozsáhlé, složité téma. #### Sekvence označeného obsahu: stavební bloky tagovaného PDF Na nejnižší úrovni začíná proces zaznamenávání významu obsahu obsaženého na stránce PDF (tj. v jejím proudu obsahu) u *sekvencí označeného obsahu* které se používají k identifikaci (dání „významu“) shluků nebo skupin operátorů PDF. Sekvencím označeného obsahu je přiřazen číselný identifikátor nazývaný její `MCID` (*identifikátor označeného obsahu*) což je celé číslo, které na každé stránce běží od 0 do nějakého maxima N. Tyto `MCID` hodnoty poskytují způsob, jak jednoznačně identifikovat sekvence operátorů obsažené v proudu obsahu konkrétní stránky. Pro upřesnění, pro každou stránku `MCID` identifikátory začínají na 0 a postupně rostou až do určité maximální hodnoty, která závisí na tom, kolik sekvencí označeného obsahu je obsaženo v proudu obsahu dané stránky. Sekvence označeného obsahu jsou ve skutečnosti základní „stavební bloky“, které se používají k sestavení vyšších datových struktur nazývaných *strukturální prvky*. Tyto strukturální prvky obsahují tag, což je název používaný k identifikaci typu obsahové položky, kterou představují. #### Příklad strukturálních prvků Zde trochu předbíháme, ale stojí za to projít si příklad. Předpokládejme, že máte 3 malé textové úryvky obsahu stránky a každý z nich je v proudu obsahu identifikován jinou sekvencí označeného obsahu. Každý z těchto 3 textových úryvků lze zabalit do vlastního strukturálního prvku s tagem a všechny tři lze „propojit“ pomocí dalšího strukturálního prvku, aby představovaly obsahovou položku vyšší úrovně, například řádek v obsahu. ![Obrázek vysvětlující strukturální prvky a sekvence označeného obsahu](/files/ad7db011e89d49ca7aeb34f24f29c03fc071cc63) Pomocí formy vztahu dat rodič–dítě se kolekce strukturálních prvků spojují a vytvářejí propojené datové struktury, které představují složitější datové položky, jako jsou číslované a odrážkové seznamy, tabulky, matematika a tak dále. Nakonec je celá kolekce strukturálních prvků obsažených v celém souboru PDF dále propojena a spojena tak, aby vytvořila logickou strukturu dokumentu PDF — k tomu se vrátíme později v článku. ### Co je sekvence označeného obsahu? V diskusi výše jsme použili jednoduchý netagovaný dokument PDF obsahující tabulku (vytvořenou v Microsoft Wordu), ale pokud nařídíme Wordu vytvořit tagované PDF, můžeme vidět, že se v proudu obsahu stránky objevilo další značení. Zde uvažujeme pouze prvních několik řádků proudu obsahu (je jich tam stovky), ale všimněte si přítomnosti dalších operátorů, jako jsou `/P <> BDC` a `EMC` které se používají k identifikaci sekvence označeného obsahu. Nebudeme prozkoumávat úplnou syntaxi sekvencí označeného obsahu, ale čtenáře odkazujeme na stranu 862 [oficiální specifikace PDF 1.7 od Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Obrázek zobrazující sekvence označeného obsahu v proudu obsahu tagovaného PDF](/files/87311333c9595d8d123baa066896954d930fbf27) Pro snadnou orientaci znovu uvádíme netagovanou verzi: ![Obrázek zobrazující proud obsahu PDF](/files/053a9bc2ce3b2d954bcd25ce13ebe33aaa737141) V *netagovaného* PDF, operátory jako `/P <> BDC` a `EMC` chybějí, ale zbývající operátory jsou beze změny: netagované PDF postrádá dodatečné značkování používané k identifikaci určitých sekvencí/souborů operátorů. Opět můžeme také použít funkci Adobe Acrobatu *interní struktura PDF* k zobrazení sekvencí označeného obsahu uvnitř proudu obsahu — zde jsme je zvýraznili zeleným rámečkem: ![Obrázek zobrazující sekvence označeného obsahu v proudu obsahu tagovaného PDF zobrazeného v Adobe Acrobat Pro DC](/files/e3aa35ced45151da9f2ae13c676ff41fa9fcbd12) Všimněte si, že některé části obsahu jsou označeny `/Artifact` který identifikuje materiál na stránce PDF, který by měl být *ignorován* softwarem pro přístupnost, například takovým, který předčítá nahlas lidem se zrakovým postižením. Následující snímek obrazovky ukazuje rozšířený pohled na první sekvenci označeného obsahu — tu s `MCID` hodnotou `0`. Konec sekvence označeného obsahu je identifikován operátorem PDF `EMC`. ![Obrázek zobrazující podrobnosti o operátorech zahrnutých do proudu označeného obsahu](/files/b8e65357a4f18c1917deedaed37a8a839cec76a8) ### Uložení logické struktury Jak bylo uvedeno, kromě poskytnutí popisu jednotlivých obsahových položek (odstavce, seznamy, tabulky atd.) je pro přístupné PDF nezbytné, aby obsahovala reprezentaci celého dokumentu ve formě jeho logické struktury. Jednotlivé části přístupného obsahu musí být propojeny, aby vytvořily úplný, navigovatelný a přístupný dokument — podobně jako je z jednotlivých odstavců, grafik, tabulek sestaven jediný dokument HTML, aby vytvořil webovou stránku. Kromě toho je zásadní, aby logická struktura dokumentu PDF zajišťovala, že veškerý obsah lze procházet ve správném *pořadí čtení*, nezávisle na pořadí, v jakém byl obsah stránky zapsán do proudů obsahu stránky PDF. Pořadí čtení prozkoumáme podrobněji níže. #### Logická struktura: „strom“ strukturálních prvků Uvedli jsme, že PDF používají něco nazvaného *strukturální prvek* k reprezentaci jednotlivých obsahových položek a že strukturální prvek obsahuje tag pro identifikaci typu obsahu, který představuje. Aby bylo možné vytvořit reprezentaci logické struktury dokumentu, jsou všechny strukturální prvky propojeny pomocí vztahů rodič–dítě a uspořádány do „stromu struktury“. Interně obsahují tagované soubory PDF objekt nazvaný `StructTreeRoot` , který obsahuje (odkazuje na) strukturální prvky, jež slouží jako výchozí bod nebo „kořen“ stromu logické struktury dokumentu. Obvykle „kořen“ stromu struktury začíná jediným strukturálním prvkem označeným tagem `Document` který obsahuje četné *dceřiné* strukturální prvky, jež společně představují veškerý obsah dokumentu. Jakýkoli software určený k vytváření přístupných PDF prostřednictvím tagování musí sestavit tuto velmi složitou datovou strukturu (a další!) — a to zahrnuje enginy TeX a LaTeX. Příklad takového stromu struktury dokumentu (`StructTreeRoot`) je zobrazen na následujícím snímku obrazovky tagovaného PDF otevřeného v Adobe Acrobat Pro DC: ![Obrázek zobrazující StructTreeRoot v tagovaném PDF](/files/20a1c0ce4f71f60f96688ae7274d8781164b5d71) Porovnejte výše uvedenou strukturu s verzí netagovaného PDF: ![Obrázek zobrazující absenci StructTreeRoot v netagovaném PDF](/files/b23dbc8f44ecd9c8575296b4b698875fab762be0) ### Zkoumání logické struktury PDF Začneme několika grafikami, které shrnou to, co jsme probrali, a zakončíme videem, které pomocí Adobe Acrobat Pro DC ukazuje více podrobností o logické struktuře tagovaného souboru PDF. Nejprve začneme schématem, které ukazuje obecné zásady: stránka PDF s proudem obsahu opatřeným značkovanými sekvencemi obsahu (MCS). ![Grafika znázorňující koncept sekvencí označeného obsahu na stránkách dokumentu PDF](/files/89737c002060dc65db8ba6dd135d0718d574e47f) Tyto MCS jsou následně spojovány do *strukturální prvky* které tvoří základ pro větší typy obsahu, jež jsou samy dále propojeny, aby uložily logickou strukturu PDF v objektu nazvaném `StructTreeRoot`. ![Grafika znázorňující logickou strukturu tagovaného souboru PDF](/files/70fb5e9bd145c4248c0bbffbb9b97b5cfd534386) #### Video znázorňující logickou strukturu tagovaného PDF Následující video (8 minut) používá Adobe Acrobat Pro DC, aby vás provedlo „komentovanou prohlídkou“ a prozkoumalo podrobnosti logické struktury tagovaného souboru PDF vytvořeného pomocí LaTeXu. Tagovaný soubor PDF použitý ve videu se jmenuje `tagpdf.pdf`, což je výborný příklad obsahující dokumentaci k experimentálnímu balíčku LaTeXu [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Cílem balíčku `tagpdf` je poskytnout „nástroje k experimentování s tagováním a přístupností pomocí pdfLaTeXu a LuaTeXu“. {% embed url="" %} ### Poznámka k tagování a flexibilitě Specifikace HTML poskytuje velké množství předdefinovaných tagů pro použití při vytváření webových stránek, ale také umožňuje flexibilitu v tom, jak je kombinujete při tvorbě zvoleného dokumentu HTML. Podobně specifikace tagovaného PDF od Adobe poskytuje sadu předdefinovaných názvů tagů, ale klade velmi málo omezení na to, jak tyto tagy kombinujete při reprezentaci složitých obsahových položek v PDF — záměrně je zde velká míra flexibility. Kromě toho je u jakékoli specifikace tak rozsáhlé a složité jako PDF nevyhnutelné, že se do psané specifikace vkradou určité nejasnosti nebo problémy s přesností. Vývojáři softwaru, kteří mají za úkol implementovat takto složitou specifikaci, mohou při jejím výkladu muset činit „kvalifikovaná rozhodnutí“, protože čelí převodu psaných popisů do funkčního kódu. Vrozená flexibilita tagovaného PDF spolu s interpretací specifikací (nebo standardů přístupnosti) přirozeně dopadá na vývojáře aplikací pro tvorbu dokumentů: které kombinace tagů by měly být použity k reprezentaci uživatelsky vytvořeného obsahu při jeho výstupu do tagovaného souboru PDF? Když navíc zohledníte neomezenou schopnost uživatelů vytvářet všelijaký obsah využíváním funkcí softwaru pro tvorbu dokumentů, pak je zřejmé, že automatizovaná tvorba přístupných tagovaných PDF je sama o sobě výzvou! Možná jako odraz nevyhnutelných složitostí spojených s tvorbou tagovaných PDF, která plně odpovídají standardům přístupnosti, je web plný návodů, tipů a rad „best practice“ k vytváření tagovaných PDF pomocí softwaru, jako je Adobe InDesign nebo Microsoft Word. Kromě toho PDF Association vytvořila užitečný dokument nazvaný [Průvodce osvědčenými postupy pro tagované PDF](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) napsaný s cílem pomoci vývojářům čelícím výzvám při implementaci tagovaného PDF a PDF/UA. ## Máte PDF, ale je přístupné? Aby bylo možné určit, zda daný soubor PDF odpovídá požadovaným standardům přístupnosti, jako jsou PDF/A nebo PDF/UA (viz níže), musí být *validován* pomocí dohodnutého validačního procesu nebo softwarového nástroje. Validace však obvykle probíhá až po dokončení dokumentu, ale tento proces nemusí provádět autor dokumentu, nýbrž specialisté na přístupnost v organizaci nebo subjektu, který shodu požadoval. Pokud PDF při validaci neuspěje, může být zapotřebí odborný ruční zásah prostřednictvím Adobe Acrobat Pro DC k opravě tagování (pokud je to možné). Alternativně se může dokument dokonce muset vrátit autorovi k úpravě původního dokumentu, případně tak, že se vyhne použití funkcí autorského softwaru, které problémy způsobily — což může být mimořádně obtížné, protože to může být mimo kontrolu autora. ### Pořadí čtení a pořadí obsahu Jak bylo uvedeno, tvorba skutečně přístupných PDF klade na software pro tvorbu dodatečné technické nároky a potenciálně také na autory dokumentů, protože je nutí k „autorské disciplíně“ v tom, jak používají/uplatňují funkce autorského softwaru. Ačkoli tagované PDF je mechanismus, který *umožňuje* tvorbu plně přístupných PDF, samotný fakt, že je PDF tagované, *ne* neznamená automaticky, že je plně přístupné, jak uvidíme v příkladu níže. Aby bylo možné vytvořit plně přístupné PDF, měl by být veškerý obsah v PDF tagován tak, aby vznikla logická struktura zajišťující, že obsah lze přistupovat a číst ve správné sekvenci — nazývané *pořadí čtení*pořadí čtení *pořadí čtení* pořadí: 1. text 2. table 3. grafika Při zápisu do PDF by software generující proud obsahu pro tuto stránku mohl začít operátory pro vykreslení tabulky, poté výstupními operátory pro vytvoření grafiky následovanými operátory pro text, což by v proudu obsahu vytvořilo *pořadí obsahu* pořadí: 1. table 2. grafika 3. text Samozřejmě vše bude při zobrazení této stránky umístěno na správné pozici. Pro plně vidícího čtenáře není pořadí, v jakém jsou tyto položky uloženy v proudu obsahu stránky, nijak důležité: vnímá kompletně vykreslenou stránku se vším na správném místě. Pokud by se však asistenční software musel spoléhat na pořadí položek v proudu obsahu (pořadí obsahu), narazil by na potíže, pokud by pořadí obsahu bylo jiné než přirozené pořadí čtení; například nástroje pro předčítání by četly materiál ve špatném sledu. Naštěstí může asistenční software využít logické pořadí (strukturu) tagovaného PDF, které musí být uspořádáno tak, aby odráželo sled, v němž by měl být obsah čten. Z těchto důvodů jsou data reprezentující logickou strukturu dokumentu ukládána odděleně od skutečného obsahu zobrazeného na viditelných stránkách, aby bylo možné > „... pořadí a vnoření logických obsahových prvků bylo zcela nezávislé na pořadí a umístění grafických objektů na stránkách dokumentu.“ (strana 856 z [Referenční příručka PDF, šesté vydání, listopad 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) V praxi je zaručení logického pořadí, které zachovává pořadí čtení, mnohem náročnější, než by se mohlo zdát, takže použijme jednoduchý, byť vymyšlený, příklad, který naznačí, o jaké problémy jde. #### Nesprávné pořadí čtení: příklad využívající Microsoft Word Autor dokumentu může využít funkce zvoleného autorského softwaru k dosažení konkrétního vizuálního efektu — například použitím tabulek k vytvoření určitého rozvržení textu. Následující snímek obrazovky například ukazuje dokument Microsoft Word použitý v předchozích příkladech. Obsahuje tabulku, která byla použita k vytvoření sady číslovaných odstavců vedle sebe. Ale pokud jde o tagování tohoto obsahu, jak by měl být posuzován: jako tabulka, nebo jako číslovaný seznam? Oba tyto typy obsahu vyžadují složitou tagovací strukturu, aby byly správně reprezentovány. Na následujícím obrázku si všimněte pořadí, v jakém mají být číslované odstavce čteny: po sloupcích, nikoli po řádcích. ![Obrázek tabulky vytvořené v Microsoft Wordu](/files/12233769c544eee17ee14f1c4ebda69797ed1693) Pokud požádáme Word, aby tento dokument uložil do PDF pomocí jeho vestavěného exportu — nikoli zásuvného modulu Acrobat PDFMaker — můžeme mu říct, aby vytvořil tagované PDF: ![Dialogové okno Možnosti procesu exportu v aplikaci Microsoft Word](/files/7f2d5734cc9c630681716dfbeed941d440751206) Jak tedy Word taguje toto rozvržení? V následujícím velmi krátkém videu (14 sekund) používáme Adobe Acrobat Pro DC ke kontrole struktury tagování vytvořené aplikací Microsoft Word. {% embed url="" %} Pro tento dokument vytvořil Word tagovaný dokument PDF, který používá `Tabulka` tag obsahující dva podtagy: `THead` pro skupinu řádků záhlaví tabulky a a `TBody` k reprezentaci skupiny řádků pro tělo tabulky. `THead` a `TBody` oba obsahují `TR` tagy, které reprezentují jednotlivé řádky obsahu. Ty `TR` tagy obsahují další tagy, které reprezentují očíslovanou položku seznamu přítomnou v každé buňce. Následující snímek obrazovky ukazuje hluboce zanořenou strukturu tagování a odpovídajícím způsobem složitou logickou strukturu potřebnou k reprezentaci i tohoto extrémně základního dokumentu! ![Obrázek zobrazující hluboce zanořenou strukturu tagování a logickou strukturu jednoduché tabulky vytvořené v Microsoft Wordu](/files/8f1202b8d6b22265f6a2e05c0045f13d0f15585e) Ve srovnání s PDF generovanými TeXem a LaTeXem je tento příklad z Wordu extrémně jednoduchý dokument, ale přesto k jeho reprezentaci vyžaduje složitou logickou strukturu. Představte si úroveň složitosti tagování potřebnou k reprezentaci PDF generovaných LaTeXem, která obsahují složitou matematiku a tabulky! #### Otagováno ano, ale pořadí čtení je nesprávné I když Word skutečně vytváří [tagované PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) ukazuje jednu ze základních výzev, kterým čelí kterákoli aplikace, jež se snaží vytvářet plně přístupná PDF: správně reprezentovat zamýšlené pořadí čtení obsahu. Při vytváření tagovaného PDF se interní procesy Wordu rozhodly zapsat odpovídající obsahový proud tak, že tabulku vypsaly po řádcích, nikoli po sloupcích. Pro čtenáře s plným zrakem při pohledu na PDF tyto nízkoúrovňové detaily nepředstavují žádný rozdíl: tabulka se zobrazuje správně. Avšak pro zrakově postižené lidi vytváří logická struktura dokumentu Wordu nesprávný výsledek, protože požadované pořadí čtení (po sloupcích) není zachováno: obsah je předčítán v nesprávném pořadí. Následující zvukový záznam byl vytvořen pomocí funkce Adobe Reader DC „Read Out Loud“. Jak je zřejmé, text je předčítán v nesprávném pořadí: po řádcích, nikoli po sloupcích: ![Tabulka vytvořená v Microsoft Wordu](/files/212090401fdac65a596e0dc26000f41103612156) Jak bylo uvedeno výše, tento příklad je poněkud umělý, ale ukazuje, jak snadné je použít kombinace softwarových funkcí, které vyvolají problémy s přístupností — ale jak má autor dokumentu předem vědět, že se to stane? Je pravděpodobné, že by se tento problém odhalil teprve tehdy, pokud by výsledné PDF prošlo praktickými testy použitelnosti z hlediska přístupnosti — např. pomocí asistenčního softwaru. Potenciálně by takové dokumenty mohly projít testy shody/validace PDF/A, ale v „reálném světě“ by selhaly. Zajištění správného pořadí čtení PDF souboru, jako je tento, by vyžadovalo kvalifikovaný ruční zásah pomocí pokročilých nástrojů pro editaci PDF, jako je Adobe Acrobat Pro DC: časově náročný a nákladný proces. Alternativně by se autor dokumentu mohl zdržet použití této konkrétní formy vyjádření obsahu nebo rozvržení — ale pouze pokud by věděl, že je problematická! ### Použití znaků mezery k oddělování slov Když píšete text v textových procesorech nebo editorech, používáte znak mezery k označení konce jednoho slova a začátku dalšího. Pokud z takového dokumentu následně vytvoříte PDF, znaky mezery, které jste napsali, se samozřejmě v PDF výstupu objeví a stanou se součástí textu uloženého v PDF. Avšak TeXové enginy nepoužívají znaky mezery k oddělování slov v sazbě; místo toho převádějí znaky mezery do podoby pružného rozestupu zvaného glue (viz tento [článku Overleafu](/latex/cs/clanky-do-hloubky/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) pro více informací o TeXových boxech a glue). V rámci obsahového proudu stránek PDF vytvořených TeXovými enginy je oddělení jednotlivých slov dosaženo přesunem na jiné místo na stránce a zahájením textu pro další slovo — namísto výstupu znaku mezery k dosažení tohoto rozestupu. Navíc se množství mezery mezi slovy v odstavcích sazovaných TeXovými enginy liší řádek od řádku kvůli TeXovu algoritmu lámaní řádků. Tato variabilita se odráží v pozičních údajích zapsaných do obsahového proudu stránek PDF. Tento aspekt sazby v TeXu má důsledky pro kopírování/vkládání textu z jeho PDF a pro asistenční software, který se snaží nahlas číst sažený text v PDF vytvořených TeXovými enginy. Asistenční software musí analyzovat obsahový proud stránky PDF, aby extrahoval text, který potřebuje zpracovat. Je zřejmé, že takový software potřebuje nějaký mechanismus k určení začátku a konce slov — nejzřejmějším řešením je použít znak mezery. S ohledem na to požadavky na přístupnost vyžadují, aby jednotlivá slova byla jasně ukončena (např. znaky mezery), což je kvůli použití mezislovní glue problematické pro TeXové enginy. #### Ale není vše ztraceno! V roce 2014 zavedl pdfTeX 2 nové primitivy, které zlepšují podporu přístupnosti tím, že umožňují použití znaků mezery mezi slovy v PDF, která vytváří: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Tyto příkazy využívají „falešné písmo“ obsahující pouze glyf mezery. Podrobnosti a příklad lze nalézt na straně 29 v [Uživatelské příručce pdfTeXu](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Použití LuaTeXu: Příklad v galerii Overleaf LuaTeX nepodporuje tyto primitivy pdfTeXu, ale lze jej naprogramovat tak, aby dosahoval výsledků velmi podobných pdfTeXu, a to pomocí takzvaného callbackového mechanismu LuaTeXu. Projekt na Overleafu pro převod glue na znaky mezery je dostupný v galerii Overleaf pod názvem [Použití LuaTeXu k převodu mezislovní glue na mezery a kerny](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Pokud sázíte svůj kód LaTeX pomocí LuaTeXu (tj. volby kompilátoru LuaLaTeX na Overleafu), můžete pomocí kódu Lua po sazbě zpracovat odstavec, vyhledat jakékoli mezislovní glue a nahradit jej znakem mezery plus vhodným kernem. Rozestup daný šířkou znaku mezery lze přičíst (nebo snížit) výpočtem odpovídající hodnoty kernu, aby se zachovalo množství prostoru poskytnutého mezislovní glue, což vede k žádnému vizuálnímu rozdílu ve výsledné sazbě. Abyste pochopili, jaký rozdíl to znamená pro uživatele asistenčního softwaru, poslechněte si tento zvukový záznam pořízený z funkce Adobe Reader DC *Read Out Loud* Tato funkce zaznamenává nahlas předčítané dva řádky textu v tomto projektu před a po převodu glue na mezery. Všimněte si, jak je druhé čtení řádku, které používá mezery, předčítáno rychleji a plynuleji ve srovnání s řádkem používajícím mezislovní glue. Projekt na Overleafu je soubor plain TeX zkompilovaný pomocí LuaTeXu a je poskytován pouze pro experimentální použití; není určen jako úplné řešení v produkční kvalitě. Především je navržen tak, aby pomohl s porozuměním technickým problémům souvisejícím s přístupnými PDF. Kód Lua použitý v tomto projektu vychází z práce obsažené v mnohem starším článku na Overleafu [Boxy a lepidlo: Krátký, ale názorný úvod s využitím LuaTeXu](/latex/cs/clanky-do-hloubky/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Poznámka: Z důvodu jednoduchosti projekt používá svůj vlastní velmi minimalistický načítací modul písem OpenType odvozený z tohoto kódu: . ### Další problémy s přístupností a tagované PDF Ačkoli tagování umožňuje identifikaci obsahových položek přítomných v PDF, některé typy obsahu, jako je grafika nebo složitá matematika, vyžadují k tomu, aby byly přístupné prostřednictvím softwaru určeného k podpoře zrakově postižených lidí, další data nebo informace. Aby byla podpora přístupnosti široké škály typů obsahu zajištěna, specifikace PDF poskytuje možnost připojit k obsahovým položkám „alternativní popisy“ nebo „ActualText“, které poskytují vhodné textové popisy nebo jiné strojově čitelné reprezentace. Například pro tento účel je ve specifikaci PDF 2.0 určen MathML. #### Je to „skutečný obsah“, nebo jen artefakt? Pro zrakově postižené lidi má proces rozdělování a zobrazování obsahu do obdélníkových bloků o velikosti stránky nežádoucí vedlejší účinky, jako je dělení slov. Navíc aspekty návrhu nebo rozvržení stránky používané ke zlepšení vizuálního vzhledu jsou pro ty, kdo je nevidí, zcela bezvýznamné. Z těchto důvodů musí tagování obsahu PDF rozpoznat, že s některým obsahem v PDF by se mělo zacházet jako s *artefakt* vizuální prezentace nebo stránkování. Například čísla stránek, záhlaví a zápatí stránek, stínovaná pozadí nebo jiné designové prvky je třeba identifikovat, aby software pro přístupnost zpracovávající obsah věděl, že je má ignorovat. ## Přehled standardů PDF/A Požadavky na vytváření přístupných PDF obvykle odkazují na normu ISO nazývanou [ISO 19005](https://www.iso.org/standard/38920.html), běžněji označovanou jako PDF/A. Nicméně protože PDF/A je *rodina* soubor norem, samotný požadavek na „shodu s PDF/A“ nemusí plně specifikovat skutečné požadavky. Abyste viděli proč, začněme krátkým přehledem PDF/A z webu [webu PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (přístup 21. května 2020), který popisuje ISO 19005 (PDF/A) takto: > „Hlavním účelem ISO 19005 je definovat formát souboru založený na PDF, známý jako PDF/A, který poskytuje mechanismus pro reprezentaci elektronických dokumentů způsobem, jenž zachovává jejich statický vizuální vzhled v čase, nezávisle na nástrojích a systémech použitých k vytváření, ukládání nebo vykreslování souborů. > > Druhým účelem ISO 19005 je definovat rámec pro reprezentaci logické struktury a dalších sémantických informací elektronických dokumentů v odpovídajících souborech. > > Dalším účelem ISO 19005 je poskytnout rámec pro zaznamenávání kontextu a historie elektronických dokumentů v metadatech v odpovídajících souborech.“ Je zřejmé, že PDF/A má několik základních cílů. ### Vývoj a růst PDF Ta [Specifikace PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) byla publikována v roce 1993 a měla pouze 230 stran. O 13 let později však specifikace pro [verzi PDF 1.7 od Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) má více než 1000 stran! Časem velikost a složitost specifikace PDF rostly přidáváním podporovaných funkcí: zahrnujících nové technologie a požadavky stále sofistikovanějších pracovních postupů a případů použití založených na PDF v různých trzích a komunitách. Je však pravděpodobné, že žádný uživatel ani žádná skupina uživatelů nikdy nevyužije všechny možnosti: PDF musí „pokrýt všechna možná hlediska“, aby dokázalo sloužit potřebám co nejširšího trhu. Například mnoho funkcí PDF určených k podpoře špičkového komerčního tisku není vyžadováno při běžném každodenním kancelářském použití jako formát pro ukládání nebo sdílení dokumentace. ### PDF/A: „zpět k základům“ pro PDF Hlavním cílem PDF/A je zajistit, aby odpovídající PDF byla vhodná pro dlouhodobou archivaci nebo obsahovala obsah, který je přístupný lidem používajícím různé asistenční technologie k „konzumaci“ těchto PDF. K dosažení těchto cílů PDF/A omezuje sadu funkcí PDF povolených v odpovídajících souborech PDF a zakazuje použití funkcí, které by mohly ohrozit archivovatelnost nebo přístupnost. PDF/A si můžete představit jako soubor norem, které specifikují, jak odpovídající soubory PDF používají *podmnožina* část plné specifikace PDF k vytváření souborů vhodných pro dlouhodobou archivaci nebo k zajištění přístupnosti jejich obsahu. Omezení PDF/A umožňují používat PDF jako „archivní digitální papír“, který je nezávislý na technologii pro čtení PDF a výpočetním prostředí používaném k přístupu k jeho obsahu. Odpovídající PDF by neměla obsahovat nic, jehož chování je „závislé na implementaci“ — tj. závislé na konkrétním softwaru nebo operačních systémech použitých k jejich zobrazení nebo zpracování. PDF musí být také *úplná*: klíčové dokumentové zdroje musí být vloženy do souboru — například písma nebo barevné profily. ### Verze PDF/A a úrovně shody Existují různé *verze* verze standardu PDF/A, z nichž každá odráží určitou verzi formální specifikace PDF (PDF 1.4, 1.7 a 2.0). Kromě toho existují různé *úrovně shody* které určují, ke kterému aspektu či aspektům standardu PDF/A soubor PDF splňuje shodu. Proto když tvrdíte nebo vyžadujete „shodu s PDF/A“, měli byste myslet na soubory PDF, které splňují **PDF/A-** Například * PDF/A-1a: znamená verzi PDF/A 1, úroveň shody a * PDF/A-2b: znamená verzi PDF/A 2, úroveň shody b Podíváme se na ně trochu podrobněji. #### Verze PDF/A Standard PDF/A spadá pod záštitu ISO a je publikován jako norma nazývaná ISO 19005. Jak bylo uvedeno, specifikace PDF se v průběhu času vyvíjela a to následně vyžadovalo aktualizace ISO 19005, což vedlo k následující tabulce: | | | | | --------------- | ---------------- | ------------------------- | | **Verze PDF/A** | **Norma ISO** | **Založeno na verzi PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | ISO 32000-1 (PDF 1.7) | V době psaní tohoto textu (duben/květen 2020) je aktualizovaná verze PDF/A-4 (ISO 19005-4) [v přípravě](https://www.iso.org/standard/71832.html). #### Úrovně shody PDF/A Kromě tří verzí PDF/A (PDF/A-1, PDF/A-2 a PDF/A-3) existují tři *úrovně shody*: * Úroveň A (přístupná) pro přístupnost (zahrnuje archivační požadavky úrovně B) * Úroveň B (základní) pro archivaci * Úroveň U (Unicode) (= archivace plus použití Unicode pro text) Zde je krátký popis těchto úrovní shody: * **Úroveň B (základní)** je minimální požadavek pro shodu podle PDF/A. Definuje požadavky, které zajišťují, že odpovídající dokumenty PDF jsou vhodné pro dlouhodobou archivaci — že je lze vždy spolehlivě zobrazit nebo vytisknout nezávisle na konkrétním softwaru, nástrojích nebo operačních systémech. * **Úroveň A (přístupnost)** zahrnuje požadavky shody úrovně B, ale navíc vyžaduje použití tagovaného PDF k poskytnutí logické struktury a informací o pořadí čtení spolu s použitím Unicode, aby byl umožněn přístup k textu dokumentu. * **Úroveň U (Unicode)** shoda byla úrovní přidanou do PDF/A-2 a navazuje na úroveň B tím, že navíc vyžaduje použití Unicode pro text dokumentu, ale nezachází tak daleko jako úroveň A tím, že by nařizovala informace o struktuře. Verze PDF/A a úrovně shody lze shrnout v tabulce: | | | | | | -------------------- | ------------------------------------------- | -------- | -------- | | **Úroveň shody** | **PDF/A-** | | | | Úroveň A (přístupná) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Úroveň B (základní) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Úroveň U (Unicode) | Není k dispozici (pro PDF/A-1 neexistovalo) | PDF/A-2u | PDF/A-3u | ### PDF/UA („univerzální přístupnost“) Ačkoli shoda úrovně A standardu PDF/A do jisté míry definuje požadavky na přístupná PDF, další norma ISO nazývaná [ISO 14289](https://www.iso.org/standard/64599.html), označovaná jako PDF/UA, jde dál. PDF/UA zpřísňuje požadavky na přístupnost a upřesňuje doporučení obsažená ve standardech PDF/A a stal se preferovaným standardem pro přístupná PDF. #### Protokol Matterhorn Čtenáře s hlubokým zájmem dozvědět se více o shodě s PDF/UA může zajímat [Protokol Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) což je „seznam všech možných způsobů, jak nesplnit shodu s PDF/UA“. ### Validační software Aby bylo možné zkontrolovat, zda soubor PDF odpovídá určitému standardu, musí být *validován* ověřen pomocí validačního softwaru, který prohledá PDF a zkontroluje, zda jeho obsah a struktura odpovídají požadavkům daného standardu — například PDF/UA nebo PDF/A-*x*a (kde *x* = 1, 2 nebo 3). Upozorňujeme, že validace PDF — jejich zpracování preferovaným validačním nástrojem — může vytvářet diagnostické zprávy nebo varování, která mohou být pro neodborného uživatele dosti nesrozumitelná — možná kvůli některým nízkoúrovňovým datům PDF (nebo struktuře), jež nesplňují příslušný standard. Pro mnoho autorů může být interpretace těchto varování a jejich přeměna na konkrétní opravu jejich dokumentů poměrně velkou výzvou. #### Bezplatný validační software * [veraPDF](https://verapdf.org/) který, cituji jejich web (přístup 28. května 2020), je „speciálně vytvořený, open-source validátor formátu souborů pokrývající všechny části PDF/A a všechny úrovně shody“. * (pouze pro Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) který je „...bezplatný nástroj pro kontrolu přístupnosti PDF, který byl prověřen a testován od roku 2010“. #### Komerční validační software * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) poskytuje sadu validačních testů PDF spolu s nástroji pro úpravu a opravu tagů v nevyhovujících souborech PDF. ### PDF Association: skvělý zdroj informací Ta [PDF Association](https://www.pdfa.org/) vytváří mnoho *vynikající* zdrojů o PDF/A, PDF/UA a mnoha dalších tématech souvisejících s PDF — včetně videí na jejich [kanálu YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) spolu s články a bezplatnými technickými publikacemi dostupnými na jejich webu. Jednou z těchto publikací je [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) která poskytuje neocenitelný úvod do standardu PDF/UA a jeho požadavků. ## Přístupná PDF z TeXových enginů a LaTeXu Doufejme, že předchozí diskuse naznačily, že vytváření plně přístupných a správně tagovaných souborů PDF je náročná technická výzva. Navíc i jednoduchý příklad z Microsoft Wordu ukázal, že autoři mohou velmi snadno používat kombinace softwarových funkcí, které vedou k tagovaným dokumentům PDF, jež nesplňují kritéria přístupnosti. Jako autorský nástroj poskytuje LaTeX autorům téměř neomezenou flexibilitu v rozsahu a složitosti dokumentů, které lze vytvořit — což může být právě důvod, proč si jej člověk vybere. LaTeX také podporuje rozšiřitelnost prostřednictvím tisíců doplňkových balíčků, které mohou autoři používat jako součást svých dokumentů. K tomu všemu mají autoři svobodu psát nové TeXové nebo LaTeXové makra nebo redefinovat stávající, aby dosáhli konkrétních efektů. Nicméně možná má tato svoboda a flexibilita svou cenu, protože obsah vznikající z nesčetných interakcí všech těch balíčků a maker LaTeXu je nějak třeba „zorchestrovat“, má-li LaTeX automaticky generovat správně tagovaný a přístupný výstup PDF. V praxi představují rozšiřitelnost, síla, všestrannost a autorská „svoboda“, kterou LaTeX poskytuje, technické výzvy pro bezproblémové a transparentní („automatické“) vytváření plně přístupných tagovaných dokumentů PDF, které odpovídají normám PDF/UA nebo PDF/A-{1|2|3}a. Širší komunita TeXu a LaTeXu se snaží tyto výzvy řešit a The TeX User Group (TUG) koordinuje výzkumné a vývojové úsilí prostřednictvím pracovních skupin pro přístupnost PDF a standardy PDF [pracovní skupiny](https://www.tug.org/twg/accessibility/). K dispozici je [diskusní seznam](https://tug.org/mailman/listinfo/accessibility) který poskytuje zájemcům způsob, jak diskutovat o vytváření tagovaných souborů PDF pomocí TeXu a LaTeXu. V těchto diskusích stojí za to pamatovat, že LaTeX ve skutečnosti není spustitelný sazební program, ale velká sbírka sofistikovaných maker (příkazů) napsaných v nižší úrovňovém jazyce nazývaném TeX. Mezi pečlivě vytvořeným dokumentem LaTeX a výsledným sázeným PDF stojí software zvaný TeX engine, jehož úkolem je „spouštět“ sadu příkazů LaTeXu (tj. makra) použitých k zápisu a sestavení vašeho dokumentu — převádět je do sazební reprezentace dokumentu uložené jako soubor PDF. Ti, kdo jsou v ekosystému TeX/LaTeX noví, jsou často, a zcela pochopitelně, zmatení množstvím krypticky znějících názvů používaných pro nástroje, na které narazí: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX a LuaLaTeX. Pokud se cítíte stejně, pomoc je po ruce v článku Overleafu [Co se skrývá v názvu: Průvodce mnoha podobami TeXu](/latex/cs/clanky-do-hloubky/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) který vysvětluje původ a význam všech těchto termínů. TeXové enginy jako pdfTeX, XeTeX nebo LuaTeX jsou třída softwaru nazývaná *kompilátory dokumentů*: vezmou váš kód LaTeX a zkompilují jej do jeho sazební podoby tím, že „převádějí“ makra LaTeXu (příkazy) zpět do instrukcí nižší úrovně jazyka TeX, které jsou „prováděny“ za účelem vytvoření sazebního výsledku. Sazební systémy založené na TeXu jsou schopny vytvářet mimořádně složitý obsah — včetně pokročilé matematiky, hudební notace, chemických struktur, grafiky a sofistikovaného vícejazyčného sázeného textu. Aby tyto složité dokumenty splňovaly standardy a předpisy pro přístupnost, musí TeXové enginy spolu se sadou maker LaTeXu a balíčky LaTeXu generovat vhodně tagované soubory PDF tím, že do jimi generovaných souborů PDF vloží velké množství dodatečných dat. Ačkoli TeXové enginy mohou generovat extrémně složité soubory PDF, jejich interní procesy, algoritmy a funkce nemají *vestavěnou* funkce *speciálně navržené* pro podporu vytváření tagovaných a přístupných PDF. Místo toho musí být podpora tagování a přístupnosti dosažena pomocí složitého programování maker, které do PDF generovaných TeXovými enginy „vstřikuje“ dodatečná data — vytváří sekvence označeného obsahu, prvky struktury a datové struktury logické struktury uložené v `StructTreeRoot`. A právě zde se ono „zorchestrování“ dostává do ostrého popředí: kód v jádru (kernelu) LaTeXu spolu s kódem v tisících balíčků a nesčetných autory vytvořených maker by musel velmi pečlivě spolupracovat, aby provádění maker produkovalo správné tagování obsahu výsledných dokumentů. Toto „zorchestrování“ by muselo být spolehlivé — bez ohledu na to, jak autoři zvolí kombinovat a používat funkce, příkazy a možnosti LaTeXu, jeho systém balíčků a sílu TeXových maker. ### Potřeby autorů Pro většinu lidí je LaTeX jen nástroj, který vám umožňuje vytvářet krásně vysazené dokumenty a zároveň si vybírat balíčky, které vám pomohou toho dosáhnout. Naprostá většina autorů LaTeXu chce jednoduše, aby jejich dokumenty „fungovaly“: aby se vysázely bez chyb, aby mohli odevzdat svou diplomovou práci, článek, zprávu nebo dokončit dlouho očekávanou knihu. Není to nerozumné, uživatelé LaTeXu očekávají, že jejich zvolená sada balíčků LaTeXu bude pokojně koexistovat a bezproblémově a transparentně spolupracovat při poskytování příkazů a funkcí potřebných k vytváření jejich dokumentů. Stejná přání lze pravděpodobně nalézt i při požadavku na vytváření tagovaného PDF z LaTeXu: mělo by to „prostě fungovat“, transparentně a s minimálním zásahem autora. Bohužel jsme stále daleko od zkušenosti typu „Hej presto! tagování se prostě děje, ať dělám cokoli divného“. Spojení technických požadavků na přístupnost plus tagované PDF se svobodou LaTeXu a autorské tvorby je ze své podstaty složité a možná se nelze vyhnout tomu, že bude potřeba nějaká forma „autorské disciplíny“, má-li být technické výzvy možné prakticky implementovat a řešit. Samostatným, ale souvisejícím problémem je, že nesprávné tagování nemusí mít na výsledné PDF žádný vizuální dopad: vizuálně může vypadat dokonale a pravděpodobně se bez problémů i vytiskne, ale autor o tom nemusí vědět, že tagování je „rozbité“, a zjistí se to až následným selháním kontrol shody/validace PDF/A a/nebo dalším praktickým testováním prostřednictvím asistenčního softwaru, jako jsou čtečky obrazovky. ### Soubory PDF vytvořené na Overleafu Overleaf poskytuje své uživatelské komunitě editor LaTeX založený na prohlížeči spolu s nástroji pro správu projektů a dokumentů, které usnadňují kolaborativní tvorbu — to vše postavené na standardní instalaci TeX Live. Ve skutečnosti Overleaf umožňuje uživatelům „spouštět LaTeX na dálku“ prostřednictvím webového prohlížeče, čímž poskytuje vrstvu izolace od složitosti správy a údržby plnohodnotného systému TeX Live. Důsledkem používání standardní instalace TeX/LaTeX na Overleafu je, že PDF vytvořená z kódu LaTeXu napsaného v editoru Overleafu jsou vytvářena pomocí přesně stejných technologií, jaké jsou přítomny v jakékoli jiné instalaci TeX Live stejné verze — včetně nastavení, která mají uživatelé nainstalovaná na svých místních zařízeních. Jediný rozdíl je v tom, že TeXové enginy, které kompilují a zpracovávají kód LaTeXu na Overleafu, běží na vzdálených serverech, nikoli na místních počítačích. Overleaf sice PDF generované TeXem linearizuje pro efektivní stahování/zobrazení v prohlížeči, ale tento proces nesouvisí s přístupností samotného obsahu PDF. Tvorba přístupných PDF prostřednictvím Overleafu závisí na schopnostech a funkcích zabudovaných do standardních TeXových enginů spolu s dostupností vhodných balíčků maker LaTeXu, které mohou uživatelé nasadit jako součást svého dokumentu. Dokumenty LaTeXu vytvořené pomocí Overleafu musí zůstat kompatibilní s jinými instalacemi TeXu a LaTeXu, protože uživatelé často potřebují exportovat svůj projekt LaTeX z Overleafu pro odevzdání do široké škály publikačních a časopiseckých systémů. Zavedení funkcí specifických pro Overleaf do jeho dokumentů LaTeXu nebo do podkladových TeXových enginů by vážně omezilo svobodu uživatelů používat svou práci jinde. Overleaf uznává a podporuje potřebu plně přístupných PDF generovaných z autorských systémů TeX/LaTeX: investujeme čas do výzkumu problémů s přístupností, zkoumání nejnovějšího vývoje v TeXových enginech a experimentálních balíčcích LaTeXu, které podporují tagované PDF. V době psaní tohoto textu neexistuje žádné řešení „v krabici“, které by autoři LaTeXu mohli použít (prostřednictvím `\usepackage`) k bezproblémovému a transparentnímu generování plně přístupných PDF odpovídajících PDF/UA z obecnych dokumentů LaTeXu. Když budou tato řešení dostupná prostřednictvím aktualizací TeX Live, budou samozřejmě dostupná i uživatelské komunitě Overleafu. ### Některé balíčky LaTeXu pro zkoumání tagování a přístupnosti Pro mnoho lidí, [tex.stackexchange](https://tex.stackexchange.com/) je první místo, kam se obracejí s žádostí o pomoc s TeXem, LaTeXem nebo ConTeXtem. Je to úžasný zdroj a má mnoho otázek na téma [přístupnosti](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) a vytváření přístupných PDF prostřednictvím LaTeXu. Pokud si tyto otázky a následný proud odpovědí a komentářů čtete a procházíte, je jediný závěr nevyhnutelný: v současnosti neexistuje žádné plné řešení na úrovni produkčního nasazení, které by automaticky vytvářelo plně přístupná, standardům vyhovující, tagovaná PDF z každého typu dokumentu LaTeXu. Existují však některé balíčky, které podporují tagování — byť možná v omezeném rozsahu případů použití a typů dokumentů. Následující seznam je určen čtenářům, kteří chtějí prozkoumat tagování PDF založené na LaTeXu: * [`tagpdf` accents](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): vysoce schopný balíček určený pro experimentování s tagováním PDF. Podporuje pdfTeX a LuaTeX a poskytuje mimořádně užitečnou a zajímavou dokumentaci, která obsahuje několik výborných poznámek o technických výzvách vytváření tagovaných PDF prostřednictvím TeXových enginů; je to velmi doporučené čtení pro každého, kdo chce lépe porozumět souvisejícím problémům. Budoucí směřování se pravděpodobně zaměří na LuaTeX. * [`axessibility` accents](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov a Univerzita v Turíně): poskytuje přístup k vzorcům v souborech PDF prostřednictvím asistenčních technologií. * [`přístupnosti` accents](https://ctan.org/pkg/accessibility) (Andy Clifton): vytváří tagované a strukturované soubory PDF. Poznámky na CTAN uvádějí, že tento balíček je „určen uživatelům tříd dokumentů KOMA-Script“. * [`accsupp` accents](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): experimentální balíček poskytující lepší podporu přístupnosti pro soubory PDF. Další pozoruhodnou zmínkou je článek z roku 2018 [Implementace standardů PDF pro matematické publikování](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) od Dr. Rosse Moora z Katedry matematiky Macquarie University. V tomto článku Dr. Moore uvádí krátký přehled problémů s tagováním PDF v LaTeXu: > „Hlavní zdroj obtíží spočívá v tom, jak mohou různé prostředí vzájemně interagovat. V LaTeXu existuje mnoho situací, kdy jedno prostředí nebo struktura není skutečně dokončeno, dokud nezačne další. Není tedy jen otázkou obalit každý kus dodaného obsahu start a konec tagy. Místo toho je třeba porozumět jemnostem toho, jak jednotlivá prostředí a další struktury skutečně začínají a končí v kontextu vytvořeném okolním materiálem.“ Dr. Moore je také současným správcem [`pdfx`](https://ctan.org/pkg/pdfx) balíčku a odborníkem i průkopníkem tagovaného PDF pomocí TeXu/LaTeXu. Jeho práce rozhodně stojí za vyhledání — včetně tohoto videa na YouTube, které poskytuje zajímavé poznatky: {% embed url="" %} #### Poznámka k balíčku pdfx Ta [`pdfx`](https://ctan.org/pkg/pdfx) Balíček (Ross Moore a kol.) poskytuje vynikající podporu pro PDF/A-1|2|3b (archivace) a další možnosti, ale zatím nevytváří tagované 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/cs/dalsi-temata/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.