> 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/ru/drugie-temy/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, соответствующий уровню AA WCAG 2.1, следуя [нашей пользовательской документации](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 и дополнительных пакетов 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) включали появление «размеченного PDF», который [«...позволил пользователям вспомогательных технологий»](https://www.adobe.com/accessibility/pdf.html). Последующие выпуски спецификации PDF расширяли и совершенствовали возможности PDF, кульминацией чего стал последний выпуск (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/426bddfcf740443e2c1cc1a0cf34ac5309fc59dc) Если извлечь (распакованный) поток содержимого страницы для этого файла и вставить первые несколько строк в текстовый редактор, мы сможем кратко описать некоторые операторы PDF, чтобы получить представление о том, как файлы PDF «описывают» содержимое, отображаемое на этой странице. ![Изображение потока содержимого в файле PDF](/files/8770b8ea1ae9c10cfce4c3434c7dd8ecfd4e1c6f) Если у вас есть доступ к Adobe Acrobat Pro DC, вы можете использовать его, чтобы перечислить операторы, содержащиеся в потоке содержимого страницы PDF. Вот представление Acrobat *Внутренняя структура PDF* по тому же PDF, которое любезно предоставляет однострочное описание каждого оператора, используемого для «рисования» нашей одной страницы с простой таблицей — обратите внимание, эти краткие описания предоставлены Adobe Acrobat Pro DC, они *не* присутствуют в самом файле PDF: ![Изображение потока содержимого PDF, просмотренного в Adobe Acrobat Pro DC](/files/c764d83040e1ede3b444be445e38791cdaf5566b) Однако обратите внимание, что ни одна из этих инструкций рисования (операторов) не хранит никакого «смысла» или «описания» того, что они на самом деле создают: это всего лишь набор графических операторов, в результате которых формируется то, что *видящий наблюдатель распознаёт* как таблицу. Очевидно, для людей с тяжёлыми нарушениями зрения отображение таблицы, получающейся из этих графических операторов в потоке содержимого 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/1fdbe752b8a7bc1c079262cf5303521531c6ec62) Через форму родительско-дочерней связи данных наборы элементов структуры объединяются для создания связанных структур данных, представляющих более сложные элементы данных, такие как нумерованные и маркированные списки, таблицы, математика и так далее. В конечном счёте весь набор элементов структуры, содержащихся во всём PDF-файле, также связывается между собой и объединяется для создания логической структуры PDF-документа — мы вернёмся к этому позже в статье. ### Что такое последовательность помеченного содержимого? В обсуждении выше мы использовали простой PDF-документ без тегов, содержащий таблицу (созданную в Microsoft Word), но если мы попросим Word создать размеченный PDF, мы увидим, что в потоке содержимого страницы появится дополнительная разметка. Здесь мы рассматриваем только первые несколько строк потока содержимого (там сотни строк), но обратите внимание на наличие дополнительных операторов, таких как `/P <> BDC` и `EMC` которые используются для идентификации последовательности помеченного содержимого. Мы не будем разбирать полный синтаксис последовательностей помеченного содержимого, но отсылаем читателя к странице 862 [официальной спецификации Adobe PDF 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Изображение, показывающее последовательности помеченного содержимого в потоке содержимого размеченного PDF](/files/68c3f7da93790ba0e6371a529f2355c3a39cb227) Для удобства снова покажем версию без тегов: ![Изображение, показывающее поток содержимого PDF](/files/8770b8ea1ae9c10cfce4c3434c7dd8ecfd4e1c6f) В *без тегов* PDF, операторы, такие как `/P <> BDC` и `EMC` отсутствуют, но остальные операторы не изменились: PDF без тегов лишён дополнительной разметки, используемой для идентификации определённых последовательностей/наборов операторов. Снова мы также можем использовать функцию Adobe Acrobat *Внутренняя структура PDF* для просмотра последовательностей помеченного содержимого внутри потока содержимого — здесь мы выделили их зелёной рамкой: ![Изображение, показывающее последовательности помеченного содержимого в потоке содержимого размеченного PDF, просмотренном в Adobe Acrobat Pro DC](/files/22ea6a0820d9b81bf2a3ca15b9c71fc209ac6809) Обратите внимание, что некоторые фрагменты содержимого помечены `/Artifact` что обозначает материал на странице PDF, который должен быть *проигнорирован* программами вспомогательного ПО, такими как те, что зачитывают вслух текст людям с нарушениями зрения. Следующий снимок экрана показывает расширенное представление первой последовательности помеченного содержимого — той, у которой `MCID` значение `0`. Конец последовательности помеченного содержимого определяется оператором PDF `EMC`. ![Изображение, показывающее детали операторов, охватываемых последовательностью помеченного содержимого](/files/6fb3732f5a3af368ff7cdcf19644c98111367ca4) ### Хранение логической структуры Как отмечалось, помимо предоставления описания отдельных элементов содержимого (абзацев, списков, таблиц и т. д.), для доступных PDF необходимо содержать представление всего документа в форме его логической структуры. Отдельные фрагменты доступного содержимого должны быть связаны между собой, чтобы создать полный, удобный для навигации и доступный документ — подобно тому, как отдельный HTML-документ строится из абзацев, графики, таблиц, чтобы создать веб-страницу. Более того, крайне важно, чтобы логическая структура PDF-документа обеспечивала возможность перехода ко всему содержимому в правильном *порядке чтения*, независимо от порядка, в котором содержимое страницы было записано в потоки содержимого страницы PDF. Мы подробнее рассмотрим порядок чтения ниже. #### Логическая структура: «дерево» элементов структуры Мы отметили, что PDF используют нечто под названием *элемент структуры* для представления отдельных элементов содержимого, и что элемент структуры содержит тег для идентификации того, какой тип содержимого он представляет. Чтобы представить логическую структуру документа, все элементы структуры связываются между собой с помощью отношений родитель—потомок и организуются в «дерево структуры». Внутри размеченных PDF-файлов содержится объект под названием `StructTreeRoot` который содержит (указывает на) элементы структуры, выступающие в качестве отправной точки или «корня» дерева логической структуры документа. Обычно «корень» дерева структуры начинается с одного элемента структуры, помеченного `Document` который содержит многочисленные *дочерние* элементы структуры, которые в совокупности представляют всё содержимое документа. Любому программному обеспечению, предназначенному для создания доступных PDF посредством разметки, приходится строить эту очень сложную структуру данных (и не только её!) — а это включает движки TeX и LaTeX. Пример такого дерева структуры документа (`StructTreeRoot`) показан на следующем снимке экрана размеченного PDF, открытого в Adobe Acrobat Pro DC: ![Изображение, показывающее StructTreeRoot в размеченном PDF](/files/d295254032169c862b91b93046079521c30fe8c0) Сравните приведённую выше структуру с версией PDF без тегов: ![Изображение, показывающее отсутствие StructTreeRoot в PDF без тегов](/files/1a08a81ee8decfece578580121edd2714889a8a9) ### Изучение логической структуры PDF Мы начнём с нескольких графических иллюстраций, чтобы подытожить то, что мы рассмотрели, и завершим видео, которое использует Adobe Acrobat Pro DC, чтобы показать больше деталей логической структуры файла размеченного PDF. Сначала приведём схему, показывающую общие принципы: страница PDF с потоком содержимого, размеченным последовательностями помеченного содержимого (MCS). ![Графика, показывающая концепцию последовательностей помеченного содержимого на страницах PDF-документа](/files/bb43dfd27c0e25fa2c65f6d0bd975750885ec464) Затем эти MCS объединяются в *элементами структуры* которые служат основой для более крупных типов содержимого, которые, в свою очередь, далее связываются между собой для хранения логической структуры PDF внутри объекта под названием `StructTreeRoot`. ![Графика, показывающая логическую структуру размеченного PDF-файла](/files/33f11b3e777896ac0352958a19d70b292de06476) #### Видео, показывающее логическую структуру размеченного 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](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. text 2. table 3. графика При записи в PDF программа, создающая поток содержимого для этой страницы, могла бы начать с операторов для рисования таблицы, затем вывести операторы для создания графики, после чего — операторы для текста, что в потоке содержимого привело бы к *порядку содержимого* порядок: 1. table 2. графика 3. text Конечно, при просмотре страницы всё будет размещено в правильных позициях. Для полностью зрячего читателя порядок, в котором эти элементы хранятся внутри потока содержимого страницы, не имеет значения: он видит полностью отрисованную страницу, где всё находится на своём месте. Однако если вспомогательное ПО будет вынуждено полагаться на порядок элементов в потоке содержимого (порядок содержимого), оно столкнётся с трудностями, если порядок содержимого отличается от естественного порядка чтения; например, инструменты озвучивания прочитают материал в неправильной последовательности. К счастью, вспомогательное ПО может использовать логический порядок (структуру) размеченного 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/1ad1f6c18286554094f7e2314586476255cfb787) Если мы попросим Word сохранить этот документ в PDF с помощью встроенного экспорта — не плагина Acrobat PDFMaker — мы можем указать ему создать тегированный PDF: ![Диалоговое окно параметров процесса экспорта Microsoft Word](/files/fe82e02fa3c9e2f1027ebdc33048e91b04641ebe) Итак, как Word размечает этот макет? В следующем очень коротком видео (14 секунд) мы используем Adobe Acrobat Pro DC, чтобы проверить структуру тегов, созданную Microsoft Word. {% embed url="" %} Для этого документа Word создал тегированный PDF-документ, который использует `Table` тег, содержащий два под-тега: `THead` для группы строк заголовка таблицы и `TBody` для представления группы строк тела таблицы. `THead` и `TBody` оба содержат `TR` теги для представления отдельных строк содержимого. `TR` Теги содержат дополнительные теги для представления нумерованного элемента списка, присутствующего в каждой ячейке. Следующее изображение экрана показывает глубоко вложенную структуру тегирования и соответствующую сложную логическую структуру, необходимую для представления даже этого крайне простого документа! ![Изображение, показывающее глубоко вложенную структуру тегирования и логическую структуру простой таблицы, созданной в Microsoft Word](/files/0654514d9bba3dca6efe1c64b08e05c3d25573b9) По сравнению с 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/b425212abb6d07f292059ad22b0767d552a961e8) Как отмечалось выше, этот пример несколько искусственный, но он действительно показывает, насколько легко сочетания программных функций могут вызывать проблемы с доступностью — но как автор документа должен заранее об этом знать? Вероятно, эта проблема была бы обнаружена только в том случае, если бы полученный PDF прошёл практические тесты на доступность — например, с использованием вспомогательного программного обеспечения. Потенциально такие документы могли бы пройти тесты на соответствие/валидацию PDF/A, но провалиться в «реальном» использовании. Обеспечение правильного порядка чтения такого PDF-файла потребовало бы квалифицированного ручного вмешательства с использованием продвинутых инструментов редактирования PDF, таких как Adobe Acrobat Pro DC: трудоёмкого и дорогостоящего процесса. В качестве альтернативы автор документа мог бы отказаться от использования именно такой формы выражения содержимого или макета — но только если бы он знал, что это проблематично! ### Использование пробельных символов для разделения слов Когда вы вводите текст в текстовых процессорах или редакторах текста, вы используете пробел для обозначения конца одного слова и начала следующего. Если затем вы создаёте PDF из такого документа, введённые вами пробельные символы, разумеется, будут выведены и станут частью текста, хранящегося в PDF. Однако движки TeX не используют пробельные символы для разделения слов в набранном тексте; вместо этого они преобразуют пробельные символы в форму гибкого промежутка, называемую glue (см. эту [статью Overleaf](/latex/ru/podrobnye-stati/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) для получения дополнительной информации о коробках и glue в TeX). Внутри потока содержимого страниц 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, в результате чего визуально набранный результат не изменится. Чтобы понять, какую разницу это создаёт для пользователей программ обеспечения доступности, послушайте эту аудиозапись, полученную из функции Adobe Reader DC *Read Out Loud* Она записывает чтение вслух двух строк текста в том проекте до и после преобразования glue в пробелы. Обратите внимание, как второе прочтение строки, использующее пробелы, звучит быстро и плавно по сравнению со строкой, использующей межсловный glue. Проект Overleaf представляет собой файл plain TeX, компилируемый с помощью LuaTeX, и предоставляется только для экспериментального использования; он не предназначен для полноценного, производственного решения. В первую очередь он предназначен для помощи в понимании технических проблем, связанных с доступными PDF. Код Lua, использованный в этом проекте, основан на работе, содержащейся в гораздо более ранней статье Overleaf [Боксы и клей: краткое, но наглядное введение с использованием LuaTeX](/latex/ru/podrobnye-stati/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Примечание: для простоты проект использует собственный очень минимальный загрузчик шрифтов OpenType, созданный на основе этого кода: . ### Другие проблемы доступности и тегированный PDF Хотя тегирование позволяет идентифицировать элементы содержимого, присутствующие внутри PDF, некоторые типы содержимого, такие как графика или сложная математика, требуют дополнительных данных или информации, если их нужно сделать доступными через программное обеспечение, предназначенное для поддержки людей с нарушениями зрения. Для обеспечения и поддержки доступности для широкого спектра типов содержимого спецификация PDF предоставляет возможность прикреплять к элементам содержимого «альтернативные описания» или «ActualText», обеспечивая подходящие текстовые описания или другие машиночитаемые представления. Например, MathML был назначен для этой цели в спецификации PDF 2.0. #### Это «реальное содержимое» или просто артефакт? Для людей с нарушениями зрения процесс разбиения и отображения содержимого на прямоугольные фрагменты размером со страницу имеет нежелательные побочные эффекты, такие как перенос слов с дефисом. Кроме того, аспекты дизайна страницы или макета, используемые для улучшения визуального представления, совершенно бессмысленны для тех, кто не может их видеть. По этим причинам при тегировании содержимого 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-файлах, запрещая использование функций, которые могли бы поставить под угрозу архивируемость или доступность. 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 («Universal Accessibility») Хотя соответствие уровня 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 in a Nutshell](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/ru/podrobnye-stati/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 для отправки в самые разные издательские журнальные системы. Введение в документы LaTeX функций, специфичных для Overleaf, или в базовые движки 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` пакет](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): очень мощный пакет, предназначенный для экспериментов с тегированием PDF. Поддерживает pdfTeX и LuaTeX и предоставляет чрезвычайно полезную и интересную документацию, содержащую отличные заметки о технических проблемах создания тегированных PDF через движки TeX; это настоятельно рекомендуемое чтение для всех, кто хочет лучше понять связанные вопросы. Вероятное направление дальнейшего развития — LuaTeX. * [`axessibility` пакет](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov and University of Turin): обеспечивает доступ к формулам в PDF-файлах с помощью вспомогательных технологий. * [`доступности` пакет](https://ctan.org/pkg/accessibility) (Andy Clifton): создаёт тегированные и структурированные PDF-файлы. В примечаниях CTAN указано, что этот пакет «ориентирован на пользователей классов документов KOMA-Script». * [`accsupp` пакет](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): экспериментальный пакет для улучшения поддержки доступности PDF-файлов. Ещё одной заслуживающей внимания ссылкой является статья 2018 года [Реализация стандартов PDF для математических публикаций](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/ru/drugie-temy/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.