> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/latex/uk/inshi-temi/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Вступ до позначених PDF-файлів: внутрішня структура та виклики доступності ## Оновлення: січень 2026 Будь ласка, дивіться [інструкції Overleaf зі створення тегованих PDF](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Функція [команда LaTeX](https://latex-project.org/) випустила нові можливості, які забезпечують автоматичне тегування PDF — центральну вимогу для доступності PDF. Ці нові можливості доступні в Overleaf у [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), а новіші оновлення доступні в безперервному випуску TeX Live, доступному через [Overleaf Labs](https://www.overleaf.com/labs/participate). Тепер можна створити тегований PDF із вихідного коду LaTeX, що відповідає WCAG 2.1 рівня AA, дотримуючись [нашої документації для користувачів](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) з використанням випусків TeX Live, доступних в Overleaf. Наведену нижче статтю з 2020 року, хоча вона й не оновлена з урахуванням найновішої інформації про доступність LaTeX, можна й надалі читати з цікавості та для довідкової інформації про тегування PDF. *** ## Що охоплює ця стаття? Мета цієї статті — дати вступ до тегованого PDF разом із оглядом деяких технічних викликів, з якими стикається програмне забезпечення, зокрема рушії TeX і LaTeX, які прагнуть створювати теговані й доступні PDF-файли. Доступність, особливо PDF, — це широка й складна тема, яка також має технічні виклики, що не завжди мають одне універсально узгоджене чи прийняте рішення — наприклад, як доступним способом подати складну математику в PDF: за допомогою MathML чи коду LaTeX? Хоча ми не можемо глибоко зануритися в кожну тему і мусимо спрощувати багато деталей, ми можемо зазирнути всередину PDF, щоб показати, що насправді означає тегування PDF. Overleaf сподівається, що ця стаття стане корисним вступом, надаючи достатньо довідкової інформації, щоб допомогти читачам краще зрозуміти технічні виклики та підтримати їхнє подальше читання й дослідження тегованого PDF та доступності. Ресурси в цій статті включають: * [8-хвилинне відео](#video-showing-the-logical-structure-of-a-tagged-pdf) про дослідження тегованого PDF, створеного LaTeX; * [проект Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) для дослідження використання пробільних символів у LuaTeX; * [звукові записи](#tagged-yes-but-the-reading-order-is-incorrect) що демонструють проблеми доступності PDF. ## Вступ Забезпечення доступності цифрового контенту справедливо визнається важливим аспектом створення та поширення контенту. Ба більше, уряди, зокрема [Сполученого Королівства](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) та [Сполучених Штатів](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), ухвалюють закони, які вимагають, щоб контент, створений у межах їхньої юрисдикції, відповідав визначеним критеріям доступності. Відповідність через поширення контенту в HTML не є надто обтяжливою, але забезпечення необхідного рівня доступності для документів, поширюваних у форматі PDF, може становити значний технічний виклик — залежно від програмного забезпечення, яке використовується для створення контенту, призначеного для виведення як PDF-файл. PDF з’явився на початку 1990-х років як рішення проблем, пов’язаних із надійною передачею документів, і історія показала, що він надзвичайно успішний. Однак PDF — це також складний формат файлів, який виник до того, як потребу в забезпеченні доступності вмісту документів було широко визнано й прийнято. Попри це, з часом специфікація PDF еволюціонувала, надаючи можливості, що дають змогу створювати доступні PDF-документи, використовуючи «стилізований» різновид PDF, який Adobe називає *тегований PDF*. На практиці створення тегованих —*і повністю доступних*—PDF-файлів ставить перед програмним забезпеченням, яке виводить PDF, значні додаткові технічні вимоги — і це стосується рушіїв TeX та екосистеми макросів і додаткових пакетів LaTeX. ## Поява PDF як цифрового паперу кінцевої форми Функція [походження Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) позначає епоху, в якій передавання документів між комп’ютерами було сповнене труднощів, часто спричинених перетворенням файлів, що призводило до переламування сторінок та інших невідповідностей, посилених несумісними шрифтами й кодуваннями тексту, які використовувалися в різних операційних системах (зокрема Windows і Macintosh). Автор цього документа тоді працював у видавничій справі й має яскраві спогади про боротьбу з цими викликами! PDF було розроблено, щоб розв’язати проблеми спільного використання файлів шляхом запровадження універсального цифрового паперу кінцевої форми (нередагованого), що дає змогу безперешкодно передавати самодостатні документи, які містять шрифти, необхідні для їх відображення. Користувачі нарешті могли передавати всілякі документи з розумною впевненістю, що одержувачі, незалежно від комп’ютерної платформи, зможуть їх відкрити й прочитати — точність документа зберігалася, а незручні переламування сторінок і сумісність/доступність шрифтів залишилися в минулому. ### Цифровий папір: добре для всіх користувачів? Походження PDF як форми цифрового паперу природно передбачало використання номерів друкованих сторінок, типографіки або елементів дизайну як підказок для візуальної навігації його вмістом — на екрані чи на папері. Однак ці візуальні підказки/механізми, звісно, не мають значення для людей із тяжкими порушеннями зору. Сьогодні покращення доступності цифрового контенту справедливо визнається важливим аспектом створення та поширення контенту. Виклик для PDF полягав у тому, щоб надати механізми, які полегшують невізуальний доступ до вмісту, замкненого в «контейнері», спочатку призначеному для відтворення візуального середовища друкованої сторінки. Перша версія специфікації PDF (PDF 1.0) [була офіційно випущена 15 червня 1993 року](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) за нею з’явилися нові версії з оновленнями, які у 2001 році (PDF 1.4) включали запровадження «tagged PDF», що [«...дозволило користувачам допоміжних технологій»](https://www.adobe.com/accessibility/pdf.html). Подальші випуски специфікації PDF розширювали й удосконалювали можливості PDF, що culminувало в найновішому випуску (PDF 2.0), який, згідно з [звітами](https://www.pdfa.org/tagged-pdf-2-0/), суттєво оновив функції доступності — хоча PDF 2.0 все ще недостатньо добре підтримується рушіями TeX. ## Вміст усередині PDF Щоб оцінити пов’язані з цим проблеми, варто розглянути, як саме PDF-файли представляють вміст сторінок, які вони містять. Глибоко всередині PDF-файлу вміст кожної сторінки міститься у її *потоці вмісту*: послідовності операторів PDF («команд»), які розміщують текст або графіку в певному місці сторінки для візуалізації (відображення) програмним забезпеченням, яке використовується для *перегляду* PDF. По суті, потік вмісту надає графічний опис або «рецепт», який підказує програмам для перегляду PDF, як «намалювати» кожну сторінку — визначаючи, що має відображатися на сторінці та де. Природно, ця послідовність операторів включає інструкції щодо вибору певних шрифтів конкретного розміру, вибору кольорів, визначення товщини ліній, малювання ліній, кривих і так далі — усе, що потрібно для повного графічного опису візуального подання сторінки. Щоб зменшити розмір файлу, потоки вмісту PDF стискаються і зберігаються в компактному бінарному форматі, але якщо ви маєте доступ до відповідного програмного забезпечення, наприклад Adobe Acrobat Pro DC, ви можете скористатися ним, щоб переглянути «розпаковану» текстову версію потоків вмісту сторінок. Розгляньмо, як оператори PDF можуть «намалювати» таблицю: потік вмісту PDF міститиме відповідну послідовність операторів для створення горизонтальних/вертикальних ліній, вибору різних шрифтів і виведення тексту, розміщеного в різних місцях сторінки, щоб створити вміст таблиці. Щоб показати це, розгляньмо дуже простий нетегований PDF-документ, що не містить нічого, крім простої таблиці з текстом, — створений у Microsoft Word з причин, які стануть очевидними пізніше в статті. Ось знімок екрана нашого простого PDF: ![Таблиця, створена в Microsoft Word](/files/10f728a6de1d7a4e0c6f7f11edac482a7dfbcf91) Якщо ми витягнемо (розпакований) потік вмісту сторінки для цього файлу й вставимо перші кілька рядків у текстовий редактор, то зможемо підсумувати деякі оператори PDF, щоб отримати «уявлення» про те, як PDF-файли «описують» вміст, показаний на цій сторінці. ![Зображення потоку вмісту у PDF-файлі](/files/df62f691fcc800780a53c0c37caf5a31de25cfaf) Якщо у вас є доступ до Adobe Acrobat Pro DC, ви можете використати його, щоб перерахувати оператори, що містяться в потоці вмісту сторінки PDF. Ось вигляд Acrobat для *внутрішньої структури PDF* того самого PDF, який зручно надає однорядковий опис кожного оператора, використаного для «малювання» нашої односторінкової таблиці — зауважте, що ці короткі описи надаються Adobe Acrobat Pro DC, вони *не* присутні в самому PDF-файлі: ![Зображення потоку вмісту PDF, переглянутого в Adobe Acrobat Pro DC](/files/c198aba8d74b67864e36afecdf0a7013b9de7643) Однак зауважте, що жодна з цих інструкцій малювання (операторів) не зберігає жодного «значення» чи «опису» того, що вони фактично створюють: це лише набір графічних операторів, які призводять до побудови того, що *зрячий спостерігач розпізнає* як таблицю. Очевидно, для людей із тяжкими порушеннями зору відображення таблиці, що є результатом цих графічних операторів у потоці вмісту PDF, не є придатним способом доступу до цього вмісту. Потрібен механізм, щоб PDF-файли містили відповідний невізуальний (машинозчитуваний) опис цієї таблиці — і, звісно, всіх інших елементів вмісту, що містяться на сторінках усередині PDF-файлу. Щоб забезпечити невізуальний доступ до вмісту, PDF-файли мають містити додаткові дані, які надають «значення» або семантику колекціям чи групам операторів, що використовуються для «малювання» певного фрагмента вмісту. Зрозуміло, цей принцип присвоєння або надання «значення» має поширюватися на всі форми вмісту, що містяться в PDF: цей механізм існує і називається *тегування* PDF, щоб отримати «варіант» PDF, який, не дивно, називається *тегований PDF*. ## Вступ до тегованого PDF Тегований PDF — це назва, яку надають певному типу PDF-файлу, що містить додаткові дані (і структури даних), відсутні в нетегованих PDF-файлах. Хоча принципи/ідеї, що лежать в основі тегованого PDF, можна коротко описати, повні деталі є складними й займають багато сторінок у формальній специфікації PDF. Adobe розробила тегований PDF для досягнення низки цілей, зокрема зробити вміст доступним для користувачів із порушеннями зору, але це також охоплює наведений нижче список із розділу 10.7 [специфікації Adobe PDF 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * просте виділення тексту та графіки для вставлення в інші програми; * автоматичне переформатування тексту та пов’язаної графіки, щоб вони вмістилися на сторінці іншого розміру, ніж було передбачено для початкового макета; * обробка тексту для таких цілей, як пошук, індексування та перевірка орфографії; * перетворення в інші поширені формати файлів (такі як HTML, XML і RTF) зі збереженням структури документа та базової інформації про стиль. Крім того, тегований PDF також вимагає: * щоб текст усередині PDF-вмісту був поданий у формі, яку можна перетворити на Unicode; * розриви слів мають бути подані явно — зауважте, що рушії TeX не використовують символи пробілу для розділення слів, вони використовують гнучке проміжне заповнення TeX, яке називається glue (див. нижче); * справжній («реальний») вміст відрізняється від артефактів верстки та розбиття на сторінки. Основою тегованого PDF є дві ключові концепції, які ми розглянемо: * визначення логічної структури вмісту у PDF-файлі; * розмітка (тегування) PDF-вмісту набором стандартних типів вмісту. ## Логічна структура У довших документах вміст зазвичай поділяється на послідовність менших елементів; наприклад, книги зазвичай поділяються на розділи, які, своєю чергою, діляться на секції та підсекції, що містять абзаци, таблиці, рисунки/діаграми, марковані або нумеровані списки, виноски та посилання тощо. Структура та організація вмісту в такій книзі або будь-якому іншому типі документа називається його *логічною структурою*. Поняття логічної структури документа відіграє важливу роль у доступності PDF, але як концепція воно може здаватися дещо розпливчастим і складним для розуміння. Наведене нижче визначення з [Енциклопедії систем баз даних](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) дає корисне уявлення: > «Логічна структура означає спосіб організації інформації в документі; вона визначає ієрархію інформації та зв’язки між різними частинами документа. Логічна структура вказує, як побудовано документ, на відміну від того, що саме документ містить». Зауважте, що це визначення логічної структури не робить жодного посилання на те, де саме *як* ця структурна інформація фізично зберігається; воно лише означає, що вона надає представлення структури й організації документа. Точні деталі того, як логічна структура документа зберігається або подається, залежать від реалізації: від програмного забезпечення, яке використовується для її створення та обробки. ### Логічна структура в PDF Специфікація PDF надає механізми, за допомогою яких логічну структуру документа можна записати всередині PDF-файлу — для використання програмним забезпеченням, яке, наприклад, може захотіти експортувати вміст PDF до інших форматів, таких як XML, HTML або Microsoft Word. Ці процеси експорту мають створювати правильно структурований текстовий документ, що відповідає правилам цільового формату файлу експорту — цього найкраще досягти, коли процес експорту керується інформацією про логічну структуру, наданою в PDF. Крім того, логічна структура PDF-файлу є необхідною для програмного забезпечення доступності, яке, наприклад, може виконувати синтез мовлення, озвучуючи вміст людині з порушеннями зору. Процес синтезу мовлення має гарантувати, що вміст озвучується в правильному порядку/послідовності, інакше він дасть безглузді результати. Також зауважте, що сама концепція сторінки може не мати жодного змісту для програм доступності, які цікавляться лише вмістом PDF і структурою документа, а не візуальним поділом і поданням у вигляді сторінок. #### Іменування елементів вмісту Запис (зберігання) логічної структури PDF-документа вимагає певного набору змістовних назв, призначених для різних *типів* елементів вмісту, які ймовірно трапляються у типовому PDF-документі — позначаючи розділи вмісту, що представляють заголовки, абзаци, таблиці, списки тощо. Крім того, деякі елементи вмісту, такі як зміст, нумеровані/марковані списки та табличні матеріали, мають доволі складні власні структури, тому також потрібні певні вказівки/правила, щоб визначити, як ці складніші елементи вмісту побудовані — їхню підструктуру. Додаткова вимога — чітко ідентифікувати будь-який PDF-вміст, який має бути проігнорований допоміжним програмним забезпеченням, що обробляє PDF; наприклад, верхні та нижні колонтитули сторінок є артефактами розбиття на сторінки, що містять текст, який є зайвим для людей із тяжкими порушеннями зору: цей вміст слід ігнорувати. Механізми, які PDF використовує для визначення логічної структури документа, розроблено так, щоб вони були гнучкими, тож у принципі різні програми, які створюють і обробляють PDF-файли, могли б використовувати назви типів вмісту за будь-якою домовленою для них схемою. Однак, щоб максимально підвищити сумісність документів і дозволити різним програмам обробки PDF надавати узгоджені результати, Adobe визначила набір стандартних назв для типів елементів вмісту, яких програмне забезпечення для створення PDF має дотримуватися. У специфікації PDF ці стандартні назви називаються тегами, що породжує поняття *тегованого* PDF. ### Розмітка PDF-вмісту: погляд «під капот» Щоб зробити обговорення трохи менш абстрактним, ми коротко подивимося на внутрішню структуру тегованих PDF-файлів — хоча ми не можемо охопити всі деталі, оскільки тегований PDF — це надто велика й складна тема. #### Послідовності позначеного вмісту: будівельні блоки тегованого PDF На найнижчому рівні процес запису значення вмісту, що міститься всередині сторінки PDF (тобто в її потоці вмісту), починається з *послідовностей позначеного вмісту* які використовуються для ідентифікації (надання «значення») кластерів або груп операторів PDF. Послідовностям позначеного вмісту присвоюється числовий ідентифікатор, який називається `MCID` (*ідентифікатор позначеного вмісту*) — це ціле число, що на кожній сторінці змінюється від 0 до певного максимального N. Ці `MCID` значення забезпечують спосіб унікально ідентифікувати послідовності операторів, що містяться в потоці вмісту певної сторінки. Для ясності: для кожної сторінки `MCID` ідентифікатори починаються з 0 і послідовно зростають до певного максимального значення, яке залежить від того, скільки послідовностей позначеного вмісту міститься в потоці вмісту конкретної сторінки. Послідовності позначеного вмісту, по суті, є фундаментальними «будівельними блоками», які використовуються для складання структур даних вищого рівня, що називаються *структурними елементами*. Ці структурні елементи містять тег, який є назвою, що використовується для позначення типу елементу вмісту, який вони представляють. #### Приклад структурних елементів Тут ми трохи забігаємо вперед, але варто розглянути приклад. Припустімо, у вас є 3 невеликі фрагменти тексту зі сторінкового вмісту, і кожен із них ідентифікується в потоці вмісту окремою послідовністю позначеного вмісту. Кожен із цих 3 фрагментів тексту можна упакувати у власний структурний елемент із тегом, і всі три можна «пов’язати разом» за допомогою іншого структурного елемента, щоб представити елемент вмісту вищого рівня, наприклад рядок у змісті. ![Зображення, що пояснює структурні елементи та послідовності позначеного вмісту](/files/c7d6aca46e0fccab51a283872c919f01fd9b6390) Через форму батьківсько-дочірнього зв’язку даних набори структурних елементів об’єднуються, щоб створити пов’язані структури даних, які представляють складніші елементи даних, такі як нумеровані та марковані списки, таблиці, математика тощо. Зрештою, вся сукупність структурних елементів, що містяться в усьому PDF-файлі, додатково пов’язується й об’єднується, щоб створити логічну структуру PDF-документа — ми повернемося до цього пізніше в статті. ### Що таке послідовність позначеного вмісту? У наведеному вище обговоренні ми використовували простий нетегований PDF-документ із таблицею (створеною в Microsoft Word), але якщо ми попросимо Word створити тегований PDF, то побачимо, що в потоці вмісту сторінки з’явилася додаткова розмітка. Тут ми розглядаємо лише перші кілька рядків потоку вмісту (там сотні рядків), але зверніть увагу на наявність додаткових операторів, таких як `/P <> BDC` та `EMC` які використовуються для ідентифікації послідовності позначеного вмісту. Ми не будемо досліджувати повний синтаксис послідовностей позначеного вмісту, але відсилаємо читача до сторінки 862 [офіційної специфікації PDF 1.7 від Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Зображення, що показує послідовності позначеного вмісту в потоці вмісту тегованого PDF](/files/45b5d9e72318e153ec107403cb47d3dbd8aa97a8) Для зручності посилання знову покажемо нетеговану версію: ![Зображення, що показує потік вмісту PDF](/files/df62f691fcc800780a53c0c37caf5a31de25cfaf) У *нетегованого* PDF, оператори на кшталт `/P <> BDC` та `EMC` відсутні, але решта операторів не змінена: нетегований PDF не має додаткової розмітки, яка використовується для ідентифікації певних послідовностей/наборів операторів. Знову ж таки, ми також можемо використати *внутрішньої структури PDF* можливість Adobe Acrobat переглядати послідовності позначеного вмісту в потоці вмісту — тут ми виділили їх зеленою рамкою: ![Зображення, що показує послідовності позначеного вмісту в потоці вмісту тегованого PDF, переглянутому в Adobe Acrobat Pro DC](/files/00777c39c3f5adf0edf4201512f096eadf9bef61) Зауважте, що деякі фрагменти вмісту позначено `/Artifact` який позначає матеріал на сторінці PDF, що має бути *проігнорований* допоміжними програмними застосунками, такими як ті, що озвучують текст для людей із порушеннями зору. Наведений нижче знімок екрана показує розгорнутий вигляд першої послідовності позначеного вмісту — тієї, що має `MCID` значення `0`. Кінець послідовності позначеного вмісту визначається оператором PDF `EMC`. ![Зображення, що показує деталі операторів, охоплених потоком позначеного вмісту](/files/d6e4fdbf229db3c949aa6495dc2c47bafe6c7ee5) ### Зберігання логічної структури Як зазначалося, крім надання опису окремих елементів вмісту (абзаців, списків, таблиць тощо), для доступних PDF необхідно, щоб вони містили подання всього документа у вигляді його логічної структури. Окремі фрагменти доступного вмісту мають бути пов’язані разом, щоб створити повний, придатний для навігації та доступний документ — подібно до того, як один HTML-документ будується з абзаців, графіки, таблиць, щоб створити вебсторінку. Крім того, життєво важливо, щоб логічна структура PDF-документа забезпечувала навігацію по всьому вмісту в правильному *порядку читання*, незалежно від того, у якому порядку вміст сторінки було записано в потоки вмісту сторінки PDF. Детальніше про порядок читання ми розглянемо нижче. #### Логічна структура: «дерево» структурних елементів Ми зазначили, що PDF використовують те, що називається *структурним елементом* для представлення окремих елементів вмісту, і що структурний елемент містить тег, який ідентифікує, який тип вмісту він представляє. Щоб подати логічну структуру документа, усі структурні елементи пов’язуються між собою через відношення батько—дитина і організовуються в «дерево структури». Усередині тегованих PDF-файлів міститься об’єкт під назвою `StructTreeRoot` який містить (вказує на) структурні елементи, що виступають точкою входу або «коренем» дерева логічної структури документа. Зазвичай «корінь» дерева структури починається з одного структурного елемента, позначеного тегом `Document` який містить численні *дочірні* структурні елементи, що разом представляють увесь вміст документа. Будь-яке програмне забезпечення, призначене для створення доступних PDF шляхом тегування, має будувати цю дуже складну структуру даних (та інші!) — і це стосується рушіїв TeX і LaTeX. Приклад такого дерева структури документа (`StructTreeRoot`) показано на наступному знімку екрана тегованого PDF, відкритого в Adobe Acrobat Pro DC: ![Зображення, що показує StructTreeRoot у тегованому PDF](/files/184fe7669a9ad1d8598efde8b4a1d6d940d0ae2d) Порівняймо наведену вище структуру з нетегованою версією PDF: ![Зображення, що показує відсутність StructTreeRoot у нетегованому PDF](/files/5c5bf9f854a6061a514dccba98d0d0055a120aed) ### Дослідження логічної структури PDF Ми починаємо з кількох графічних схем, щоб підсумувати те, що вже розглянули, і завершуємо відео, яке використовує Adobe Acrobat Pro DC, щоб показати більше деталей логічної структури тегованого PDF-файлу. Спочатку ми почнемо зі схеми, що показує загальні принципи: сторінка PDF з її потоком вмісту, розміченим послідовностями позначеного вмісту (MCS). ![Графічна схема, що показує концепцію послідовностей позначеного вмісту на сторінках PDF-документа](/files/66ed81b1b1c5959960d0dc611f93375feeeeb1de) Потім ці MCS об’єднуються в *структурними елементами* які становлять основу для більших типів вмісту, що, своєю чергою, додатково пов’язуються між собою для зберігання логічної структури PDF в об’єкті під назвою `StructTreeRoot`. ![Графічна схема, що показує логічну структуру тегованого PDF-файлу](/files/64d2f2d37c516341eae52009d0c3fa4ad928c11e) #### Відео, що показує логічну структуру тегованого PDF Наведене нижче відео (8 хвилин) використовує Adobe Acrobat Pro DC, щоб провести вас у «оглядову екскурсію» й дослідити деталі логічної структури тегованого PDF-файлу, створеного за допомогою LaTeX. Тегований PDF-файл, використаний у відео, називається `tagpdf.pdf`, який є чудовим прикладом, що містить документацію для експериментального пакета LaTeX [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). `tagpdf` Мета пакета — надати «інструменти для експериментів із тегуванням і доступністю за допомогою pdfLaTeX і LuaTeX». {% embed url="" %} ### Примітка про тегування та гнучкість Специфікація HTML надає велику кількість попередньо визначених тегів для використання під час створення вебсторінок, але також дозволяє гнучкість у тому, як ви поєднуєте їх, щоб створити обраний HTML-документ. Подібним чином специфікація тегованого PDF від Adobe надає набір попередньо визначених назв тегів, але накладає дуже мало обмежень на те, як ви поєднуєте ці теги, щоб представляти складні елементи вмісту в PDF — за задумом тут є велика гнучкість. Крім того, в будь-якій специфікації, настільки великій і складній, як PDF, неминуче виникають деякі неоднозначності або проблеми з ясністю в тексті специфікації. Розробникам програмного забезпечення, яким доручено реалізувати таку складну специфікацію, можливо, доведеться робити «оцінкові рішення» під час її інтерпретації, оскільки вони мають перетворювати письмові описи на працездатний код. Властива тегованому PDF гнучкість разом з інтерпретацією специфікацій (або стандартів доступності) природно впливає на розробників програм для створення документів: які комбінації тегів слід використовувати для представлення вмісту, створеного користувачем, під час виведення його в тегований PDF-файл? Якщо врахувати безмежну здатність користувачів створювати всілякий вміст, використовуючи можливості програмного забезпечення для створення документів, тоді стає зрозуміло, що автоматичне створення доступних тегованих PDF — це певний виклик! Можливо, відображаючи неминучі складнощі створення тегованих PDF, які повністю відповідають стандартам доступності, в Інтернеті є безліч «інструкцій», «порад» і рекомендацій «найкращих практик» щодо створення тегованих PDF за допомогою такого програмного забезпечення, як Adobe InDesign або Microsoft Word. Крім того, PDF Association підготувала корисний документ під назвою [Посібник із найкращих практик для тегованого PDF](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) створений, щоб допомогти розробникам, які стикаються з викликами впровадження тегованого PDF та PDF/UA. ## Маєте PDF, але чи є він доступним? Щоб визначити, чи відповідає певний PDF-файл потрібним стандартам доступності, таким як PDF/A або PDF/UA (див. нижче), його потрібно *перевірити* за допомогою узгодженого процесу перевірки або програмного інструмента. Однак перевірка зазвичай відбувається після завершення документа, але цей процес може виконувати не автор документа, а фахівці з доступності в організації чи установі, яка вимагала відповідності. Якщо PDF не проходить перевірку, може знадобитися кваліфіковане ручне втручання через Adobe Acrobat Pro DC, щоб виправити тегування (якщо це можливо). Або ж документ може навіть довестися повернути автору для внесення змін до початкового документа, можливо, шляхом уникнення використання функцій програми для створення документів, які спричинили проблеми, — а це може бути надзвичайно складно, оскільки це може бути поза контролем автора. ### Порядок читання та порядок вмісту Як зазначалося, створення справді доступних PDF ставить додаткові технічні вимоги до програмного забезпечення для створення документів і, потенційно, також до самих авторів документів, змушуючи їх дотримуватися «авторської дисципліни» у тому, як вони використовують/застосовують можливості програмного забезпечення для створення документів. Хоча тегований PDF — це механізм, який *дозволяє* створювати повністю доступні PDF, сам по собі той факт, що PDF є тегованим, не *не* означає автоматично, що він повністю доступний, як ми побачимо в прикладі нижче. Щоб створювати повністю доступні PDF, усі елементи вмісту в PDF мають бути позначені тегами, щоб створити логічну структуру, яка гарантує, що вміст можна буде отримати й прочитати у правильній послідовності — це називається *порядку читання*порядком читання. Це може здаватися «очевидним», але коли програмне забезпечення записує PDF-файл, воно може виводити графіку та текст у потоки вмісту сторінки в будь-якому порядку, який обере. Наприклад, припустімо, що сторінка починалася з тексту, за яким іде таблиця і завершується графікою, утворюючи природний *порядку читання* з: 1. текст 2. table 3. графіка Коли це записується в PDF, програмне забезпечення, що генерує потік вмісту для цієї сторінки, може почати з операторів для малювання таблиці, потім вивести оператори для створення графіки, після чого оператори для тексту, що в потоці вмісту створило б *порядок вмісту* з: 1. table 2. графіка 3. текст Звісно, усе буде розміщено в правильному місці, коли цю сторінку переглядатимуть. Для повністю зрячого читача порядок, у якому ці елементи зберігаються всередині потоку вмісту сторінки, не становить інтересу: вони бачать повністю відрендерену сторінку, де все розташовано правильно. Однак, якщо допоміжне програмне забезпечення мало б покладатися на порядок елементів у потоці вмісту (порядок вмісту), воно зіткнулося б із труднощами, якщо порядок вмісту відрізнявся б від природного порядку читання; наприклад, інструменти для озвучування читали б матеріал у неправильній послідовності. На щастя, допоміжне програмне забезпечення може використовувати логічний порядок (структуру) тегованого PDF, який має бути організований так, щоб відображати послідовність, у якій вміст слід читати. Саме з цих причин дані, що представляють логічну структуру документа, зберігаються окремо від фактичного вмісту, показаного на видимих сторінках, щоб дозволити > «... щоб порядок і вкладеність логічних елементів вмісту були повністю незалежними від порядку та розташування графічних об’єктів на сторінках документа». (сторінка 856 [The PDF Reference, шосте видання, листопад 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) На практиці гарантувати логічний порядок, який зберігає порядок читання, набагато складніше, ніж може здатися, тож скористаймося простим, хоч і вигаданим, прикладом, який дає уявлення про пов’язані з цим проблеми. #### Неправильний порядок читання: приклад із використанням Microsoft Word Автор документа може використовувати можливості обраного ним програмного забезпечення для створення документів, щоб досягти певного візуального ефекту — наприклад, використовуючи таблиці для створення особливого текстового макета. Наприклад, наведений нижче знімок екрана показує документ Microsoft Word, використаний у попередніх прикладах. Він містить таблицю, яку використано для створення набору нумерованих абзаців, розташованих поруч. Але коли йдеться про тегування цього вмісту, як його слід трактувати: як таблицю чи як нумерований список? Обидва ці типи вмісту потребують складної структури тегування, щоб правильно їх представити. На наведеному нижче зображенні зверніть увагу на порядок, у якому призначено читати нумеровані абзаци: по стовпцях, а не по рядках. ![Зображення таблиці, створеної в Microsoft Word](/files/65c75b914952f1409506633d07776fa32b4588d1) Якщо ми попросимо Word зберегти цей документ у PDF за допомогою вбудованого експорту — а не плагіна Acrobat PDFMaker — ми можемо вказати йому створити тегований PDF: ![Діалогове вікно параметрів процесу експорту Microsoft Word](/files/5660acb4de35fa058ee6efe1c18179410d03ff0c) Отже, як Word позначає це розміщення? У наведеному нижче дуже короткому відео (14 секунд) ми використовуємо Adobe Acrobat Pro DC, щоб переглянути структуру тегування, створену Microsoft Word. {% embed url="" %} Для цього документа Word створив тегований PDF-документ, який використовує `Таблиця` тег, що містить два підтеги: `THead` для групи рядків заголовка таблиці та й `TBody` щоб представляти групу рядків для тіла таблиці. `THead` та `TBody` обидва містять `TR` теги, що представляють окремі рядки вмісту. `TR` теги містять додаткові теги, що представляють нумерований елемент списку, наявний у кожній комірці. Наведене нижче зображення екрана показує глибоко вкладену структуру тегування та відповідно складну логічну структуру, потрібну для представлення навіть цього надзвичайно простого документа! ![Зображення, що показує глибоко вкладену структуру тегування та логічну структуру простої таблиці, створеної в Microsoft Word](/files/5b977283fbac5b4bfd48a80136a1915672e94163) Порівняно з PDF, згенерованими TeX і LaTeX, цей приклад Word є надзвичайно простим документом, але для його представлення все одно потрібна складна логічна структура. Уявіть рівень складності тегування, потрібний для представлення PDF, згенерованих LaTeX, що містять складну математику та таблиці! #### Тегований, так, але порядок читання неправильний Хоча Word і справді створює [тегований PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) це демонструє одну з фундаментальних проблем, з якими стикається будь-яка програма, що намагається створювати повністю доступні PDF: правильно відтворити задуманий порядок читання вмісту. Під час створення тегованого PDF внутрішні процеси Word вирішили записати відповідний потік вмісту, виводячи таблицю построково, а не по стовпцях. Для повністю зрячого читача, який переглядає PDF, ці низькорівневі деталі не мають значення: таблиця відображається правильно. Однак для людей із порушенням зору логічна структура документа Word дає неправильний результат, тому що бажаний порядок читання (по стовпцях) не зберігається: вміст читається вголос у неправильному порядку. Наведений нижче аудіозапис було створено за допомогою функції Adobe Reader DC «Read Out Loud». Як видно, текст читається в неправильній послідовності: построково, а не по стовпцях: ![Таблиця, створена в Microsoft Word](/files/5a3dab1c4b7ef3e81ff6f13baf54968a7a6997c7) Як зазначено вище, цей приклад дещо штучний, але він демонструє, наскільки легко застосовувати комбінації функцій програмного забезпечення, що спричиняють проблеми з доступністю — але як автор документа має знати це наперед? Ймовірно, цю проблему було б виявлено лише тоді, коли отриманий PDF пройшов би практичні тести на придатність для доступності — наприклад, із використанням допоміжного програмного забезпечення. Потенційно такі документи могли б пройти перевірки на відповідність/валідацію PDF/A, але провалитися в «реальному» використанні. Забезпечення правильного порядку читання PDF-файлу такого типу потребувало б кваліфікованого ручного втручання з використанням просунутих інструментів редагування PDF, таких як Adobe Acrobat Pro DC: це тривалий і дорогий процес. Або ж автор документа міг би утриматися від використання саме такої форми подання вмісту чи макета — але лише якби знав, що це проблематично! ### Використання символів пробілу для розділення слів Коли ви вводите текст у текстових процесорах або редакторах тексту, ви використовуєте символ пробілу, щоб позначити кінець одного слова й початок наступного. Якщо згодом ви створюєте PDF із такого документа, введені вами символи пробілу, звісно, будуть виведені й стануть частиною тексту, збереженого в PDF. Однак рушії TeX не використовують символи пробілу для розділення слів у набраному тексті; натомість вони перетворюють символи пробілу на форму гнучкого інтервалу, що називається glue (див. це [статті Overleaf](/latex/uk/dokladni-statti/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) для отримання додаткової інформації про TeX boxes і glue). У межах потоку вмісту сторінок PDF, створених рушіями TeX, розділення окремих слів досягається шляхом переходу в іншу позицію на сторінці та початку тексту наступного слова — а не виведенням символу пробілу для створення такого інтервалу. Крім того, величина проміжку між словами в абзацах тексту, набраних рушіями TeX, змінюється від рядка до рядка через алгоритм перенесення рядків TeX. Ця варіація відображається в позиційних даних, записуваних у потік вмісту сторінок PDF. Цей аспект верстки TeX має наслідки для копіювання/вставляння тексту з його PDF-файлів і для допоміжного програмного забезпечення, яке намагається читати вголос набраний текст у PDF, створених рушіями TeX. Допоміжне ПЗ має аналізувати потік вмісту сторінки PDF, щоб витягти текст, який потрібно обробити. Очевидно, такому ПЗ потрібен якийсь механізм для визначення початку й кінця слів — найочевидніше рішення полягає у використанні символу пробілу. З огляду на це, стандарти доступності вимагають, щоб окремі слова були чітко завершені (наприклад, символами пробілу), що є проблематичним для рушіїв TeX через використання міжслівного glue. #### Але не все втрачено! У 2014 році pdfTeX запровадив 2 нові примітиви, щоб поліпшити підтримку доступності, даючи змогу використовувати символи пробілу між словами в PDF, які він виводить: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Ці команди використовують «фіктивний шрифт», що містить лише гліф пробілу. Деталі та приклад можна знайти на сторінці 29 [посібника користувача pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Використання LuaTeX: приклад у галереї Overleaf LuaTeX не підтримує ці примітиви pdfTeX, але його можна запрограмувати так, щоб досягти результатів, дуже схожих на pdfTeX, використовуючи так званий механізм callback у LuaTeX. Проєкт Overleaf для перетворення glue на символи пробілу доступний у галереї Overleaf під назвою [Використання LuaTeX для перетворення міжслівного glue на пробіли та керни](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Якщо ви набираєте свій код LaTeX за допомогою LuaTeX (тобто з параметром компілятора LuaLaTeX на Overleaf), то, використовуючи код Lua, ви можете після набору обробити абзац, знайти будь-який міжслівний glue та замінити його символом пробілу плюс відповідний керн. Інтервал, який забезпечує ширина символу пробілу, можна додати (або зменшити), обчисливши відповідне значення керна, щоб зберегти величину інтервалу, яку забезпечував міжслівний glue, у результаті чого візуально набраний результат не зміниться. Щоб зрозуміти, яку різницю це має для користувачів програмного забезпечення для доступності, прослухайте цей звукозапис, зроблений за допомогою *Read Out Loud* функції. Він записує, як у тому проєкті вголос читаються два рядки тексту — до та після перетворення glue на пробіли. Зверніть увагу, як друге прочитання рядка, яке використовує пробіли, звучить швидко й плавно порівняно з рядком, що використовує міжслівний glue. Проєкт Overleaf — це файл plain TeX, скомпільований за допомогою LuaTeX і призначений лише для експериментального використання; він не задуманий як повноцінне рішення виробничої якості. Переважно він створений, щоб допомогти зрозуміти технічні питання, пов’язані з доступними PDF. Код Lua, використаний у цьому проєкті, ґрунтується на роботі, викладеній у значно ранішій статті Overleaf [Блоки та клей: короткий, але наочний вступ із використанням LuaTeX](/latex/uk/dokladni-statti/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Примітка: для простоти проєкт використовує власний дуже мінімальний завантажувач шрифтів OpenType, похідний від цього коду: . ### Інші проблеми доступності та тегований PDF Хоча тегування дає змогу ідентифікувати елементи вмісту, наявні в PDF, деякі типи вмісту, як-от графіка чи складна математика, потребують додаткових даних або інформації, якщо їх потрібно зробити доступними через програмне забезпечення, призначене для підтримки людей із порушенням зору. Щоб забезпечити й підтримати доступність для широкого спектра типів вмісту, специфікація PDF надає можливість приєднувати до елементів вмісту «Alternate Descriptions» або «ActualText», забезпечуючи відповідні текстові описи чи інші машинно-читані подання. Наприклад, для цієї мети у специфікації PDF 2.0 було визначено MathML. #### Це «справжній вміст» чи лише артефакт? Для людей із порушенням зору процес поділу й відображення вмісту у прямокутних фрагментах розміром зі сторінку має небажані побічні ефекти, такі як перенос слів. Крім того, аспекти дизайну чи макета сторінки, що використовуються для покращення візуального подання, є цілком беззмістовними для тих, хто не може цього бачити. З цих причин тегування PDF-вмісту має враховувати, що деякий вміст у PDF слід розглядати як *артефакт* візуального подання або пагінації. Наприклад, номери сторінок, верхні та нижні колонтитули, заштриховані фони чи інші елементи дизайну потрібно ідентифікувати, щоб програмне забезпечення для доступності, яке обробляє вміст, знало, що їх слід ігнорувати. ## Огляд стандартів PDF/A Запити на створення доступних PDF зазвичай посилаються на стандарт ISO під назвою [ISO 19005](https://www.iso.org/standard/38920.html), який частіше називають PDF/A. Однак, оскільки PDF/A є *сімейство* набором стандартів, просте прохання про «відповідність PDF/A» може не повністю визначати фактичні вимоги. Щоб зрозуміти чому, почнімо з короткого огляду PDF/A з [вебсайту PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (переглянуто 21 травня 2020 року), де ISO 19005 (PDF/A) описано так: > «Основна мета ISO 19005 — визначити файловий формат на основі PDF, відомий як PDF/A, який забезпечує механізм подання електронних документів у спосіб, що зберігає їхній статичний візуальний вигляд з плином часу, незалежно від інструментів і систем, використаних для створення, зберігання або візуалізації файлів. > > Другорядна мета ISO 19005 — визначити основу для подання логічної структури та іншої семантичної інформації електронних документів у файлах, що відповідають стандарту. > > Ще одна мета ISO 19005 — надати основу для запису контексту та історії електронних документів у метаданих у файлах, що відповідають стандарту». Очевидно, PDF/A має кілька ключових цілей. ### Еволюція та зростання PDF Функція [Специфікація PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) була опублікована 1993 року й містила лише 230 сторінок. Однак через 13 років специфікація для [версії PDF 1.7 від Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) перевищувала 1000 сторінок! З часом обсяг і складність специфікації PDF зростали завдяки розширенню підтримуваного набору можливостей: охопленню нових технологій і вимог дедалі складніших робочих процесів та сценаріїв використання PDF у різних ринках і спільнотах. Однак, імовірно, жоден користувач чи група користувачів ніколи не використовує всі можливості: PDF має «охоплювати всі варіанти», щоб обслуговувати потреби якомога ширшого ринку. Наприклад, багато функцій PDF, призначених для підтримки високоякісного комерційного друку, не потрібні для типового щоденного офісного використання як формату для зберігання чи обміну документацією. ### PDF/A: «повернення до основ» для PDF Основна мета PDF/A — забезпечити, щоб PDF, що відповідають стандарту, були придатні для довгострокового архівування або містили вміст, доступний людям, які використовують різні допоміжні технології для «споживання» цих PDF. Щоб досягти цих цілей, PDF/A обмежує набір функцій PDF, дозволених у файлах, що відповідають стандарту, забороняючи використання функцій, які могли б поставити під загрозу архівованість або доступність. PDF/A можна уявити як набір стандартів, які визначають, як PDF-файли, що відповідають стандарту, використовують *підмножина* частину повної специфікації PDF, щоб створювати файли, придатні для довгострокового архівування або забезпечення доступності їхнього вмісту. Обмеження PDF/A дають змогу використовувати PDF як «архівний цифровий папір», незалежний від технології читання PDF і обчислювального середовища, що використовується для доступу до їхнього вмісту. PDF, що відповідають стандарту, не повинні містити нічого, поведінка чого є «залежною від реалізації», тобто залежить від конкретного програмного забезпечення або операційних систем, які використовуються для перегляду чи обробки. PDF також мають бути *повними*: ключові ресурси документа мають бути вбудовані у файл — такі як шрифти або колірні профілі. ### Версії PDF/A та рівні відповідності Існують різні *версії* версії стандарту PDF/A, кожна з яких відображає певну версію формальної специфікації PDF (PDF 1.4, 1.7 і 2.0). Крім того, існують різні *рівні відповідності* які визначають, яким аспектам стандарту PDF/A відповідає PDF-файл. Відповідно, коли ви заявляєте або вимагаєте «відповідність PDF/A», слід думати про PDF-файли, що відповідають **PDF/A-** Наприклад * PDF/A-1a: означає версію PDF/A 1, рівень відповідності a * PDF/A-2b: означає версію PDF/A 2, рівень відповідності b Ми розглянемо це трохи докладніше. #### Версії PDF/A Стандарт PDF/A перебуває під егідою ISO і опублікований як стандарт під назвою ISO 19005. Як зазначалося, специфікація PDF з часом еволюціонувала, і це, своєю чергою, зумовило оновлення ISO 19005, що призвело до наведеної нижче таблиці: | | | | | ---------------- | ---------------- | --------------------------- | | **Версія PDF/A** | **Стандарт ISO** | **Базується на версії PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) | На момент написання (квітень/травень 2020 року) оновлений PDF/A-4 (ISO 19005-4) перебуває [на стадії підготовки](https://www.iso.org/standard/71832.html). #### Рівні відповідності PDF/A Окрім трьох версій PDF/A (PDF/A-1, PDF/A-2 і PDF/A-3), існують три *рівні відповідності*: * Рівень A (доступний) для доступності (включає вимоги до архівування рівня B) * Рівень B (базовий) для архівування * Рівень U (Unicode) (= архівування плюс використання Unicode для тексту) Ось короткий опис цих рівнів відповідності: * **Рівень B (базовий)** є мінімальною вимогою для відповідності PDF/A. Вона визначає вимоги, що забезпечують придатність PDF-документів, які відповідають стандарту, для довгострокового архівування — тобто щоб їх завжди можна було надійно переглядати або друкувати незалежно від конкретного програмного забезпечення, інструментів чи операційних систем. * **Рівень A (доступність)** включає вимоги відповідності рівня B, але додатково вимагає використання тегованого PDF для надання логічної структури та інформації про порядок читання, а також використання Unicode, щоб забезпечити доступ до тексту документа. * **Рівень U (Unicode)** рівень відповідності було додано до PDF/A-2, і він спирається на рівень B, додатково вимагаючи використання Unicode для тексту документа, але не заходить так далеко, як рівень A, оскільки не вимагає обов’язкової структурної інформації. Версії PDF/A та рівні відповідності можна підсумувати в таблиці: | | | | | | ------------------------ | ----------------------------- | -------- | -------- | | **Рівень відповідності** | **PDF/A-** | | | | Рівень A (доступний) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Рівень B (базовий) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Рівень U (Unicode) | Н/Д (не існувало для PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA («Універсальна доступність») Хоча відповідність рівня A стандарту PDF/A певною мірою визначає вимоги до доступних PDF, інший стандарт ISO під назвою [ISO 14289](https://www.iso.org/standard/64599.html), який називають PDF/UA, іде далі. PDF/UA посилює вимоги до доступності та уточнює настанови, що містяться у стандартах PDF/A, і став кращим стандартом для доступних PDF. #### Протокол Matterhorn Читачам, які глибоко цікавляться тим, щоб дізнатися більше про відповідність PDF/UA, може бути цікавий [Протокол Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) який є «списком усіх можливих способів не відповідати PDF/UA». ### Програмне забезпечення для валідації Щоб перевірити, чи відповідає PDF-файл певному стандарту, його потрібно *перевірити* за допомогою програмного забезпечення для перевірки відповідності, яке сканує PDF, щоб перевірити, чи відповідають його вміст і структура вимогам цього стандарту — таким як PDF/UA або PDF/A-*x*a (де *x* = 1, 2 або 3). Зверніть увагу, що валідація PDF — обробка їх за допомогою обраного інструмента валідації — може давати діагностичні повідомлення або попередження, які для недосвідченого користувача можуть бути досить незрозумілими — можливо, через деякі низькорівневі дані (або структуру) PDF, що не відповідають відповідному стандарту. Для багатьох авторів тлумачення цих попереджень і перетворення їх на дієве виправлення своїх документів може бути справжнім викликом. #### Безплатне програмне забезпечення для валідації * [veraPDF](https://verapdf.org/) який, якщо цитувати їхній сайт (переглянуто 28 травня 2020 року), є «спеціально створеним валідатором формату файлів з відкритим кодом, що охоплює всі частини PDF/A та рівні відповідності». * (лише Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) який є «...безплатним інструментом перевірки доступності PDF, що був випробуваний і протестований з 2010 року». #### Комерційне програмне забезпечення для валідації * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) надає набір тестів для валідації PDF разом з інструментами для редагування й виправлення тегів у PDF-файлах, що не відповідають стандарту. ### PDF Association: чудове джерело інформації Функція [PDF Association](https://www.pdfa.org/) створює багато *чудову* ресурсів про PDF/A, PDF/UA та багато інших тем, пов’язаних із PDF, зокрема відео на їхньому [каналі YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) разом зі статтями та безплатними технічними публікаціями, доступними на їхньому вебсайті. Однією з таких публікацій є [PDF/UA в двох словах](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) яка дає безцінний вступ до стандарту PDF/UA та його вимог. ## Доступні PDF з рушіїв TeX і LaTeX Сподіваємося, попередні обговорення показали, що створення повністю доступних і правильно тегованих PDF-файлів є складним технічним викликом. Ба більше, навіть простий приклад Microsoft Word продемонстрував, що автори можуть дуже легко використовувати комбінації функцій програмного забезпечення, які призводять до тегованих PDF-документів, що не відповідають критеріям доступності. Як інструмент для авторювання, LaTeX надає авторам майже необмежену гнучкість у діапазоні та складності документів, які можна створювати, — можливо, саме тому його й обирають. LaTeX також підтримує розширюваність завдяки тисячам додаткових пакетів, які автори можуть використовувати як частину своїх документів. До того ж автори мають свободу писати нові макроси TeX або LaTeX чи перевизначати наявні, щоб досягати певних ефектів. Однак, можливо, за цю свободу та гнучкість доводиться платити, адже вміст, що створюється незліченними взаємодіями всіх цих пакетів і макросів LaTeX, «якось» потрібно координувати, якщо LaTeX має автоматично генерувати правильно тегований і доступний PDF-вивід. На практиці розширюваність, потужність, універсальність і авторська «свобода», які надає LaTeX, створюють технічні виклики для безперебійного й прозорого («автоматичного») створення повністю доступних тегованих PDF-документів, що відповідають стандартам PDF/UA або PDF/A-{1|2|3}a. Ширша спільнота TeX і LaTeX докладає значних зусиль, щоб подолати ці виклики, а TeX User Group (TUG) координує дослідницькі та розробницькі зусилля через робочу групу з доступності PDF і стандартів PDF [робочу групу](https://www.tug.org/twg/accessibility/). Існує [список розсилки для обговорення](https://tug.org/mailman/listinfo/accessibility) який дає зацікавленим сторонам змогу обговорювати створення тегованих PDF-файлів за допомогою TeX і LaTeX. У цих обговореннях варто пам’ятати, що LaTeX насправді не є виконуваною програмою для верстки; це велика колекція складних макросів (команд), написаних нижчорівневою мовою під назвою TeX. Між ретельно створеним документом LaTeX і фінальним набраним PDF стоїть програмне забезпечення, що називається рушієм TeX, чия робота — «виконувати» набір команд LaTeX (тобто макросів), які використовуються для написання й побудови вашого документа, перетворюючи їх на набране подання вашого документа, збережене як PDF-файл. Тих, хто новий у екосистемі TeX/LaTeX, часто, і цілком зрозуміло, збиває з пантелику безліч загадково звучних назв, які використовуються для інструментів, з якими вони стикаються: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX і LuaLaTeX. Якщо ви почуваєтеся так само, допомога поруч у статті Overleaf [Що в назві: путівник багатьма варіантами TeX](/latex/uk/dokladni-statti/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) яка пояснює походження та значення всіх цих термінів. Рушії TeX, такі як pdfTeX, XeTeX або LuaTeX, належать до класу програмного забезпечення, що називається *компіляторами документів*: вони беруть ваш код LaTeX і компілюють його в набрану форму, «перетворюючи» макроси LaTeX (команди) назад у їхні низькорівневі інструкції мови TeX, які «виконуються» для отримання набраного результату. Системи верстки на базі TeX здатні створювати надзвичайно складний вміст — зокрема просунуту математику, музичну нотацію, хімічні структури, графіку та складний багатомовний набраний текст. Щоб такі складні документи відповідали стандартам і нормам доступності, рушіям TeX разом із колекцією макросів LaTeX та пакетами LaTeX потрібно генерувати належним чином теговані PDF-файли, вбудовуючи у створювані ними PDF-файли велику кількість додаткових даних. Хоча рушії TeX можуть генерувати надзвичайно складні PDF-файли, їхні внутрішні процеси, алгоритми та функції не мають *вбудовану* функцій *спеціально призначених* для підтримки створення тегованих і доступних PDF. Натомість підтримку тегування та доступності потрібно забезпечувати за допомогою складного програмування макросів, яке «впорскує» додаткові дані в PDF, згенеровані рушіями TeX, — створюючи послідовності позначеного вмісту, елементи структури та структури даних логічної структури, що зберігаються в `StructTreeRoot`. І саме тут ця «координація» постає особливо виразно: код у ядрі (kernel) LaTeX разом із кодом у тисячах пакетів і незліченних створених авторами макросах мав би дуже ретельно співпрацювати, щоб виконання макросів забезпечувало правильне тегування вмісту документів, що в результаті створюються. Така «координація» мала б бути надійною — незалежно від того, як автори вирішують поєднувати й використовувати функції, команди та можливості LaTeX, його систему пакетів і силу макросів TeX. ### Потреби авторів Для більшості людей LaTeX — це просто інструмент, який дає змогу створювати красиво набрані документи, маючи свободу вибирати пакети, щоб допомогти цього досягти. Переважна більшість авторів LaTeX просто хоче, щоб їхні документи «працювали»: набиралися без помилок, щоб можна було подати дисертацію, статтю, звіт або завершити ту довгоочікувану книгу. І це цілком зрозуміло: користувачі LaTeX очікують, що обрана ними сукупність пакетів LaTeX мирно співіснуватиме, безшовно та прозоро взаємодіючи, щоб надавати команди й функції, необхідні для створення їхніх документів. Такі самі очікування, ймовірно, виникають і тоді, коли постає вимога створювати тегований PDF з LaTeX: це має «просто працювати», прозоро й із мінімальним втручанням автора. На жаль, ми ще далекі від досвіду «Хей-престо! тегування просто відбувається, що б я не робив». Поєднання технічних вимог доступності та тегованого PDF із LaTeX і свободою автора є за своєю природою складним, і, можливо, неминуче, що може знадобитися певна форма «дисципліни автора», якщо технічні виклики мають стати придатними для практичної реалізації та розв’язання. Окрема, але пов’язана проблема полягає в тому, що неправильне тегування може не мати жодного візуального впливу на фінальний PDF: візуально він може виглядати ідеально й, імовірно, без проблем друкуватиметься, але невідомо для автора тегування може бути «зламане»; це виявиться лише під час подальшого провалу перевірок відповідності/валідації PDF/A та/або додаткового практичного тестування за допомогою програм доступності, таких як читачі екрана. ### PDF-файли, створені на Overleaf Overleaf надає своєму користувацькому співтовариству браузерний редактор LaTeX разом з інструментами керування проєктами та документами, які полегшують спільне авторювання — усе це побудовано поверх стандартної інсталяції TeX Live. Фактично, Overleaf дає користувачам змогу «запускати LaTeX на відстані» через веббраузер, забезпечуючи шар захисту від складнощів керування та підтримання повної системи TeX Live. Наслідком використання Overleaf стандартної інсталяції TeX/LaTeX є те, що PDF, створені з коду LaTeX, написаного в редакторі Overleaf, генеруються з використанням тих самих технологій, що й у будь-якій іншій інсталяції TeX Live тієї самої версії — включно з налаштуваннями, встановленими користувачами на локальних пристроях. Єдина відмінність полягає в тому, що рушії TeX, які компілюють і обробляють код LaTeX у Overleaf, працюють на віддалених серверах, а не на локальних машинах. Overleaf дійсно лінеаризує PDF, згенерований TeX, для ефективного завантаження/відображення в браузері, але цей процес не пов’язаний із доступністю самого PDF-вмісту. Створення доступних PDF через Overleaf спирається на можливості та функції, вбудовані в стандартні рушії TeX, а також на наявність відповідних пакетів макросів LaTeX, які користувачі можуть застосовувати як частину свого документа. Документи LaTeX, створені в Overleaf, мають залишатися сумісними з іншими інсталяціями TeX і LaTeX, тому що користувачам часто потрібно експортувати свій проєкт LaTeX з Overleaf для подання до різних видавничих і журнальних систем. Додавання специфічних для Overleaf функцій до його документів LaTeX або до базових рушіїв TeX серйозно обмежило б свободу користувачів використовувати свою роботу деінде. Overleaf визнає та підтримує потребу в повністю доступних PDF, згенерованих системами авторювання TeX/LaTeX: ми інвестуємо час у дослідження проблем доступності, вивчення найновіших розробок у рушіях TeX і експериментальних пакетах LaTeX, які підтримують тегований PDF. Зрештою, на момент написання немає готового «з коробки» рішення, яке автори LaTeX могли б використовувати (через `\usepackage`) для безшовного й прозорого створення повністю доступних PDF, що відповідають PDF/UA, з типових документів LaTeX. Коли такі рішення стануть доступними через оновлення TeX Live, вони, звісно, стануть доступними й для спільноти користувачів Overleaf. ### Деякі пакети LaTeX для дослідження тегування та доступності Для багатьох людей, [tex.stackexchage](https://tex.stackexchange.com/) є першим місцем, куди звертаються по допомогу з TeX, LaTeX або ConTeXt. Це дивовижний ресурс, і там є багато запитань на тему [доступності](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) та створення доступних PDF через LaTeX. Якщо читати й переглядати ці запитання, а також наступний потік відповідей і коментарів, неминучим є лише один висновок: на цей момент не існує повного, виробничого рішення для автоматичного створення повністю доступних, стандартизованих, тегованих PDF з будь-якого типу документа LaTeX. Однак є деякі пакети, які підтримують тегування — хоча, можливо, у обмеженому колі сценаріїв використання та типів документів. Наведений нижче список призначений для читачів, які хочуть дослідити тегування PDF на основі LaTeX: * [`tagpdf` accents](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): надзвичайно потужний пакет, створений для експериментів із тегуванням PDF. Підтримує pdfTeX і LuaTeX та надає надзвичайно корисну й цікаву документацію, яка містить чудові нотатки про технічні виклики створення тегованих PDF через рушії TeX; його дуже рекомендовано прочитати всім, хто хоче краще зрозуміти пов’язані питання. Ймовірний майбутній напрям — LuaTeX. * [`axessibility` accents](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov і Університет Турина): забезпечує доступ до формул у PDF-файлах за допомогою допоміжних технологій. * [`доступності` accents](https://ctan.org/pkg/accessibility) (Andy Clifton): створює теговані та структуровані PDF-файли. У примітках CTAN зазначено, що цей пакет «орієнтований на користувачів класів документів KOMA-Script». * [`accsupp` accents](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): експериментальний пакет для кращої підтримки доступності PDF-файлів. Ще одне варте уваги джерело — стаття 2018 року [Implementing PDF standards for Mathematical Publishing](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) авторства д-ра Росса Мура з факультету математики Університету Маккуорі. У цій статті д-р Мур коротко окреслює виклики тегування PDF у LaTeX: > «Основне джерело труднощів полягає в тому, як різні середовища можуть взаємодіяти одне з одним. У LaTeX є багато ситуацій, коли одне середовище чи структура фактично не завершені, доки не розпочалося наступне. Тож справа не просто в тому, щоб обгорнути кожен наданий фрагмент вмісту початковими й кінцевими тегами. Натомість потрібно розуміти тонкощі того, як різні середовища та інші структури насправді починаються й завершуються в контексті, створеному навколишнім матеріалом». Д-р Мур також є нинішнім супроводжувачем [`pdfx`](https://ctan.org/pkg/pdfx) пакета, а також експертом і піонером тегованого PDF з використанням TeX/LaTeX. Його роботи варто пошукати — зокрема й це відео на YouTube, яке дає цікаві уявлення: {% embed url="" %} #### Примітка щодо пакета pdfx Функція [`pdfx`](https://ctan.org/pkg/pdfx) пакет (Ross Moore et al) забезпечує чудову підтримку PDF/A-1|2|3b (архівування) та інших параметрів, але поки що не створює тегований 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://ayakaleaf-pro.ayaka.space/latex/uk/inshi-temi/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.