> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/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)，并且在通过 [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 引擎和旨在生成带标签且可访问 PDF 文件的 LaTeX）所面临的一些技术挑战。无障碍性，尤其是 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 文档的功能。实际上，生成带标签——*且完全可访问*——的 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 内部结构* 对同一个 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 规范中，这些标准名称被称为标签（tags），由此产生了 *带标签* 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`。标记内容序列的结尾由 PDF 运算符 `EMC`. ![显示由标记内容流包围的运算符细节的图像](/files/d1716056f1fc13db915f55f7e47d9d5ece88b2f3) ### 存储逻辑结构 如前所述，除了提供单个内容项（段落、列表、表格等）的描述之外，可访问 PDF 还必须包含整个文档的表示形式，即其逻辑结构。单个可访问内容片段必须相互链接，以创建一个完整、可导航且可访问的文档——类似于单个 HTML 文档由段落、图形、表格构建成一个网页。此外，至关重要的是，PDF 文档的逻辑结构要确保所有内容都能按照正确的 *阅读顺序*进行导航，而不受页面内容写入 PDF 页面内容流时顺序的影响。我们将在下文更详细地探讨阅读顺序。 #### 逻辑结构：结构元素“树” 我们已经提到，PDF 使用一种称为 *结构元素* 的东西来表示单个内容项，而且结构元素包含一个标签来标识其代表的内容类型。为了表示文档的逻辑结构，所有结构元素通过父—子关系链接起来，并组织成一棵“结构树”。在内部，带标签 PDF 文件包含一个名为 `StructTreeRoot` 的对象，其中包含（指向）结构元素，它们充当文档逻辑结构树的起点或“根”。通常，结构树的“根”从一个带有标签 `Document` 的单个结构元素开始，其中包含众多 *子* 结构元素，这些元素合在一起代表文档的全部内容。任何旨在通过加标签生成可访问 PDF 的软件都必须构建这一极其复杂的数据结构（以及其他结构！）——这也包括 TeX 引擎和 LaTeX。 这样的文档结构树示例（`StructTreeRoot`）显示在下面这张在 Adobe Acrobat Pro DC 中打开的带标签 PDF 截图中： ![显示带标签 PDF 中 StructTreeRoot 的图像](/files/6ff4a0b8fea50356990b4600ff4cd9b176302ab6) 将上面的结构与未加标签的 PDF 版本进行比较： ![显示未加标签 PDF 中缺少 StructTreeRoot 的图像](/files/7a782a1b085ab88e879244795c1306923ed867fb) ### 探索 PDF 的逻辑结构 我们先用一些图形来总结已讨论的内容，然后以一个使用 Adobe Acrobat Pro DC 展示带标签 PDF 文件逻辑结构更多细节的视频作结。首先，我们用一张示意图来展示一般原理：一个 PDF 页面，其内容流使用标记内容序列（MCS）进行标记。 ![用于显示 PDF 文档页面中标记内容序列概念的图形](/files/a8f877878f594cde789c2f1759f56bcff75c206d) 这些 MCS 随后被组合成 *结构元素* 结构元素 `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` 宏包 {% 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. text 2. table 3. 图形 。当写入 PDF 时，为该页面生成内容流的软件可能会先使用运算符绘制表格，再输出运算符生成图形，然后再输出文本的运算符，这在内容流中会产生一个 *内容顺序* 。这看起来似乎“显而易见”，但当软件将一个 PDF 文件写出时，它可以按自己选择的任何顺序将图形和文本输出到页面内容流中。例如，假设某一页先有一些文本，随后是一个表格，最后是一幅图形，形成一种自然的 1. table 2. 图形 3. text 。当然，当该页面被查看时，一切都会被放置在正确的位置。对于完全具备视力的读者来说，这些项目存储在页面内容流中的顺序并不重要：他们看到的是一个完整渲染的页面，所有内容都在正确的位置。 然而，如果辅助软件不得不依赖内容流中项目的排序（内容顺序），而内容顺序又不同于自然阅读顺序，它就会面临困难；例如，朗读工具会以错误的顺序读出材料。幸运的是，辅助软件可以使用带标签 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 文档，其中使用了一个 `表格` 标记，其中包含两个子标记： `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 的“Read Out Loud”功能制作的。很明显，文本朗读的顺序是错误的：按行，而不是按列： ![Microsoft Word 中创建的一个表格](/files/f5fbf8cbae78486aaf9af443c766ebca67258db1) 如上所述，这个例子有些刻意，但它确实表明，组合使用软件功能触发可访问性问题是多么容易——可文档作者又怎么可能事先知道这一点呢？这类问题很可能只有在生成的 PDF 经过实际的可访问性使用测试时才会被发现——例如，借助辅助软件。潜在地，这类文档也许能够通过 PDF/A 合规/验证测试，但在“真实世界”使用中却会失败。要确保像这样的 PDF 文件具有正确的阅读顺序，需要使用 Adobe Acrobat Pro DC 等高级 PDF 编辑工具进行熟练的手动干预：这既耗时又昂贵。或者，文档作者可以避免使用这种特定的内容表达或版式——但前提是他们知道它有问题！ ### 使用空格字符分隔单词 当你在文字处理器或文本编辑器中输入文本时，你会使用空格字符来标记一个单词的结束和下一个单词的开始。如果随后从这样的文档创建 PDF，你输入的空格字符当然会被输出，并成为存储在 PDF 中的文本的一部分。然而，TeX 引擎并不使用空格字符来分隔排版文本中的单词；相反，它们会将空格字符转换为一种称为 glue 的可伸缩间距（参见这篇 [Overleaf 文章](/latex/zh-cn/shen-ru-wen-zhang/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) 以了解更多关于 TeX 盒子和 glue 的信息）。 在 TeX 引擎创建的 PDF 页面内容流中，单词之间的分隔是通过移动到页面上的另一个位置并开始下一个单词的文本来实现的——而不是通过输出一个空格字符来实现这种间距。此外，由于 TeX 的断行算法，TeX 引擎排版的文本段落中单词之间的间距会逐行变化。这种变化会反映在写入 PDF 页面内容流的位置信息中。 TeX 排版的这一特点会影响从其 PDF 中复制/粘贴文本，也会影响试图朗读 TeX 引擎生成的 PDF 中排版文本的辅助软件。辅助软件必须解析 PDF 页面的内容流以提取它需要处理的文本。显然，这类软件需要某种机制来检测单词的开始和结束——最明显的解决方案就是使用空格字符。考虑到这一点，无障碍标准要求各个单词要明确地结束（例如用空格字符），但这对 TeX 引擎来说是个问题，因为它们使用单词间 glue。 #### 但并非毫无希望！ 2014 年，pdfTeX 引入了 2 个新的原语，以通过允许在其输出的 PDF 中使用单词之间的空格字符来改进可访问性支持： * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` 这些命令使用一种只包含空格字形的“虚拟字体”。详细信息和示例可见于 [pdfTeX 用户手册](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### 使用 LuaTeX：Overleaf 图库中的一个示例 LuaTeX 不支持这些 pdfTeX 原语，但可以通过 LuaTeX 所谓的回调机制进行编程，以实现与 pdfTeX 非常相似的效果。Overleaf 图库中有一个将 glue 转换为空格字符的项目，标题为 [使用 LuaTeX 将单词间 glue 转换为空格和 kern](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). 如果你使用 LuaTeX（即 Overleaf 上的 LuaLaTeX 编译选项）排版 LaTeX 代码，那么可以借助 Lua 代码对已排版的段落进行后处理，查找任何单词间 glue，并将其替换为空格字符加上适当的 kern。通过计算合适的 kern 值，可以在空格字符宽度提供的间距基础上增加（或减少）间距，以保留单词间 glue 提供的空间量，从而使排版结果在视觉上没有差异。 要理解这对辅助功能软件用户带来的差异，请收听这段从 Adobe Reader DC 的 *Read Out Loud* 功能捕获的录音。它记录了该项目中两行文本在将 glue 转换为空格之前和之后被朗读的情况。请注意，与使用单词间 glue 的那一行相比，使用空格的第二次朗读速度更快，也更流畅。 该 Overleaf 项目是一个使用 LuaTeX 编译的 plain TeX 文件，仅供实验使用；它并非旨在成为完整的、可用于生产的解决方案。其主要目的是帮助理解与可访问 PDF 相关的技术问题。该项目中使用的 Lua 代码基于一篇更早的 Overleaf 文章中的工作 [盒子与胶水：使用 LuaTeX 的简短但可视化的介绍](/latex/zh-cn/shen-ru-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/A 的简要概述说起，摘自 [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 能够作为一种“归档数字纸张”来使用，而不依赖用于访问其内容的 PDF 阅读技术和计算环境。符合规范的 PDF 不应包含任何“实现依赖”的行为——即其行为取决于用于查看或处理它们的特定软件或操作系统。PDF 还必须是 *完整的*：关键文档资源必须嵌入文件中——例如字体或颜色配置文件。 ### PDF/A 版本和符合级别 有不同的 *版本* PDF/A 标准版本，每个版本都反映了正式 PDF 规范的某个特定版本（PDF 1.4、1.7 和 2.0）。此外，还有各种 *符合级别* ，用于规定 PDF 文件符合 PDF/A 标准的哪些方面。因此，当声称或要求“PDF/A 符合性”时，你应该想到符合 **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)、即 PDF/UA 的 ISO 标准，则更进一步。PDF/UA 强化了可访问性要求，并澄清了 PDF/A 标准中的指导说明，已成为可访问 PDF 的首选标准。 #### Matterhorn 协议 对深入了解 PDF/UA 合规性有浓厚兴趣的读者，可能会对 [Matterhorn Protocol](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) 感兴趣，它是“导致 PDF/UA 合规失败的所有可能方式的列表”。 ### 验证软件 要检查某个 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 要自动生成标记正确且可访问的 PDF 输出，那么所有这些 LaTeX 宏包和宏之间的无数交互所产生的内容就“某种程度上”需要被协调起来。 在实践中，LaTeX 所赋予的可扩展性、强大功能、多用途性和创作“自由”，给无缝且透明（“自动”）地生成完全可访问、并符合 PDF/UA 或 PDF/A-{1|2|3}a 标准的带标记 PDF 文档带来了技术挑战。更广泛的 TeX 和 LaTeX 社区正在努力应对这些挑战，而 TeX User Group（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-ru-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 核心（kernel）中的代码，以及数千个宏包和无数作者创建的宏中的代码，必须非常谨慎地协同工作，以确保宏的执行能对最终文档内容产生正确的标记。这种“协调”必须是可靠的——无论作者如何组合和使用 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 导出，以提交到各种出版商和期刊系统。如果在其 LaTeX 文档或底层 TeX 引擎中引入 Overleaf 特有的功能，将严重限制用户在其他地方使用其作品的自由。 Overleaf 认识并支持从 TeX/LaTeX 创作系统生成完全可访问 PDF 的需求：我们投入时间研究可访问性问题，探索支持带标记 PDF 的 TeX 引擎和实验性 LaTeX 宏包的最新进展。最终，在撰写本文时，还没有一个 LaTeX 作者 `\usepackage`）从通用 LaTeX 文档中无缝且透明地生成完全可访问、符合 PDF/UA 标准的 PDF。当这些解决方案通过 TeX Live 更新可用时，它们当然也会向 Overleaf 用户社区开放。 ### 一些用于探索标记和可访问性的 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://overleaf-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.