> 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-tw/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) ，即可從 LaTeX 原始碼產生符合 WCAG 2.1 AA 等級的具標籤 PDF，並使用 Overleaf 中可用的 TeX Live 發行版。 以下這篇 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 在 1990 年代初期作為解決可靠文件傳輸問題的方案而出現，歷史證明它非常成功。然而，PDF 也是一種複雜的檔案格式，誕生於人們普遍尚未認知並接受文件內容需要便於無障礙存取之前。儘管如此，隨著時間推移，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/b94db83800755eac46f28d29e8af449c6bb6aa42) 如果我們擷取此檔案的（解壓縮後的）頁面內容流，並將前幾行貼到文字編輯器中，就可以把一些 PDF 運算子概括出來，稍微體會 PDF 檔案如何「描述」這一頁所顯示的內容。 ![PDF 檔案中內容流的影像](/files/c2af78911340cbfa445d8b4d60fc2d80ad29f359) 如果你能使用 Adobe Acrobat Pro DC，就可以用它列出 PDF 頁面內容流中包含的運算子。以下是 Acrobat 的 *PDF 內部結構* 同一份 PDF 的檢視畫面，它貼心地提供了用來「繪製」我們這個包含基本表格的單頁所使用之每個運算子的單行說明——請注意，這些簡短說明是由 Adobe Acrobat Pro DC 提供的，它們 *不是* PDF 檔案本身所包含的： ![在 Adobe Acrobat Pro DC 中檢視的 PDF 內容流影像](/files/47d2f3d11a0219028880f1e7a39cf15a5b3bc8fe) 然而，請注意，這些繪圖指示（運算子）都沒有儲存任何它們實際產生內容的「意義」或「描述」：它們只是一組圖形運算子，最終構成了 *有視力的觀察者所辨識* 為表格的東西。顯然，對於嚴重視覺障礙者來說，顯示這些圖形運算子在 PDF 內容流中所形成的表格，並不是存取該內容的可行方法。真正需要的是一種機制，讓 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 處理應用程式能提供一致的結果，Adobe 定義了一組標準的內容項目名稱，PDF 產生軟體應予以遵循。在 PDF 規格中，這些標準名稱被稱為標籤，因此產生了 *具標籤* PDF 的概念。 ### PDF 內容的標記：窺探「內部」 為了讓討論少一些抽象，我們將簡要看看具標籤 PDF 檔案的內部結構——雖然我們無法涵蓋所有細節，因為具標籤 PDF 是一個非常龐大且複雜的主題。 #### 標記內容序列：具標籤 PDF 的組成區塊 在最底層，記錄 PDF 頁面中所含內容（也就是在其內容流中）的意義的過程，從 *標記內容序列* 開始，它們用來識別（賦予「意義」給）PDF 運算子的叢集或群組。標記內容序列會被指派一個數值識別碼，稱為其 `MCID` (*標記內容識別碼*）這是一個整數，在每一頁上從 0 到某個最大 N。這些 `MCID` 值提供了一種方式，可唯一識別特定頁面內容流中所包含的運算子序列。為了澄清一下，對每一頁而言， `MCID` 識別碼都從 0 開始，並依序增加到某個最大值，該值取決於特定頁面的內容流中包含多少個標記內容序列。 實際上，標記內容序列是用來組裝更高層次資料結構的基本「組成區塊」，這些資料結構稱為 *結構元素*。這些結構元素包含一個標籤，也就是用來識別其代表哪一種內容項目的名稱。 #### 結構元素範例 這裡我們稍微往前跳了一點，但這個範例值得檢視。假設你有 3 段小型文字片段的頁面內容，而每一段都在內容流中由不同的標記內容序列來識別。這 3 段文字片段中的每一段都可以各自封裝成一個帶有標籤的結構元素，而這三者又可以透過另一個結構元素「連結」在一起，代表更高層次的內容項目，例如目錄中的一行。 ![說明結構元素與標記內容序列的影像](/files/f0858cf0985f4623dc761d4a389f15e431c3aaef) 透過一種父子資料關係，結構元素的集合會被組合起來，以建立連結資料結構，表示較複雜的資料項目，例如編號與項目符號清單、表格、數學等等。最終，整個 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/eb368d81a5a97bc1ea69d67ad03b5f4b4631e1c0) 為方便參考，我們再次顯示未加標籤的版本： ![顯示 PDF 內容流的影像](/files/c2af78911340cbfa445d8b4d60fc2d80ad29f359) 在 *未加標籤的* PDF 中，像 `/P <> BDC` 以及 `EMC` 這樣的運算子並不存在，但其餘運算子保持不變：未加標籤的 PDF 缺少用來識別某些運算子序列／集合的額外標記。此外，我們也可以使用 Adobe Acrobat 的 *PDF 內部結構* 功能來檢視內容流中的標記內容序列——此處我們以綠色框線將它們標示出來： ![在 Adobe Acrobat Pro DC 中檢視的具標籤 PDF 內容流中標記內容序列的影像](/files/587ea2abb5afed1c4bf8dad5e960c648dba8be1b) 請注意，有些內容是以 `/Artifact` 標記，這用來識別 PDF 頁面上應該被 *忽略* 的材料，供輔助軟體應用程式使用，例如那些會為視覺障礙者朗讀內容的程式。 以下截圖顯示第一個標記內容序列的展開檢視——也就是那個 `MCID` 值為 `0`。該標記內容序列的結尾由 PDF 運算子 `EMC`. ![顯示被標記內容流所包含的運算子細節的影像](/files/e90e5df3a384266b745152cbddf360a25cff2fa5) ### 儲存邏輯結構 如前所述，除了提供個別內容項目（段落、清單、表格等）的描述之外，可存取的 PDF 也必須包含整份文件的表示形式，也就是其邏輯結構。個別的可存取內容片段必須連結起來，形成一份完整、可導覽且可存取的文件——類似於單一 HTML 文件如何由段落、圖形、表格組成以形成網頁。此外，PDF 文件的邏輯結構必須確保所有內容都能以正確的 *閱讀順序*來導覽，且不受頁面內容寫入 PDF 頁面內容流的順序影響。我們將在下文更詳細探討閱讀順序。 #### 邏輯結構：由結構元素組成的「樹」 我們已提到 PDF 使用一種稱為 *結構元素* 的東西來代表個別內容項目，而結構元素包含一個標籤，用來識別其所代表的內容類型。為了表示文件的邏輯結構，所有結構元素都透過父子關係連結在一起，並組織成一棵「結構樹」。在內部，具標籤 PDF 檔案包含一個名為 `StructTreeRoot` 的物件，其中包含（指向）作為文件邏輯結構樹起點或「根」的結構元素。通常，結構樹的「根」會從一個帶有標籤 `Document` 的單一結構元素開始，其中包含許多 *子* 結構元素，這些元素合起來代表整份文件的全部內容。任何設計為透過標籤化來產生可存取 PDF 的軟體，都必須建立這個極其複雜的資料結構（以及其他資料結構！）——這也包括 TeX 引擎與 LaTeX。 這類文件結構樹的範例（`StructTreeRoot`）如下所示：以下是在 Adobe Acrobat Pro DC 中開啟的具標籤 PDF 的截圖： ![顯示具標籤 PDF 中 StructTreeRoot 的影像](/files/66a22c3e21c1a41c9dba2bb841b8feb9805688d7) 將上述結構與未加標籤的 PDF 版本比較： ![顯示未加標籤 PDF 中缺少 StructTreeRoot 的影像](/files/d5a03ef6a3929db584e8e4b9f0861bac35dd8f9f) ### 探索 PDF 的邏輯結構 我們先用一些圖形來總結目前已涵蓋的內容，最後再以一段影片，使用 Adobe Acrobat Pro DC 更詳細地展示具標籤 PDF 檔案的邏輯結構。首先，我們先用一張示意圖來說明一般原理：一個 PDF 頁面，其內容流以標記內容序列（MCS）進行標記。 ![用來說明 PDF 文件頁面中標記內容序列概念的圖形](/files/3c623a95837470287c7e71f8b327ce5f747fea4d) 這些 MCS 隨後會被組合成 *結構元素* ，作為更大型內容類型的基礎，而這些更大型內容類型又會進一步連結在一起，並儲存在一個名為 `StructTreeRoot`. ![用來說明具標籤 PDF 檔案邏輯結構的圖形](/files/20c4aa0d04b44fca613c4e17474365677b99bcff) #### 顯示具標籤 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. 表格 3. 圖形 在寫入 PDF 時，為該頁產生內容流的軟體可能會先用一些運算子繪製表格，接著輸出運算子產生圖形，然後再輸出運算子產生文字，而這些在內容流中會形成一個 *內容順序* 順序： 1. 表格 2. 圖形 3. 文字 當然，當該頁被檢視時，一切都會被放在正確的位置。對於完全看得見的讀者而言，這些項目儲存在頁面內容流中的順序並不重要：他們看到的是一個完整渲染的頁面，所有內容都在正確的位置。 然而，如果輔助軟體必須依賴內容流中項目的排序（內容順序），當內容順序與自然閱讀順序不同時，它就會面臨困難；例如，朗讀工具可能會以錯誤的順序唸出內容。幸運的是，輔助軟體可以使用具標記 PDF 的邏輯順序（結構），而這必須依內容應被閱讀的順序來組織。基於這些原因，代表文件邏輯結構的資料會與顯示在可視頁面上的實際內容分開儲存，以便 > 「……邏輯內容元素的排序與巢狀關係，能夠完全獨立於文件頁面上圖形物件的順序與位置。」（第 856 頁， [《PDF Reference》第六版，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/a589ea2223f3f854fff581c31484cd5128728176) 如果我們要求 Word 使用其內建的匯出功能——不是 Acrobat PDFMaker 外掛程式——將這份文件儲存為 PDF，我們可以設定它建立具標記 PDF： ![Microsoft Word 匯出程序的選項對話方塊](/files/4d4f6023630797afbb253f42cd30fb7890207dff) 那麼，Word 是如何為這個版面加上標記的呢？在下面這段很短的影片（14 秒）中，我們使用 Adobe Acrobat Pro DC 來檢視 Microsoft Word 產生的標記結構。 {% embed url="" %} 對於這份文件，Word 建立了一份具標記 PDF 文件，使用了 `Table` 標記，並包含兩個子標記： `THead` 代表表格標頭列群組，還有 `TBody` 代表表格主體的列群組。 `THead` 以及 `TBody` 都包含 `TR` 標記，用來代表個別的內容列。 `TR` 標記再包含進一步的標記，用來代表每個儲存格中出現的編號清單項目。下方螢幕畫面顯示了深度巢狀的標記結構，以及即使是這麼極其基本的文件所需的、同樣複雜的邏輯結構！ ![顯示由 Microsoft Word 建立之簡單表格的深度巢狀標記結構與邏輯結構的影像](/files/e441b01865967d22c1f9f2188e8ee03aaf0ecaee) 與 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/3b75ec110233120e08f0b13cc335f5f6f2537071) 如上所述，這個例子有些刻意，但它確實說明了要套用軟體功能組合而引發無障礙問題是多麼容易——但文件作者又怎麼可能事先知道這一點呢？很可能只有在產生的 PDF 經過實際的無障礙使用測試時，才會發現這個問題——例如，使用輔助軟體進行測試。潛在地，這類文件可能通過 PDF/A 相容性／驗證測試，卻在「真實世界」的使用中失敗。要確保像這樣的 PDF 檔案具有正確的閱讀順序，需要使用 Adobe Acrobat Pro DC 等進階 PDF 編輯工具進行熟練的手動介入：這是一個耗時且昂貴的過程。或者，文件作者可以避免使用這種特定的內容表達或版面形式——但前提是他們知道它有問題！ ### 使用空白字元分隔單字 當你在文書處理器或文字編輯器中輸入文字時，你會使用空白字元來標示一個字的結尾與下一個字的開始。如果你之後從這樣的文件建立 PDF，你輸入的空白字元當然會被輸出，並成為儲存在 PDF 中的文字的一部分。然而，TeX 引擎並不使用空白字元來分隔排版文字中的單字；相反地，它們會將空白字元轉換成一種稱為 glue 的彈性間距（請參閱這篇 [Overleaf 文章](/latex/zh-tw/shen-ru-wen-zhang/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) 以取得關於 TeX box 與 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 所謂的 callback 機制編寫程式，以達到與 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 的 *朗讀* 功能擷取的音訊。它記錄了該專案中兩行文字在將 glue 轉換為空白字元之前與之後被朗讀的情況。請注意，使用空白字元的第二次朗讀，比起使用單字間 glue 的那一行，朗讀起來更快速且更流暢。 這個 Overleaf 專案是使用 LuaTeX 編譯的 plain TeX 檔案，僅供實驗用途；它無意作為完整、可供生產環境使用的解決方案。其主要設計目的是協助理解與無障礙 PDF 相關的技術問題。該專案中使用的 Lua 程式碼，基於更早期的一篇 Overleaf 文章中的工作 [Boxes and Glue：使用 LuaTeX 的簡短但具視覺化的介紹](/latex/zh-tw/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 指定為此用途。 #### 是「真實內容」還是只是 artifact？ 對於視覺障礙者而言，將內容分割並顯示在矩形頁面大小區塊中的過程會帶來不必要的副作用，例如單字斷字。此外，用來增強視覺呈現的頁面設計或版面配置方面，對看不見的人來說幾乎毫無意義。基於這些原因，PDF 內容的標記必須認知到，PDF 中某些內容應被視為一種 *artifact* 的視覺呈現或分頁結果。例如，頁碼、頁首與頁尾、陰影背景或其他設計提示都需要被識別出來，讓處理內容的無障礙軟體知道要忽略它們。 ## 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 的人存取的內容。為達成這些目標，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，檢查其內容與結構是否符合該標準的要求——例如 PDF/UA 或 PDF/A-*x*a（其中 *x* ＝ 1、2 或 3）。請注意，驗證 PDF——使用偏好的驗證工具處理它們——可能會產生診斷訊息或警告，對非專家使用者來說可能相當晦澀難懂，原因也許是某些低階 PDF 資料（或結構）未能符合相關標準。對許多作者而言，要解讀那些警告並將其轉化為文件的可操作修正，可能相當具挑戰性。 #### 免費驗證軟體 * [veraPDF](https://verapdf.org/) ，引用其網站（取用於 2020 年 5 月 28 日）的說法，它是一個「專為此目的而建立的開源檔案格式驗證器，涵蓋所有 PDF/A 部分與符合等級」。 * （僅限 Windows） [PDF 無障礙檢查器（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-tw/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 的需求：我們投入時間研究無障礙問題，探索 TeX 引擎與支援具標記 PDF 的實驗性 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-tw/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.