> 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/zh-cn/geng-duo-zhu-ti/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # 标记 PDF 文件导论：内部结构与可访问性挑战 ## 更新：2026年1月 请参见 [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). 现在，只需按照 [我们的用户文档](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) 中针对 Overleaf 所提供的 TeX Live 版本，便可从 LaTeX 源文件生成符合 WCAG 2.1 AA 级的带标签 PDF。 下面这篇 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) 探索由 LaTeX 生成的带标签 PDF； * [一个 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 在 20 世纪 90 年代初作为解决可靠文档传输问题的方案而出现，历史证明它取得了巨大成功。然而，PDF 也是一种复杂的文件格式，它诞生于人们广泛认识并接受需要促进文档内容可访问性之前。不过，随着时间推移，PDF 规范不断演进，提供了能支持以一种 Adobe 称为 *带标签 PDF*. 在实践中，生成带标签——*且完全可访问的*——PDF 文件，会给输出 PDF 的软件带来额外且重要的技术要求，而这也包括 TeX 引擎以及 LaTeX 的宏和附加 LaTeX 宏包生态系统。 ## 作为最终成品的数字纸张的 PDF 的起源 该 [可移植文档格式（PDF）的起源](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) 可追溯至一个文档在计算机之间传输充满困难的时代；这些困难往往由文件转换引起，导致页面重排，以及不同操作系统（尤其是 Windows 和 Macintosh）所使用的不兼容字体和文本编码所带来的其他差异。本文作者当时在出版行业工作，对应对这些挑战有着鲜活的记忆！ PDF 的设计初衷是通过引入一种通用的、最终成品形式的（不可编辑）数字纸张来解决文件共享问题，从而允许无缝传输自包含的文档，这些文档携带显示它们所需的字体。用户终于可以相对有把握地传递各种文档，接收者无论使用何种计算平台，都能打开并阅读它们——文档保真度得以保留，繁琐的页面重排、字体兼容性/可用性问题也成了过去式。 ### 数字纸张：对所有用户都好吗？ 作为一种数字纸张，PDF 的渊源自然默认使用印刷页码、排版或设计元素作为在屏幕上或纸面上视觉导航内容的线索。然而，当然，这些视觉线索/机制对严重视力障碍者毫无意义。如今，提高数字内容的可访问性理所当然地被视为内容制作和传播的重要方面。PDF 面临的挑战是提供机制，以便对原本设计为复制印刷页面视觉媒介的“容器”中锁定的内容进行非视觉访问。 PDF 规范的第一个版本（PDF 1.0）于 [1993 年 6 月 15 日正式发布](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/)，其可访问性功能已大幅改进——尽管 TeX 引擎对 PDF 2.0 的支持仍不完善。 ## PDF 中的内容 要理解其中涉及的问题，值得研究 PDF 文件实际上如何表示其包含的页面内容。深入到 PDF 文件内部，每一页的内容位于该页的 *内容流*：一系列 PDF 运算符（“命令”），它们在页面的特定位置放置文本或图形，以供用于 *查看* 该 PDF 的软件进行渲染（显示）。实际上，内容流提供了一种图形描述或“配方”，告诉 PDF 查看应用程序如何“绘制”每一页——定义页面上要显示什么，以及显示在哪里。自然地，这一系列运算符包括选择特定字号的字体、选择颜色、定义线宽、绘制线条、曲线等等的指令——提供页面视觉呈现所需的完整图形描述的一切。 为减小文件大小，PDF 内容流会被压缩并以紧凑的二进制格式存储；但如果你能使用合适的软件，例如 Adobe Acrobat Pro DC，就可以用它查看页面内容流的“解压”纯文本版本。 让我们考虑 PDF 运算符如何“绘制”一个表格：PDF 内容流将包含适当的运算符序列，用于生成水平/垂直线条，选择不同字体，并输出放置在页面不同位置的文本，从而形成表格内容。为了演示这一点，让我们考虑一个非常简单的未加标签 PDF 文档，它除了一个带有一些文本的基本表格之外别无他物——这个文档是在 Microsoft Word 中创建的，原因会在本文后面变得明显。下面是显示我们这个简单 PDF 的截图： ![在 Microsoft Word 中创建的表格](/files/cc6318bdf36b71dc658a6099b6d67cc8797851bb) 如果我们提取这个文件（解压后的）页面内容流，并将前几行粘贴到文本编辑器中，我们可以对一些 PDF 运算符进行总结，从而感受一下 PDF 文件如何“描述”此页面上显示的内容。 ![PDF 文件中内容流的图像](/files/c730b233d669a2e22e453f1947d74965768fbd18) 如果你能访问 Adobe Acrobat Pro DC，就可以用它列出 PDF 页面内容流中包含的运算符。下面是 Acrobat 的 *PDF 内部结构* 视图，它贴心地为用于“绘制”我们这张包含基本表格的单页的每个运算符都提供了一行描述——请注意，这些简短描述由 Adobe Acrobat Pro DC 提供，它们 *不* 本身并不在 PDF 文件中： ![在 Adobe Acrobat Pro DC 中查看的 PDF 内容流图像](/files/8b75b09a2baf5c36f2086ca15b3c560703e0d20b) 然而，请注意，这些绘制指令（运算符）都没有存储它们实际生成内容的任何“含义”或“描述”：它们只是一组图形运算符，其结果构成了一个 *旁观者会识别为* 表格的内容。显然，对于严重视力障碍者来说，显示 PDF 内容流中的这些图形运算符所生成的表格并不是访问该内容的可行方法。所需要的是一种机制，让 PDF 文件包含对该表格以及 PDF 文件页面内所有其他内容项的合适非视觉（机器可读）描述。 为了实现对内容的非视觉访问，PDF 文件需要包含额外数据，用于将“含义”或语义附加到正在用于“绘制”特定内容片段的运算符集合或组上。必要地，这种赋予或提供“含义”的原则必须扩展到 PDF 中包含的所有形式的内容：这种机制确实存在，称为 *加标签* 该 PDF，从而生成一种称为、顾名思义， *带标签 PDF*. ## 介绍带标签 PDF 带标签 PDF 是指一种特定类型的 PDF 文件，其中包含未加标签 PDF 文件中没有的额外数据（以及数据结构）。尽管带标签 PDF 背后的原理/思想可以用概述方式描述，但完整细节很复杂，在正式的 PDF 规范中占据了很多页。 Adobe 设计带标签 PDF 的目的包括让内容对视力障碍用户可访问，但它也涵盖了以下内容，这段摘自 [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/8675391a26a01ef084b3f7d940955df7de5b816b) 通过一种父—子数据关系，结构元素集合被组合起来，形成链接的数据结构，用以表示更复杂的数据项，如编号和项目符号列表、表格、数学等等。最终，整个 PDF 文件中包含的所有结构元素集合会进一步链接并组合起来，构成 PDF 文档的逻辑结构——我们会在本文后面再回到这一点。 ### 什么是标记内容序列？ 在上面的讨论中，我们使用了一个包含表格的简单未加标签 PDF 文档（在 Microsoft Word 中创建），但如果我们指示 Word 创建带标签 PDF，就会看到页面内容流中出现了一些额外标记。这里，我们只考虑内容流的前几行（总共有数百行），但请注意存在诸如 `/P <> BDC` 和 `EMC` 等附加运算符，它们用于识别一个标记内容序列。我们不会探讨标记内容序列的完整语法，但建议读者参见 [Adobe 官方 PDF 1.7 规范](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![显示带标签 PDF 内容流中标记内容序列的图像](/files/98f75e43669e91a37ce87673cea51f697811cd88) 为便于参考，我们再次展示未加标签版本： ![显示 PDF 内容流的图像](/files/c730b233d669a2e22e453f1947d74965768fbd18) 在 *未加标签的* PDF 中，诸如 `/P <> BDC` 和 `EMC` 缺失，但其余运算符保持不变：未加标签 PDF 缺少用于识别某些运算符序列/集合的额外标记。同样，我们也可以使用 Adobe Acrobat 的 *PDF 内部结构* 用于查看内容流中标记内容序列的功能——这里，我们用绿色边框将它们高亮显示： ![在 Adobe Acrobat Pro DC 中查看的带标签 PDF 内容流中标记内容序列的图像](/files/6eb3c269b583e73ac5a71bf06f5f38d9d4bc8287) 请注意，某些内容片段标记为 `/Artifact` ，它用于标识 PDF 页面上应该被 *忽略* 的材料，供辅助软件应用程序使用，例如那些为视障人士朗读内容的软件。 下面的截图展示了第一个标记内容序列的展开视图——即那个值为 `MCID` 值为 `0`0 `EMC`. ![标记内容序列结束由 PDF 运算符所标识的图像](/files/d1716056f1fc13db915f55f7e47d9d5ece88b2f3) ### 存储逻辑结构 如前所述，除了为单个内容项（段落、列表、表格等）提供描述之外，可访问 PDF 还需要包含整个文档的表示，形式即其逻辑结构。各个可访问内容片段必须链接起来，形成一个完整、可导航且可访问的文档——类似于单个 HTML 文档由段落、图形、表格构成网页。此外，PDF 文档的逻辑结构必须确保所有内容都能按照正确的 *阅读顺序*进行导航，而不受页面内容写入 PDF 页面内容流的顺序影响。我们将在下文更详细地探讨阅读顺序。 #### 逻辑结构：结构元素的“树” 我们注意到，PDF 使用一种称为 *结构元素* 的东西来表示单个内容项，而且结构元素中包含用于标识其代表何种内容类型的标签。为了表示文档的逻辑结构，所有结构元素都通过父—子关系链接在一起，并组织成一棵“结构树”。在内部，带标签 PDF 文件包含一个名为 `StructTreeRoot` 的对象，其中包含（指向）作为文档逻辑结构树起点或“根”的结构元素。通常，结构树的“根”从一个被标记为 `Document` 的单一结构元素开始，其中包含众多 *子* 结构元素，这些元素共同表示文档的全部内容。任何通过加标签来生成可访问 PDF 的软件都必须构建这种极其复杂的数据结构（以及其他数据结构！）——这也包括 TeX 引擎和 LaTeX。 下面的截图展示了这样一棵文档结构树（`StructTreeRoot`）显示在下面这张带标签 PDF 的截图中： ![在带标签 PDF 中显示 StructTreeRoot 的图像](/files/6ff4a0b8fea50356990b4600ff4cd9b176302ab6) 将上面的结构与未加标签 PDF 版本进行比较： ![在未加标签 PDF 中显示缺少 StructTreeRoot 的图像](/files/7a782a1b085ab88e879244795c1306923ed867fb) ### 探索 PDF 的逻辑结构 我们先用一些图示来总结我们已经讨论的内容，最后用一段视频，通过 Adobe Acrobat Pro DC 展示带标签 PDF 文件逻辑结构的更多细节。首先，我们用一张示意图来展示一般原理：PDF 页面及其内容流用标记内容序列（MCS）进行标记。 ![显示 PDF 文档页面中标记内容序列概念的图示](/files/a8f877878f594cde789c2f1759f56bcff75c206d) 这些 MCS 随后被组合成 *结构元素* 它们构成更大内容类型的基础，而这些内容类型本身又进一步链接在一起，以将 PDF 的逻辑结构存储在一个名为 `StructTreeRoot`. ![显示带标签 PDF 文件逻辑结构的图示](/files/46b3ecaf3a5011263b2e1b284be204525a9c798c) #### 显示带标签 PDF 逻辑结构的视频 以下视频（8 分钟）使用 Adobe Acrobat Pro DC，带你“导览”了解用 LaTeX 生成的带标签 PDF 文件的逻辑结构细节。视频中使用的带标签 PDF 文件名为 `tagpdf.pdf`，它是一个很好的示例，包含实验性 LaTeX 宏包 [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en)的文档。该 `tagpdf` 宏包的目标是提供“用于通过 pdfLaTeX 和 LuaTeX 试验加标签和可访问性的工具”。 {% embed url="" %} ### 关于加标签与灵活性的一则说明 HTML 规范提供了大量用于构建网页的预定义标签，但它也允许你在组合它们以创建所选 HTML 文档时拥有灵活性。同样，Adobe 的带标签 PDF 规范提供了一组预定义标签名称，但故意对你如何组合这些标签以表示 PDF 中的复杂内容项施加极少限制——设计上，灵活性非常大。此外，对于像 PDF 这样庞大而复杂的规范，一些歧义或表述不清的问题不可避免会出现在书面规范中。负责实现这种复杂规范的软件开发者在解释规范时，可能不得不做出“判断性决定”，因为他们面临的是将书面描述转化为可运行代码。 带标签 PDF 天然具有的灵活性以及对规范（或可访问性标准）的解释，当然会影响文档创作应用程序的开发者：在输出为带标签 PDF 文件时，应该使用哪些标签组合来表示用户创建的内容？如果再考虑到用户能够借助文档创作软件的功能无限制地构建各种内容，那么你就会发现，自动生成可访问的带标签 PDF 是一项颇具挑战性的工作！ 也许是因为生成完全符合可访问性标准的带标签 PDF 不可避免地复杂，网络上充斥着关于如何通过 Adobe InDesign 或 Microsoft Word 等软件创建带标签 PDF 的“操作方法”、“技巧”和“最佳实践”建议。此外，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 的逻辑顺序（结构），它必须被组织成反映内容应该被阅读的顺序。正因为如此，表示文档逻辑结构的数据与显示在可见页面上的实际内容分开存储，以便 > “……逻辑内容元素的排序和嵌套完全独立于图形对象在文档页面上的顺序和位置。”（见 [《PDF 参考手册》第六版，2006 年 11 月](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/b1fb1e9847779eb1264ad97c86bb6c340c31803c) 如果我们让 Word 使用其内置导出功能——而不是 Acrobat PDFMaker 插件——将此文档保存为 PDF，我们可以告诉它创建带标签的 PDF： ![Microsoft Word 导出过程的选项对话框](/files/0700c4c9a07bd0a1b77c3f1288790e3cb33d0f9e) 那么，Word 是如何给这个版式加标签的呢？在下面这个很短的视频（14 秒）中，我们使用 Adobe Acrobat Pro DC 检查 Microsoft Word 生成的标签结构。 {% embed url="" %} 对于这个文档，Word 创建了一个带标签的 PDF 文档，它使用了一个 `Table` 标签，其中包含两个子标签： `THead` 用于表头行组，以及 `TBody` 用于表示表体的行组。 `THead` 和 `TBody` 都包含 `TR` 标签，用于表示内容的各个行。 `TR` 这些标签又包含进一步的标签，用于表示每个单元格中出现的编号列表项。下图展示了深度嵌套的标签结构，以及表示这样一个极其基础的文档都需要的相应复杂逻辑结构！ ![图像显示了 Microsoft Word 中创建的简单表格的深度嵌套标签结构和逻辑结构](/files/0c86cefbe6f172834a6ca0f269eea2c7b8b4fdd9) 与 TeX 和 LaTeX 生成的 PDF 相比，这个 Word 示例是一个极其简单的文档，但它仍然需要复杂的逻辑结构来表示它。设想一下，要表示包含复杂数学公式和表格的 LaTeX 生成 PDF，需要多么高的标签复杂度！ #### 有标签，没错，但阅读顺序不正确 尽管 Word 确实生成了一个 [带标签 PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) 它展示了任何试图生成完全可访问 PDF 的应用程序所面临的根本挑战之一：正确表示内容预期的阅读顺序。在创建带标签的 PDF 时，Word 的内部处理过程决定按行而不是按列输出表格，从而写出相应的内容流。对于查看 PDF 的完全健视读者来说，这些底层细节并不会造成差异：表格显示是正确的。然而，对于视力受损的人来说，Word 的逻辑文档结构会产生错误结果，因为所需的阅读顺序（按列）没有被保留：内容被以错误的顺序朗读出来。 以下音频录音是使用 Adobe Reader DC 的“朗读”功能生成的。显而易见，文本是按错误的顺序朗读的：按行而不是按列： ![Microsoft Word 中创建的一个表格](/files/f5fbf8cbae78486aaf9af443c766ebca67258db1) 如上所述，这个例子在某种程度上是人为设计的，但它确实说明了组合使用软件功能时是多么容易触发可访问性问题——可文档作者又怎么可能事先知道这一点呢？这类问题很可能只有在生成的 PDF 经过实际可访问性使用测试时才会被发现——例如，借助辅助软件。潜在地，这类文档也许能够通过 PDF/A 符合性/验证测试，但在“真实世界”使用中却会失败。要确保像这样的 PDF 文件具有正确的阅读顺序，需要使用 Adobe Acrobat Pro DC 之类的高级 PDF 编辑工具进行熟练的人工干预：这是一个耗时且昂贵的过程。或者，文档作者可以避免使用这种特定形式的内容表达或版式——但前提是他们知道它有问题！ ### 使用空格字符分隔单词 当你在文字处理器或文本编辑器中输入文本时，你会使用空格字符来标记一个单词的结束和下一个单词的开始。如果你随后从这样的文档创建 PDF，你输入的空格字符当然会被输出，并成为存储在 PDF 中的文本的一部分。然而，TeX 引擎并不会在排版文本中使用空格字符来分隔单词；相反，它们会把空格字符转换成一种称为 glue 的弹性间距形式（有关 TeX 盒子和 glue 的更多信息，请参见此 [Overleaf 文章](/latex/zh-cn/shen-du-wen-zhang/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) ， 在 TeX 引擎创建的 PDF 页面内容流中，单词之间的分隔是通过移动到页面上的另一个位置并开始输入下一个单词来实现的——而不是通过输出一个空格字符来实现这种间距。此外，TeX 引擎排版的文本段落中单词之间的空白大小会由于 TeX 的断行算法而逐行变化。这种变化会反映在写入 PDF 页面内容流的位置信息中。 TeX 排版的这一方面会影响从其 PDF 中复制/粘贴文本，也会影响辅助软件尝试朗读 TeX 引擎生成的 PDF 中排版文本的能力。辅助软件必须解析 PDF 页面内容流，才能提取其需要处理的文本。显然，这类软件需要某种机制来检测单词的开始和结束——最明显的解决方案就是使用空格字符。考虑到这一点，可访问性标准要求单个单词必须清楚地结束（例如通过空格字符），但由于 TeX 引擎使用单词间 glue，这就成了一个问题。 #### 但并非无计可施！ 2014 年，pdfTeX 引入了 2 个新的原语，通过允许在其输出的 PDF 中使用单词之间的空格字符来改进可访问性支持： * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` 这些命令使用了一个只包含空格字形的“虚拟字体”。更多细节和示例可参见 [pdfTeX User Manual](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### 使用 LuaTeX：Overleaf Gallery 中的一个示例 LuaTeX 不支持这些 pdfTeX 原语，但可以通过 LuaTeX 所谓的回调机制进行编程，以实现与 pdfTeX 非常相似的结果。Overleaf Gallery 中有一个将 glue 转换为空格字符的项目，标题为 [使用 LuaTeX 将单词间 glue 转换为空格和 kern](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). 如果你使用 LuaTeX 排版 LaTeX 代码（即 Overleaf 上的 LuaLaTeX 编译器选项），那么借助 Lua 代码，你可以对排版后的段落进行后处理，找出任何单词间 glue，并将其替换为空格字符加上适当的 kern。空格字符提供的间距宽度可以通过计算合适的 kern 值来增加（或减少），以保留单词间 glue 提供的间距，从而使排版结果在视觉上没有差异。 要理解这对可访问性软件用户带来的差异，请听这段从 Adobe Reader DC 的 *朗读* 功能中截取的录音。它记录了该项目中两行文本在将 glue 转换为空格前后被朗读出来的情况。请注意，与使用单词间 glue 的那一行相比，使用空格的第二次朗读速度更快，也更流畅。 该 Overleaf 项目是一个使用 LuaTeX 编译的 plain TeX 文件，仅供实验用途；它并非旨在成为完整、生产级的解决方案。其主要目的是帮助理解与可访问 PDF 相关的技术问题。该项目中使用的 Lua 代码基于更早的一篇 Overleaf 文章中的工作 [盒子与胶水：使用 LuaTeX 的简明而直观的介绍](/latex/zh-cn/shen-du-wen-zhang/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). 注意：为简化起见，该项目使用了自己的极简 OpenType 字体加载器，其代码源自此处： . ### 其他可访问性问题与带标签的 PDF 尽管标签化允许识别 PDF 中存在的内容项，但某些类型的内容，例如图形或复杂数学公式，如果要通过专为支持视力受损者的软件实现可访问，还需要额外的数据或信息。为了为各种内容类型提供并支持可访问性，PDF 规范提供了将“替代描述”或“实际文本（ActualText）”附加到内容项的能力，从而提供合适的文本描述或其他机器可读表示。例如，在 PDF 2.0 规范中，MathML 就被指定用于这一目的。 #### 它是“真实内容”还是仅仅是一个工件？ 对于视力受损者来说，将内容划分并显示在矩形页面大小的块中这一过程会带来一些不希望有的副作用，例如单词连字符化。此外，用于增强视觉呈现的页面设计或版式方面，对看不见它的人来说毫无意义。因此，PDF 内容的标签化必须认识到，PDF 中的某些内容应被视为 *工件* ，即视觉呈现或分页的工件。例如，页码、页眉和页脚、阴影背景或其他设计提示都需要被识别出来，以便处理内容的可访问性软件知道忽略它们。 ## PDF/A 标准概览 关于生成可访问 PDF 的请求通常会提到一个名为 [ISO 19005](https://www.iso.org/standard/38920.html)的 ISO 标准，更常被称为 PDF/A。不过，由于 PDF/A 是一 *族* 组标准，因此仅仅要求“PDF/A 符合性”可能并不能完整地说明实际要求。要理解原因，让我们先从 PDF Association 网站上的一段简要说明开始， [PDF Association 网站](https://www.pdfa.org/resource/iso-19005-pdfa/) （访问于 2020 年 5 月 21 日），其中将 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 年后， [Adobe 的 PDF 1.7 版本](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/A 限制了符合标准的 PDF 文件中允许使用的 PDF 功能集，禁止使用可能损害可归档性或可访问性的功能。你可以把 PDF/A 看作一组标准，它规定符合标准的 PDF 文件如何使用 *子集* 完整 PDF 规范中的 *完整*：关键文档资源必须嵌入到文件中——例如字体或颜色配置文件。 ### PDF/A 版本和符合级别 PDF/A 标准有不同的 *版本* 版本，每个版本都反映了某一特定正式 PDF 规范版本（PDF 1.4、1.7 和 2.0）。此外，还有不同的 *符合级别* ，用于规定 PDF 文件符合 PDF/A 标准的哪些方面。因此，在声称或要求“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 年 4 月/5 月），更新版的 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（“通用可访问性”） 尽管 PDF/A 标准的 A 级符合性在某种程度上定义了可访问 PDF 的要求，但另一个名为 [ISO 14289](https://www.iso.org/standard/64599.html)的 ISO 标准，即 PDF/UA，则更进一步。PDF/UA 加强了可访问性要求，并澄清了 PDF/A 标准中的指导内容，已成为可访问 PDF 的首选标准。 #### Matterhorn 协议 希望深入了解 PDF/UA 符合性要求的读者，可能会对 [Matterhorn Protocol](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/) 正如其网站所述（访问于 2020 年 5 月 28 日），它是一个“专门构建的、开源的文件格式验证器，覆盖所有 PDF/A 部分和符合级别”。 * （仅限 Windows） [PDF Accessibility Checker（PAC 2024）](https://pac.pdf-accessibility.org/en/download) 它是一款“……自 2010 年以来经过反复试用和测试的免费 PDF 可访问性检查工具”。 #### 商业验证软件 * [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 标准及其要求提供了极其宝贵的入门介绍。 ## 来自 TeX 引擎和 LaTeX 的可访问 PDF 希望前面的讨论已经表明，生成完全可访问且正确标记的 PDF 文件是一项要求很高的技术挑战。此外，即便是前面那个简单的 Microsoft Word 示例也表明，作者很容易使用某些软件功能组合，从而生成未能满足可访问性标准的带标签 PDF 文档。 作为一种创作工具，LaTeX 为作者提供了几乎无限的灵活性，使其能够创建范围和复杂性都极高的文档——而这也许正是当初选择它的原因。LaTeX 还通过数千个附加包支持扩展性，作者可以将其作为文档的一部分加以使用。除此之外，作者还可以自由编写新的 TeX 或 LaTeX 宏，或重新定义现有宏，以实现特定效果。然而，也许正是这种自由和灵活性带来了代价，因为由众多 LaTeX 包和宏之间的相互作用所产生的内容，“某种程度上”需要被协调起来，LaTeX 才能自动生成正确标记且可访问的 PDF 输出。 在实践中，LaTeX 所赋予的可扩展性、强大能力、多功能性以及作者“自由”，给无缝且透明（“自动”）地生成符合 PDF/UA 或 PDF/A-{1|2|3}a 标准的完全可访问、带标签 PDF 文档带来了技术挑战。更广泛的 TeX 和 LaTeX 社区正在努力应对这些挑战，TeX 用户组（TUG）正通过 PDF 可访问性和 PDF 标准 [工作组](https://www.tug.org/twg/accessibility/)来协调研究与开发工作。还有一个 [讨论列表](https://tug.org/mailman/listinfo/accessibility) ，为有兴趣的各方提供了一个讨论使用 TeX 和 LaTeX 生成带标签 PDF 文件的途径。 在这些讨论中，值得记住的是，LaTeX 本身并不是一个可执行的排版程序，它是用一种更底层的语言 TeX 编写的大量复杂宏（命令）的集合。在你精心制作的 LaTeX 文档和最终排版出的 PDF 之间，存在着一款名为 TeX 引擎的软件，它的任务是“执行”用于编写和构造文档的那组 LaTeX 命令（即宏）——把它们转换成文档的排版表示并保存为 PDF 文件。对于刚接触 TeX/LaTeX 生态系统的人来说，面对他们遇到的那些听起来很晦涩的工具名称——TeX、LaTeX、pdfTeX、pdfLaTeX、XeTeX、XeLaTeX、LuaTeX 和 LuaLaTeX——往往会感到困惑，这完全可以理解。如果你也有同感，Overleaf 文章 [《名字里有什么：TeX 的多种“风味”指南》](/latex/zh-cn/shen-du-wen-zhang/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) 会为你解释这些术语的起源和含义。 像 pdfTeX、XeTeX 或 LuaTeX 这样的 TeX 引擎属于一类被称为 *文档编译器*的软件：它们接收你的 LaTeX 代码，并通过将 LaTeX 宏（命令）“转换”回更底层的 TeX 语言指令来将其编译成排版形式，这些指令被“执行”后生成排版结果。基于 TeX 的排版系统能够生成极其复杂的内容——包括高级数学、乐谱、化学结构、图形以及复杂的多语言排版文本。为了确保这些复杂文档符合可访问性标准和法规，TeX 引擎与 LaTeX 宏集合以及 LaTeX 宏包需要通过向其生成的 PDF 文件中嵌入大量额外数据来生成适当带标签的 PDF 文件。 尽管 TeX 引擎可以生成极其复杂的 PDF 文件，但其内部流程、算法和函数并没有 *内置的* 专门设计的 *功能* 来支持生成带标签、可访问的 PDF。相反，对标签化和可访问性的支持必须通过复杂的宏编程来实现，这些宏编程会向 TeX 引擎生成的 PDF 中“注入”额外数据——创建存储在 `StructTreeRoot`中的标记内容序列、结构元素和逻辑结构数据结构。而这正是“协调”之处最受关注的地方：LaTeX 核心（内核）中的代码以及数千个宏包和无数作者自定义宏中的代码，必须非常谨慎地协同工作，以确保宏的执行能够对结果文档内容进行正确的标签化。这种“协调”必须是可靠的——无论作者如何组合和使用 LaTeX 的功能、命令和特性、其宏包系统以及 TeX 宏的强大能力。 ### 作者的需求 对大多数人来说，LaTeX 只是一个让你创建排版精美文档的工具，你可以自由选择各种宏包来帮助实现这一点。绝大多数 LaTeX 作者只希望他们的文档“能正常工作”：排版时不出错，这样他们就能提交论文、文章、报告，或者完成那本期待已久的书。也不奇怪，LaTeX 用户期望他们选择的 LaTeX 宏包能够和谐共存，无缝、透明地互操作，从而提供生成文档所需的命令和功能。当面临从 LaTeX 生成带标签 PDF 的要求时，这些相同的愿望也很可能存在：它应该“直接就能用”，透明且只需作者极少干预。不幸的是，我们距离那种“瞧！无论我做什么奇怪的操作，标签都会自动出现”的体验还有相当距离。将可访问性的技术要求与带标签 PDF 结合 LaTeX 和作者自由，本质上是很复杂的，也许如果这些技术挑战要变得适合实际实现和解决，某种形式的“作者约束”可能是不可避免的。 另一个独立但相关的问题是，错误的标签化在最终 PDF 中可能没有任何视觉影响：从视觉上看，它可能完美无缺，而且打印出来也很可能没有问题，但作者并不知道标签已经“损坏”，只有在随后进行 PDF/A 符合性/验证检查失败和/或通过诸如屏幕阅读器之类的可访问性软件进行进一步实际测试时才会被发现。 ### 在 Overleaf 上生成的 PDF 文件 Overleaf 为其用户社区提供了一个基于浏览器的 LaTeX 编辑器，以及项目和文档管理工具，以促进协作创作——所有这些都建立在标准 TeX Live 安装之上。实际上，Overleaf 允许用户通过网页浏览器“远程运行 LaTeX”，从而为管理和维护完整 TeX Live 系统的复杂性提供了一层隔离。 Overleaf 使用标准 TeX/LaTeX 安装的结果是，在 Overleaf 编辑器中编写的 LaTeX 代码所生成的 PDF，会使用与任何其他同版本 TeX Live 安装中完全相同的技术——包括用户在本地设备上安装的环境。唯一的区别在于，编译和处理 Overleaf LaTeX 代码的 TeX 引擎运行在远程服务器上，而不是本地机器上。Overleaf 确实会对 TeX 生成的 PDF 进行线性化，以便在浏览器中高效下载/显示，但该过程与 PDF 内容本身的可访问性无关。 通过 Overleaf 生成可访问 PDF 依赖于标准 TeX 引擎内置的能力和功能，以及用户可以作为文档一部分部署的合适 LaTeX 宏包的可用性。使用 Overleaf 创建的 LaTeX 文档必须与其他 TeX 和 LaTeX 安装保持兼容，因为用户经常需要将其 LaTeX 项目从 Overleaf 导出，以便提交到各种出版商和期刊系统。将 Overleaf 特定功能引入其 LaTeX 文档或底层 TeX 引擎，会严重限制用户在其他地方使用其工作的自由。 Overleaf 认识到并支持从 TeX/LaTeX 创作系统生成完全可访问 PDF 的需求：我们投入时间研究可访问性问题，探索 TeX 引擎和支持带标签 PDF 的实验性 LaTeX 宏包的最新进展。归根结底，在撰写本文时，并没有一个 LaTeX 作者可以使用的“开箱即用”解决方案（通过 `\usepackage`) ### 一些用于探索标签化和可访问性的 LaTeX 宏包 对许多人来说， [tex.stackexchage](https://tex.stackexchange.com/) 是获取 TeX、LaTeX 或 ConTeXt 帮助的首选去处。它是一个令人惊叹的资源，在 [可访问性](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) 以及通过 LaTeX 生成可访问 PDF 方面有许多问题。如果你阅读并浏览这些问题，以及随之而来的大量答案和评论，只有一个结论是不可避免的：目前还没有一个完整的、生产级的解决方案，能够从每一种 LaTeX 文档中自动创建完全可访问、符合标准、带标签的 PDF。不过，确实有一些宏包支持标签化——尽管可能只适用于有限范围的使用场景和文档类型。以下列表供希望探索基于 LaTeX 的 PDF 标签化的读者参考： * [`tagpdf` 宏包](https://ctan.org/pkg/tagpdf) （Ulrike Fischer）：功能极强的宏包，专为试验 PDF 标签化而设计。支持 pdfTeX 和 LuaTeX，并提供极其有用且有趣的文档，其中包含关于通过 TeX 引擎创建带标签 PDF 的技术挑战的出色说明；强烈推荐任何有兴趣更好理解相关问题的人阅读。未来方向的重点很可能是 LuaTeX。 * [`axessibility` 宏包](https://ctan.org/pkg/axessibility?lang=en) （Boris Doubrov 和都灵大学）：通过辅助技术为 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) 作者是麦考瑞大学数学系的 Ross Moore 博士。在那篇论文中，Moore 博士简要概述了在 LaTeX 中为 PDF 加标签所面临的挑战： > “困难的主要来源在于不同环境彼此相互作用的方式。在 LaTeX 中，存在许多情况，其中一个环境或结构直到下一个环境开始时才算真正完成。因此，这不仅仅是在每一段提供的内容外面包上开始和结束标签的问题。相反，需要理解不同环境和其他结构在其周围材料所建立的上下文中，实际上是如何开始和结束的细微差别。” Moore 博士也是 [`pdfx`](https://ctan.org/pkg/pdfx) 宏包的现任维护者，也是使用 TeX/LaTeX 进行带标签 PDF 方面的专家和先驱。他的工作非常值得搜索——包括这个 YouTube 视频，它提供了有趣的见解： {% embed url="" %} #### pdfx 宏包说明 该 [`pdfx`](https://ctan.org/pkg/pdfx) 宏包（Ross Moore 等）为 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/zh-cn/geng-duo-zhu-ti/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.