> 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/vi/chu-de-khac/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Giới thiệu về tệp PDF có gắn thẻ: cấu trúc bên trong và các thách thức về khả năng truy cập ## Cập nhật: Tháng 1 năm 2026 Vui lòng xem [hướng dẫn của Overleaf về cách tạo PDF có gắn thẻ](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Tính năng [nhóm LaTeX](https://latex-project.org/) đã phát hành các tính năng mới cho phép gắn thẻ PDF tự động, yêu cầu cốt lõi để PDF có thể truy cập. Các tính năng mới này khả dụng trong Overleaf trong [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), với các cập nhật mới hơn có sẵn trong bản phát hành TeX Live dạng rolling có thể truy cập thông qua [Overleaf Labs](https://www.overleaf.com/labs/participate). Giờ đây có thể tạo một PDF có gắn thẻ từ mã nguồn LaTeX tuân thủ WCAG 2.1 Mức AA bằng cách làm theo [tài liệu hướng dẫn người dùng của chúng tôi](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) sử dụng các bản phát hành TeX Live có sẵn trong Overleaf. Bài viết dưới đây từ năm 2020, tuy chưa được cập nhật với thông tin mới nhất về khả năng truy cập của LaTeX, vẫn có thể tiếp tục được đọc để tham khảo và để nắm thông tin nền về việc gắn thẻ PDF. *** ## Bài viết này đề cập đến điều gì? Mục tiêu của bài viết này là giới thiệu về PDF có gắn thẻ cùng với tổng quan về một số thách thức kỹ thuật mà phần mềm, bao gồm các bộ máy TeX và LaTeX, phải đối mặt khi hướng tới việc tạo ra các tệp PDF có gắn thẻ và có thể truy cập. Khả năng truy cập, đặc biệt là của PDF, là một chủ đề rộng và phức tạp, cũng có những thách thức kỹ thuật mà không phải lúc nào cũng có một giải pháp duy nhất, được đồng thuận hoặc chấp nhận rộng rãi—chẳng hạn như làm thế nào để biểu diễn toán học phức tạp trong PDF theo cách có thể truy cập: dùng MathML hay mã LaTeX? Mặc dù chúng ta không thể đi sâu vào mọi chủ đề, và phải đơn giản hóa nhiều chi tiết, chúng ta có thể xem bên trong PDF để thấy việc gắn thẻ một PDF thực sự bao gồm những gì. Overleaf hy vọng bài viết này sẽ là một lời giới thiệu hữu ích, cung cấp đủ bối cảnh để giúp độc giả hiểu rõ hơn các thách thức kỹ thuật và hỗ trợ việc đọc thêm cũng như khám phá tiếp về PDF có gắn thẻ và khả năng truy cập. Các tài nguyên trong bài viết này bao gồm: * [một video dài 8 phút](#video-showing-the-logical-structure-of-a-tagged-pdf) khám phá một PDF có gắn thẻ được tạo bởi LaTeX; * [một dự án Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) để tìm hiểu việc sử dụng các ký tự khoảng trắng trong LuaTeX; * [các bản ghi âm](#tagged-yes-but-the-reading-order-is-incorrect) minh họa các vấn đề về khả năng truy cập của PDF. ## Giới thiệu Đảm bảo khả năng truy cập của nội dung số được công nhận đúng đắn là một khía cạnh quan trọng của việc sản xuất và phổ biến nội dung. Hơn nữa, các chính phủ, bao gồm [Vương quốc Anh](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) và [Hoa Kỳ](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), đang ban hành các luật yêu cầu nội dung được tạo ra dưới quyền tài phán của họ phải tuân thủ các tiêu chí khả năng truy cập đã được xác định. Việc tuân thủ thông qua phát hành nội dung ở định dạng HTML không quá nặng nề, nhưng việc bảo đảm mức khả năng truy cập cần thiết cho các tài liệu được phân phối ở định dạng PDF có thể là một thách thức kỹ thuật đáng kể—tùy thuộc vào phần mềm được dùng để soạn nội dung dự định xuất ra dưới dạng tệp PDF. PDF xuất hiện vào đầu những năm 1990 như một giải pháp cho các vấn đề xoay quanh việc chuyển giao tài liệu đáng tin cậy và lịch sử đã cho thấy nó thành công vang dội. Tuy nhiên, PDF cũng là một định dạng tệp phức tạp, ra đời trước khi nhu cầu hỗ trợ khả năng truy cập nội dung tài liệu được công nhận và chấp nhận rộng rãi. Dù vậy, theo thời gian, đặc tả PDF đã phát triển để cung cấp các tính năng cho phép và hỗ trợ việc tạo ra các tài liệu PDF có thể truy cập bằng một biến thể PDF “cách điệu” mà Adobe gọi là *PDF có gắn thẻ*. Trên thực tế, việc tạo ra các tệp PDF—có gắn thẻ*và hoàn toàn có thể truy cập*—đặt ra các yêu cầu kỹ thuật bổ sung đáng kể đối với phần mềm xuất PDF—và điều đó bao gồm các bộ máy TeX cùng hệ sinh thái macro và các gói LaTeX bổ trợ. ## Sự ra đời của PDF như giấy kỹ thuật số ở dạng cuối cùng Tính năng [sự ra đời của Định dạng Tài liệu Di động (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) bắt nguồn từ một thời kỳ mà việc chuyển tài liệu giữa các máy tính đầy khó khăn, thường do việc chuyển đổi tệp gây ra hiện tượng dàn trang lại và các sai khác khác, lại còn bị làm trầm trọng thêm bởi các phông chữ và bảng mã văn bản không tương thích được dùng trên các hệ điều hành khác nhau (đáng chú ý là Windows và Macintosh). Tác giả của tài liệu này khi đó đang làm trong ngành xuất bản và vẫn còn ký ức rất rõ về việc đối phó với những thách thức đó! PDF được thiết kế để giải quyết các vấn đề chia sẻ tệp thông qua việc giới thiệu một loại giấy kỹ thuật số phổ quát, ở dạng cuối cùng (không thể chỉnh sửa), cho phép chuyển giao liền mạch các tài liệu tự chứa, mang theo các phông chữ cần thiết để hiển thị chúng. Người dùng cuối cùng có thể chuyển đủ loại tài liệu với sự tin tưởng hợp lý rằng người nhận, bất kể nền tảng máy tính nào, đều có thể mở và đọc chúng—tính nguyên vẹn của tài liệu được bảo toàn và những lần dàn trang lại lộn xộn, vấn đề tương thích/sẵn có của phông chữ đã trở thành chuyện của quá khứ. ### Giấy kỹ thuật số: có tốt cho tất cả người dùng không? Nguồn gốc của PDF, với tư cách là một dạng giấy kỹ thuật số, mặc nhiên giả định việc sử dụng số trang in, kiểu chữ hoặc các yếu tố thiết kế làm tín hiệu để điều hướng trực quan nội dung của nó—trên màn hình hay trên giấy. Tuy nhiên, những tín hiệu/cơ chế trực quan đó, dĩ nhiên, vô nghĩa đối với những người bị khiếm thị nặng. Ngày nay, việc cải thiện khả năng truy cập của nội dung số được công nhận đúng đắn là một khía cạnh quan trọng của việc sản xuất và phổ biến nội dung. Thách thức đối với PDF là cung cấp các cơ chế giúp truy cập không trực quan vào nội dung bị “đóng gói” bên trong một “container” vốn ban đầu được thiết kế để tái tạo phương tiện trực quan của trang in. Phiên bản đầu tiên của đặc tả PDF (PDF 1.0) đã được [chính thức phát hành vào ngày 15 tháng 6 năm 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) sau đó là các phiên bản mới với các cập nhật mà vào năm 2001 (PDF 1.4) đã bao gồm việc giới thiệu “PDF có gắn thẻ”, thứ mà [“...cho phép người dùng các công nghệ hỗ trợ”](https://www.adobe.com/accessibility/pdf.html). Các bản phát hành tiếp theo của đặc tả PDF đã mở rộng và nâng cao các tính năng của PDF, đỉnh điểm là bản phát hành mới nhất (PDF 2.0), mà, dựa trên [các báo cáo](https://www.pdfa.org/tagged-pdf-2-0/), đã cải tổ đáng kể các tính năng truy cập—mặc dù PDF 2.0 vẫn chưa được các bộ máy TeX hỗ trợ tốt. ## Nội dung bên trong PDF Để hiểu rõ các vấn đề liên quan, đáng xem xét cách các tệp PDF thực sự biểu diễn nội dung trang mà chúng chứa. Sâu bên trong một tệp PDF, nội dung của mỗi trang nằm trong *luồng nội dung*: một chuỗi các toán tử PDF (“lệnh”) đặt văn bản hoặc đồ họa tại một vị trí cụ thể trên trang để phần mềm đang dùng có thể kết xuất (hiển thị) khi *xem* PDF. Về thực chất, luồng nội dung cung cấp một mô tả đồ họa hay “công thức” cho các ứng dụng xem PDF biết cách “vẽ” mỗi trang—xác định điều gì sẽ được hiển thị trên trang, và ở đâu. Tất nhiên, chuỗi toán tử đó bao gồm các chỉ dẫn để chọn phông chữ cụ thể ở kích thước nhất định, chọn màu sắc, xác định độ dày đường kẻ, vẽ đường thẳng, đường cong, v.v.—mọi thứ cần thiết để cung cấp một mô tả đồ họa đầy đủ cho việc trình bày trực quan của một trang. Để giảm kích thước tệp, các luồng nội dung PDF được nén và lưu ở định dạng nhị phân gọn, nhưng nếu bạn có phần mềm thích hợp, chẳng hạn như Adobe Acrobat Pro DC, bạn có thể dùng nó để xem phiên bản văn bản thuần “đã giải nén” của các luồng nội dung trang. Hãy xem các toán tử PDF có thể “vẽ” một bảng như thế nào: luồng nội dung PDF sẽ chứa một chuỗi toán tử thích hợp để tạo các đường ngang/dọc, chọn các phông chữ khác nhau và xuất văn bản được đặt tại nhiều vị trí trên trang để tạo nên nội dung của bảng. Để minh họa, hãy xét một tài liệu PDF rất đơn giản chưa gắn thẻ, chỉ chứa một bảng cơ bản với vài dòng văn bản—được tạo trong Microsoft Word vì những lý do sẽ trở nên rõ ràng hơn ở phần sau của bài viết. Đây là ảnh chụp màn hình hiển thị PDF đơn giản của chúng ta: ![Một bảng được tạo trong Microsoft Word](/files/3580da0c0398275af33aaa5bc91a9891cf6865ce) Nếu chúng ta trích xuất luồng nội dung trang (đã giải nén) của tệp này và dán vài dòng đầu tiên vào trình soạn thảo văn bản, chúng ta có thể tóm tắt một số toán tử PDF để nắm được “hương vị” của cách các tệp PDF “mô tả” nội dung hiển thị trên trang này. ![Ảnh của luồng nội dung trong một tệp PDF](/files/c9b4dc6fab1612433f18f18eb7b3e1e5ad107ada) Nếu bạn có Adobe Acrobat Pro DC, bạn có thể dùng nó để liệt kê các toán tử có trong luồng nội dung của một trang PDF. Đây là phần *Cấu trúc PDF nội bộ* hiển thị của cùng một PDF, phần này cung cấp một mô tả ngắn gọn trên một dòng cho mọi toán tử được dùng để “vẽ” trang đơn của chúng ta chứa một bảng cơ bản—lưu ý rằng những mô tả ngắn này do Adobe Acrobat Pro DC cung cấp, chúng *không* không có sẵn trong chính tệp PDF: ![Ảnh luồng nội dung PDF được xem trong Adobe Acrobat Pro DC](/files/579d5ea674016c1eb6d0163441493fa7439c2135) Tuy nhiên, hãy lưu ý rằng không có chỉ dẫn vẽ nào (các toán tử) trong số đó lưu trữ bất kỳ “ý nghĩa” hay “mô tả” nào về thứ mà chúng thực sự tạo ra: chúng chỉ là một tập hợp các toán tử đồ họa dẫn đến việc dựng nên thứ mà một *người quan sát nhìn thấy* nhận ra là một bảng. Rõ ràng, đối với những người bị khiếm thị nặng, việc hiển thị bảng được tạo ra từ các toán tử đồ họa trong luồng nội dung của PDF không phải là một phương pháp khả thi để truy cập nội dung đó. Điều cần thiết là một cơ chế để các tệp PDF chứa một mô tả phi trực quan phù hợp (có thể đọc bằng máy) về bảng đó—và, dĩ nhiên, về mọi mục nội dung khác có trong các trang bên trong một tệp PDF. Để cho phép truy cập phi trực quan vào nội dung, các tệp PDF cần chứa dữ liệu bổ sung gán “ý nghĩa” hoặc ngữ nghĩa cho các tập hợp hay nhóm toán tử đang được dùng để “vẽ” một phần nội dung cụ thể. Tất yếu, nguyên tắc gán hay cung cấp “ý nghĩa” này phải mở rộng cho mọi dạng nội dung có trong PDF: cơ chế đó đã tồn tại và được gọi là *gắn thẻ* cho PDF để tạo ra một “biến thể” của PDF được gọi, không ngạc nhiên, là *PDF có gắn thẻ*. ## Giới thiệu PDF có gắn thẻ PDF có gắn thẻ là tên gọi dành cho một loại tệp PDF cụ thể chứa dữ liệu bổ sung (và các cấu trúc dữ liệu) không có trong các tệp PDF chưa gắn thẻ. Mặc dù các nguyên tắc/ý tưởng đằng sau PDF có gắn thẻ có thể được mô tả khái quát, nhưng chi tiết đầy đủ thì phức tạp và chiếm nhiều trang trong đặc tả PDF chính thức. Adobe đã thiết kế PDF có gắn thẻ để đạt được một số mục tiêu, trong đó có việc làm cho nội dung trở nên truy cập được đối với người dùng khiếm thị, nhưng nó cũng bao gồm danh sách sau đây được lấy từ Mục 10.7 của [đặc tả PDF 1.7 của Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * trích xuất đơn giản văn bản và đồ họa để dán vào các ứng dụng khác; * tự động dàn trang lại văn bản và đồ họa liên quan để phù hợp với một trang có kích thước khác với kích thước giả định cho bố cục gốc; * xử lý văn bản cho các mục đích như tìm kiếm, lập chỉ mục và kiểm tra chính tả; * chuyển đổi sang các định dạng tệp thông dụng khác (như HTML, XML và RTF) với cấu trúc tài liệu và thông tin kiểu dáng cơ bản được bảo toàn. Ngoài ra, PDF có gắn thẻ còn yêu cầu: * văn bản bên trong nội dung PDF phải được biểu diễn dưới dạng có thể chuyển đổi sang Unicode; * các chỗ ngắt từ phải được biểu diễn một cách tường minh—lưu ý rằng các bộ máy TeX không dùng ký tự khoảng trắng để tách từ, chúng dùng khoảng cách linh hoạt của TeX gọi là glue (xem bên dưới); * nội dung thực tế (“thực”) được phân biệt với các hiện vật của bố cục và phân trang. Cơ sở của PDF có gắn thẻ là hai khái niệm then chốt mà chúng ta sẽ xem xét: * xác định cấu trúc logic của nội dung trong một tệp PDF; * đánh dấu (gắn thẻ) nội dung PDF bằng một tập các kiểu nội dung tiêu chuẩn. ## Cấu trúc logic Trong các tài liệu dài hơn, nội dung thường được chia thành một chuỗi các mục nội dung nhỏ hơn; ví dụ, sách thường được chia thành các chương, rồi các chương lại được chia thành các mục và tiểu mục chứa các đoạn văn, bảng, hình/biểu đồ, danh sách gạch đầu dòng hoặc đánh số, chú thích cuối trang và tài liệu tham khảo, v.v. Cấu trúc và tổ chức nội dung trong một cuốn sách như vậy, hoặc bất kỳ loại tài liệu nào khác, được gọi là *cấu trúc logic*. Khái niệm cấu trúc logic của một tài liệu đóng vai trò quan trọng trong khả năng truy cập của PDF nhưng, xét như một khái niệm, cấu trúc logic có vẻ hơi mơ hồ và khó hiểu. Định nghĩa sau đây từ [Bách khoa toàn thư về Hệ thống Cơ sở dữ liệu](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) cung cấp cái nhìn hữu ích: > “Cấu trúc logic là cách thông tin trong một tài liệu được tổ chức; nó xác định hệ thống phân cấp của thông tin và mối quan hệ giữa các phần khác nhau của tài liệu. Cấu trúc logic cho biết một tài liệu được xây dựng như thế nào, thay vì tài liệu đó chứa gì.” Lưu ý rằng định nghĩa về cấu trúc logic này không đề cập chính xác đến *cách* việc thông tin cấu trúc được lưu trữ vật lý như thế nào; nó chỉ nói rằng nó cung cấp một biểu diễn của cấu trúc và tổ chức của tài liệu. Các chi tiết chính xác về cách cấu trúc logic của một tài liệu được lưu trữ hay biểu diễn phụ thuộc vào cách triển khai: là hàm của phần mềm dùng để tạo và xử lý nó. ### Cấu trúc logic trong PDF Đặc tả PDF cung cấp các cơ chế để cấu trúc logic của một tài liệu có thể được ghi lại bên trong một tệp PDF—cho phần mềm sử dụng, chẳng hạn, có thể muốn xuất nội dung PDF sang các định dạng khác như XML, HTML hoặc Microsoft Word. Các quy trình xuất đó cần tạo ra một tài liệu văn bản có cấu trúc đúng, phù hợp với các quy tắc của định dạng tệp đích—điều này đạt được tốt nhất khi quá trình xuất được dẫn dắt bởi thông tin cấu trúc logic được cung cấp trong PDF. Ngoài ra, cấu trúc logic của một tệp PDF là thiết yếu đối với phần mềm hỗ trợ khả năng truy cập, chẳng hạn có thể muốn thực hiện các thao tác chuyển văn bản thành giọng nói, đọc to nội dung cho người bị khiếm thị. Quá trình chuyển văn bản thành giọng nói cần bảo đảm nội dung được đọc to theo đúng thứ tự/trình tự, nếu không sẽ tạo ra kết quả vô nghĩa. Cũng lưu ý rằng ngay cả khái niệm về một trang có thể không có ý nghĩa đối với các ứng dụng trợ năng chỉ quan tâm đến nội dung và cấu trúc của tài liệu PDF, chứ không phải việc phân chia và trình bày trực quan thành các mẩu có kích thước trang. #### Đặt tên cho các mục nội dung Việc ghi lại (lưu trữ) cấu trúc logic của một tài liệu PDF đòi hỏi một tập hợp các tên có ý nghĩa được gán cho các *kiểu* mục nội dung có khả năng xuất hiện trong một tài liệu PDF điển hình—nhận diện các phần nội dung đại diện cho tiêu đề, đoạn văn, bảng, danh sách, v.v. Ngoài ra, một số mục nội dung như mục lục, danh sách đánh số/gạch đầu dòng và tài liệu dạng bảng có cấu trúc riêng khá phức tạp nên cũng cần có một số hướng dẫn/quy tắc để chỉ rõ cách các mục nội dung phức tạp hơn đó được tạo ra—tức là cấu trúc con của chúng. Một yêu cầu nữa là phải xác định rõ bất kỳ nội dung PDF nào nên bị phần mềm hỗ trợ khi xử lý PDF bỏ qua; ví dụ, đầu trang và chân trang là các hiện vật của phân trang chứa văn bản thừa đối với những người bị khiếm thị nặng: nội dung đó nên bị bỏ qua. Các cơ chế mà PDF dùng để xác định cấu trúc logic của một tài liệu được thiết kế để linh hoạt, vì vậy, về nguyên tắc, các ứng dụng khác nhau tạo và xử lý tệp PDF có thể dùng tên cho các kiểu nội dung theo bất kỳ quy ước nào họ chọn. Tuy nhiên, để tối đa hóa khả năng trao đổi tài liệu, cho phép các ứng dụng xử lý PDF khác nhau cho kết quả nhất quán, Adobe đã xác định một tập hợp các tên chuẩn cho các kiểu mục nội dung mà phần mềm tạo PDF nên tuân theo. Trong đặc tả PDF, các tên chuẩn đó được gọi là thẻ, dẫn tới khái niệm *PDF* PDF. ### Đánh dấu nội dung PDF: Nhìn “dưới nắp máy” Để cuộc thảo luận bớt trừu tượng hơn một chút, chúng ta sẽ xem lướt qua cấu trúc bên trong của các tệp PDF có gắn thẻ—mặc dù không thể bao quát mọi chi tiết vì PDF có gắn thẻ là một chủ đề rất lớn và phức tạp. #### Các chuỗi nội dung được đánh dấu: các khối xây dựng của PDF có gắn thẻ Ở mức thấp nhất, quá trình ghi lại ý nghĩa của nội dung chứa trong một trang PDF (tức là trong luồng nội dung của nó) bắt đầu bằng *các chuỗi nội dung được đánh dấu* được dùng để xác định (gán “ý nghĩa” cho) các cụm hoặc nhóm toán tử PDF. Các chuỗi nội dung được đánh dấu được gán một định danh số gọi là `MCID` (*định danh nội dung được đánh dấu*) là một số nguyên chạy từ 0 đến một giá trị tối đa N nào đó trên mỗi trang. Những `MCID` giá trị này cung cấp một cách để nhận diện duy nhất các chuỗi toán tử có trong luồng nội dung của một trang cụ thể. Để làm rõ, đối với mỗi trang thì các `MCID` định danh bắt đầu từ 0 và tăng tuần tự lên đến một giá trị tối đa nào đó tùy thuộc vào số lượng chuỗi nội dung được đánh dấu có trong luồng nội dung của một trang cụ thể. Trên thực tế, các chuỗi nội dung được đánh dấu là những “khối xây dựng” cơ bản được dùng để lắp ghép nên các cấu trúc dữ liệu mức cao hơn gọi là *các phần tử cấu trúc*. Các phần tử cấu trúc đó chứa một thẻ, là tên được dùng để xác định loại mục nội dung mà chúng đại diện. #### Ví dụ về các phần tử cấu trúc Ở đây chúng ta đi hơi nhanh một chút, nhưng đáng để xem một ví dụ. Giả sử bạn có 3 mảnh văn bản nhỏ của nội dung trang và mỗi mảnh được xác định trong luồng nội dung bởi một chuỗi nội dung được đánh dấu khác nhau. Mỗi trong 3 mảnh văn bản đó có thể được đóng gói vào phần tử cấu trúc riêng của nó, có một thẻ, và cả ba có thể được “liên kết với nhau” bằng một phần tử cấu trúc khác để biểu diễn một mục nội dung mức cao hơn như một dòng trong mục lục. ![Ảnh giải thích các phần tử cấu trúc và các chuỗi nội dung được đánh dấu](/files/060db5b1d77a23ce4aa00e2628a4181a4c456c05) Thông qua một dạng quan hệ dữ liệu cha–con, các tập hợp phần tử cấu trúc được kết hợp để tạo ra các cấu trúc dữ liệu liên kết đại diện cho những mục dữ liệu phức tạp hơn như danh sách đánh số và gạch đầu dòng, bảng, toán học, v.v. Cuối cùng, toàn bộ tập hợp phần tử cấu trúc chứa trong cả tệp PDF được liên kết và kết hợp thêm để tạo nên cấu trúc logic của tài liệu PDF—chúng ta sẽ quay lại điều này sau trong bài viết. ### Chuỗi nội dung được đánh dấu là gì? Trong phần thảo luận ở trên, chúng ta đã dùng một tài liệu PDF đơn giản chưa gắn thẻ chứa một bảng (được tạo trong Microsoft Word) nhưng nếu chúng ta yêu cầu Word tạo một PDF có gắn thẻ, ta có thể thấy một số đánh dấu bổ sung đã xuất hiện trong luồng nội dung trang. Ở đây, chúng ta chỉ xem xét vài dòng đầu tiên của luồng nội dung (có hàng trăm dòng) nhưng hãy chú ý sự xuất hiện của các toán tử bổ sung như `/P <> BDC` và `EMC` được dùng để xác định một chuỗi nội dung được đánh dấu. Chúng ta sẽ không khám phá toàn bộ cú pháp của các chuỗi nội dung được đánh dấu mà xin người đọc tham khảo trang 862 của [đặc tả PDF 1.7 chính thức của Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Ảnh cho thấy các chuỗi nội dung được đánh dấu trong luồng nội dung của một PDF có gắn thẻ](/files/f4385219bd341fe97508062445f79bd3f492dd1d) Để tiện đối chiếu, chúng ta lại hiển thị phiên bản chưa gắn thẻ: ![Ảnh hiển thị luồng nội dung PDF](/files/c9b4dc6fab1612433f18f18eb7b3e1e5ad107ada) Trong *chưa gắn thẻ* PDF, các toán tử như `/P <> BDC` và `EMC` không xuất hiện nhưng các toán tử còn lại không thay đổi: PDF chưa gắn thẻ thiếu phần đánh dấu bổ sung dùng để xác định một số chuỗi/tập hợp toán tử nhất định. Một lần nữa, chúng ta cũng có thể dùng tính năng của Adobe Acrobat *Cấu trúc PDF nội bộ* để xem các chuỗi nội dung được đánh dấu bên trong một luồng nội dung—ở đây, chúng ta đã làm nổi bật chúng bằng đường viền màu xanh lá: ![Ảnh cho thấy các chuỗi nội dung được đánh dấu trong luồng nội dung của PDF có gắn thẻ được xem trong Adobe Acrobat Pro DC](/files/95506b4a07a859b1dace29b69412d80b0cb32a6c) Lưu ý rằng một số phần nội dung được đánh dấu bằng `/Artifact` để xác định phần nội dung trên trang PDF nên được *bỏ qua* bởi các ứng dụng phần mềm hỗ trợ, chẳng hạn những ứng dụng đọc to cho người khiếm thị. Ảnh chụp màn hình sau cho thấy chế độ xem mở rộng của chuỗi nội dung được đánh dấu đầu tiên—chuỗi có `MCID` giá trị của `0`. Phần kết của chuỗi nội dung được đánh dấu được xác định bởi toán tử PDF `EMC`. ![Ảnh cho thấy chi tiết của các toán tử được bao hàm bởi một luồng nội dung được đánh dấu](/files/daf226dec0ce80ef64ecc35decc76b0f5026cfdd) ### Lưu trữ cấu trúc logic Như đã lưu ý, ngoài việc cung cấp mô tả cho từng mục nội dung riêng lẻ (đoạn văn, danh sách, bảng, v.v.) thì các PDF có thể truy cập cần chứa một biểu diễn của toàn bộ tài liệu dưới dạng cấu trúc logic của nó. Các phần nội dung có thể truy cập riêng lẻ phải được liên kết với nhau để tạo thành một tài liệu hoàn chỉnh, có thể điều hướng và có thể truy cập—tương tự như cách một tài liệu HTML đơn lẻ được xây dựng từ các đoạn văn, đồ họa, bảng để tạo thành một trang web. Hơn nữa, điều thiết yếu là cấu trúc logic của một tài liệu PDF phải bảo đảm rằng mọi nội dung đều có thể được điều hướng theo đúng *thứ tự đọc*, độc lập với thứ tự mà nội dung trang được ghi ra các luồng nội dung trang PDF. Chúng ta sẽ tìm hiểu thứ tự đọc chi tiết hơn bên dưới. #### Cấu trúc logic: một “cây” các phần tử cấu trúc Chúng ta đã lưu ý rằng PDF sử dụng một thứ gọi là *phần tử cấu trúc* để biểu diễn các mục nội dung riêng lẻ, và rằng một phần tử cấu trúc chứa một thẻ để xác định nó đại diện cho kiểu nội dung nào. Để cung cấp một biểu diễn của cấu trúc logic của tài liệu, tất cả các phần tử cấu trúc được liên kết với nhau, sử dụng quan hệ cha—con, và được tổ chức thành một “cây cấu trúc”. Bên trong, các tệp PDF có gắn thẻ chứa một đối tượng gọi là `StructTreeRoot` chứa (trỏ tới) các phần tử cấu trúc đóng vai trò là điểm bắt đầu hay “gốc” của cây cấu trúc logic của tài liệu. Thông thường, “gốc” của cây cấu trúc bắt đầu bằng một phần tử cấu trúc duy nhất được gắn thẻ `Document` nó chứa nhiều *con* phần tử cấu trúc con, vốn cùng nhau biểu diễn toàn bộ nội dung của tài liệu. Bất kỳ phần mềm nào được thiết kế để tạo PDF có thể truy cập thông qua gắn thẻ đều phải xây dựng cấu trúc dữ liệu rất phức tạp này (và cả những cấu trúc khác nữa!)—và điều đó bao gồm các bộ máy TeX và LaTeX. Một ví dụ về cây cấu trúc tài liệu như vậy (`StructTreeRoot`) được hiển thị trong ảnh chụp màn hình sau của một PDF có gắn thẻ đang mở trong Adobe Acrobat Pro DC: ![Ảnh cho thấy StructTreeRoot trong một PDF có gắn thẻ](/files/c9c69226a002c53bbe98e2114ef82a097f35f0e8) So sánh cấu trúc trên với phiên bản PDF chưa gắn thẻ: ![Ảnh cho thấy sự vắng mặt của StructTreeRoot trong một PDF chưa gắn thẻ](/files/316daf007b0b60922d12e39acd2bace6c5c20bc8) ### Khám phá cấu trúc logic của PDF Chúng ta bắt đầu bằng một số hình minh họa để tóm tắt những gì đã đề cập và kết thúc bằng một video dùng Adobe Acrobat Pro DC để cho thấy chi tiết hơn về cấu trúc logic của một tệp PDF có gắn thẻ. Trước hết, chúng ta bắt đầu với một sơ đồ thể hiện các nguyên tắc chung: một trang PDF với luồng nội dung của nó được đánh dấu bằng các chuỗi nội dung được đánh dấu (MCS). ![Đồ họa minh họa khái niệm các chuỗi nội dung được đánh dấu trong các trang tài liệu PDF](/files/44d025663e14aabed6225965f46b8806aab11cc5) Những MCS đó sau đó được kết hợp thành *các phần tử cấu trúc* chúng tạo thành nền tảng cho các kiểu nội dung lớn hơn, vốn lại được liên kết thêm với nhau để lưu cấu trúc logic của PDF trong một đối tượng gọi là `StructTreeRoot`. ![Đồ họa minh họa cấu trúc logic của một tệp PDF có gắn thẻ](/files/4eeca236fa4308148beefd5b59537b373e9f909e) #### Video hiển thị cấu trúc logic của một PDF có gắn thẻ Video sau (8 phút) sử dụng Adobe Acrobat Pro DC để đưa bạn đi “tham quan có hướng dẫn” nhằm khám phá chi tiết cấu trúc logic của một tệp PDF có gắn thẻ được tạo bằng LaTeX. Tệp PDF có gắn thẻ được dùng trong video có tên là `tagpdf.pdf`, đây là một ví dụ xuất sắc chứa tài liệu hướng dẫn cho gói LaTeX thử nghiệm [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Mục tiêu của `tagpdf` gói là cung cấp “các công cụ để thử nghiệm việc gắn thẻ và khả năng truy cập bằng pdfLaTeX và LuaTeX”. {% embed url="" %} ### Một lưu ý về gắn thẻ và tính linh hoạt Đặc tả HTML cung cấp một số lượng lớn các thẻ định nghĩa sẵn để dùng khi xây dựng các trang web, nhưng nó cũng cho phép sự linh hoạt trong cách bạn kết hợp chúng để tạo tài liệu HTML mong muốn. Tương tự, đặc tả PDF có gắn thẻ của Adobe cung cấp một tập các tên thẻ định nghĩa sẵn nhưng đặt ra rất ít hạn chế về cách bạn kết hợp các thẻ đó để biểu diễn các mục nội dung phức tạp trong một PDF—theo thiết kế, có rất nhiều sự linh hoạt. Ngoài ra, với bất kỳ đặc tả nào lớn và phức tạp như PDF, việc có một số điểm mơ hồ hoặc vấn đề thiếu rõ ràng len vào đặc tả viết là điều khó tránh khỏi. Các nhà phát triển phần mềm được giao nhiệm vụ triển khai một đặc tả phức tạp như vậy có thể phải đưa ra các “phán đoán” khi diễn giải nó vì họ phải chuyển các mô tả bằng văn bản thành mã chạy được. Tính linh hoạt vốn có của PDF có gắn thẻ, cùng với việc diễn giải các đặc tả (hoặc các tiêu chuẩn khả năng truy cập), tự nhiên ảnh hưởng đến các nhà phát triển ứng dụng soạn thảo tài liệu: nên dùng những tổ hợp thẻ nào để biểu diễn nội dung do người dùng tạo ra khi xuất nó sang một tệp PDF có gắn thẻ? Nếu bạn tính thêm khả năng vô hạn của người dùng trong việc tạo ra đủ loại nội dung bằng cách tận dụng các tính năng của phần mềm soạn thảo tài liệu thì bạn sẽ thấy việc tự động tạo ra các PDF có gắn thẻ, có thể truy cập, quả thật là một thách thức! Có lẽ phản ánh những phức tạp không thể tránh khỏi của việc tạo PDF có gắn thẻ hoàn toàn tuân thủ các tiêu chuẩn khả năng truy cập, trên web đầy rẫy các hướng dẫn “cách làm”, “mẹo” và lời khuyên “thực hành tốt nhất” về việc tạo PDF có gắn thẻ qua các phần mềm như Adobe InDesign hoặc Microsoft Word. Ngoài ra, PDF Association đã tạo ra một tài liệu hữu ích có tên là [Hướng dẫn thực hành tốt nhất cho PDF có gắn thẻ](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) được viết để hỗ trợ các nhà phát triển đối mặt với những thách thức khi triển khai PDF có gắn thẻ và PDF/UA. ## Có PDF nhưng nó có thể truy cập không? Để xác định liệu một tệp PDF nhất định có tuân thủ các tiêu chuẩn khả năng truy cập bắt buộc như PDF/A hay PDF/UA (xem bên dưới) hay không, nó phải được *xác thực* bằng một quy trình xác thực hoặc công cụ phần mềm đã được thống nhất. Tuy nhiên, việc xác thực thường diễn ra sau khi tài liệu đã hoàn thành, nhưng quá trình đó có thể không do chính tác giả tài liệu thực hiện mà do các chuyên gia về khả năng truy cập trong tổ chức hoặc cơ quan đã yêu cầu tuân thủ. Nếu PDF không đạt xác thực thì có thể cần can thiệp thủ công có kỹ năng qua Adobe Acrobat Pro DC để sửa phần gắn thẻ (nếu có thể). Hoặc, nó thậm chí có thể phải quay lại cho tác giả để chỉnh sửa tài liệu gốc, có lẽ bằng cách tránh sử dụng những tính năng của phần mềm soạn thảo đã gây ra vấn đề—điều này có thể cực kỳ khó thực hiện vì có thể vượt quá quyền kiểm soát của tác giả. ### Thứ tự đọc và thứ tự nội dung Như đã lưu ý, việc tạo ra các PDF thực sự có thể truy cập đặt ra các yêu cầu kỹ thuật bổ sung đối với phần mềm soạn thảo và, tiềm năng, cả với tác giả tài liệu bằng cách áp đặt “kỷ luật soạn thảo” trong cách họ dùng/áp dụng các tính năng của phần mềm soạn thảo. Mặc dù PDF có gắn thẻ là cơ chế *cho phép* tạo ra các PDF hoàn toàn có thể truy cập, thì chỉ vì một PDF được gắn thẻ cũng không *không* tự động có nghĩa là nó hoàn toàn có thể truy cập, như chúng ta sẽ thấy trong một ví dụ bên dưới. Để tạo ra các PDF hoàn toàn có thể truy cập, tất cả các mục nội dung trong PDF phải được gắn thẻ để tạo ra một cấu trúc logic bảo đảm nội dung có thể được truy cập và đọc theo đúng trình tự—được gọi là *thứ tự đọc*. Điều này có vẻ “hiển nhiên” nhưng khi phần mềm ghi ra một tệp PDF, nó có thể xuất đồ họa và văn bản vào các luồng nội dung trang theo bất kỳ thứ tự nào nó chọn. Ví dụ, giả sử một trang bắt đầu bằng một ít văn bản, tiếp theo là một bảng và kết thúc bằng một đồ họa, tạo ra một *thứ tự đọc* trình tự tự nhiên của: 1. text 2. table 3. đồ họa Khi được ghi vào PDF, phần mềm tạo luồng nội dung cho trang đó có thể bắt đầu bằng các toán tử để vẽ bảng, sau đó xuất các toán tử để tạo đồ họa rồi đến các toán tử cho văn bản, điều này trong luồng nội dung sẽ tạo ra một *thứ tự nội dung* trình tự tự nhiên của: 1. table 2. đồ họa 3. text Tất nhiên, mọi thứ sẽ được đặt đúng vị trí khi trang đó được xem. Đối với một người nhìn đầy đủ, thứ tự mà các mục đó được lưu bên trong luồng nội dung của trang không hề đáng quan tâm: họ thấy một trang đã được kết xuất hoàn chỉnh với mọi thứ ở đúng vị trí. Tuy nhiên, nếu phần mềm hỗ trợ phải dựa vào thứ tự của các mục trong một luồng nội dung (thứ tự nội dung) thì nó sẽ gặp khó khăn nếu thứ tự nội dung khác với thứ tự đọc tự nhiên; chẳng hạn, các công cụ đọc to sẽ đọc nội dung sai trình tự. May mắn là phần mềm hỗ trợ có thể dùng thứ tự logic (cấu trúc) của một PDF có gắn thẻ, thứ tự này phải được tổ chức để phản ánh trình tự mà nội dung nên được đọc. Chính vì những lý do đó mà dữ liệu biểu diễn cấu trúc logic của tài liệu được lưu riêng biệt với nội dung thực tế hiển thị trên các trang nhìn thấy được, để cho phép > “... việc sắp xếp và lồng ghép các phần tử nội dung logic hoàn toàn độc lập với thứ tự và vị trí của các đối tượng đồ họa trên các trang của tài liệu.” (trang 856 của [PDF Reference, ấn bản thứ sáu, tháng 11 năm 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) Trên thực tế, việc bảo đảm một thứ tự logic giữ nguyên thứ tự đọc còn thách thức hơn nhiều so với vẻ bề ngoài, vì vậy hãy dùng một ví dụ đơn giản, dù là giả tạo, để cho thấy những vấn đề liên quan. #### Thứ tự đọc không đúng: Một ví dụ dùng Microsoft Word Tác giả của một tài liệu có thể dùng các tính năng của phần mềm soạn thảo đã chọn để đạt được một hiệu ứng trực quan cụ thể—chẳng hạn dùng bảng để tạo một bố cục văn bản đặc biệt. Ví dụ, ảnh chụp màn hình sau cho thấy tài liệu Microsoft Word được dùng trong các ví dụ trước. Nó chứa một bảng đã được dùng để tạo ra một bộ các đoạn văn được đánh số đặt cạnh nhau. Nhưng khi gắn thẻ nội dung này, nó nên được xử lý như thế nào: gắn thẻ là một bảng hay một danh sách đánh số? Cả hai kiểu nội dung đó đều cần một cấu trúc gắn thẻ phức tạp để biểu diễn đúng. Trong hình sau, hãy chú ý thứ tự mà các đoạn văn được đánh số dự định sẽ được đọc: theo cột, không phải theo hàng. ![Ảnh của một bảng được tạo trong Microsoft Word](/files/e48014afefb656165ac6a62522ef3dccf9725f9c) Nếu chúng ta yêu cầu Word lưu tài liệu này thành PDF bằng chức năng xuất tích hợp sẵn của nó — không phải plugin Acrobat PDFMaker — chúng ta có thể bảo nó tạo PDF có gắn thẻ: ![Hộp thoại Tùy chọn của quy trình xuất của Microsoft Word](/files/aed64c12704feb44b4aefe377603ed8657052a2a) Vậy Word gắn thẻ bố cục này như thế nào? Trong video rất ngắn sau đây (14 giây), chúng ta dùng Adobe Acrobat Pro DC để kiểm tra cấu trúc gắn thẻ do Microsoft Word tạo ra. {% embed url="" %} Đối với tài liệu này, Word đã tạo một tài liệu PDF có gắn thẻ sử dụng một `Table` thẻ chứa hai thẻ con: `THead` cho nhóm hàng tiêu đề của bảng và `TBody` để biểu diễn nhóm các hàng cho phần thân bảng. `THead` và `TBody` đều chứa `TR` các thẻ để biểu diễn từng hàng nội dung. Các `TR` thẻ chứa các thẻ tiếp theo để biểu diễn mục danh sách được đánh số có trong mỗi ô. Ảnh chụp màn hình sau đây cho thấy cấu trúc gắn thẻ lồng rất sâu và cấu trúc logic tương ứng phức tạp cần thiết để biểu diễn ngay cả tài liệu cực kỳ cơ bản này! ![Hình ảnh cho thấy cấu trúc gắn thẻ lồng sâu và cấu trúc logic của một bảng đơn giản được tạo trong Microsoft Word](/files/8648fa310d7dc222d65551cae23efa0b7abf535e) So với các PDF được tạo bởi TeX và LaTeX, ví dụ Word này là một tài liệu cực kỳ đơn giản, nhưng nó vẫn cần một cấu trúc logic phức tạp để biểu diễn. Hãy tưởng tượng mức độ phức tạp của việc gắn thẻ cần thiết để biểu diễn các PDF do LaTeX tạo ra có chứa toán học và bảng biểu phức tạp! #### Có gắn thẻ, đúng vậy, nhưng thứ tự đọc thì sai Mặc dù Word có tạo ra một [PDF có gắn thẻ](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) nó cho thấy một trong những thách thức cơ bản mà bất kỳ ứng dụng nào cố gắng tạo ra PDF có khả năng truy cập đầy đủ đều phải đối mặt: biểu diễn đúng thứ tự đọc dự kiến của nội dung. Trong quá trình tạo PDF có gắn thẻ, các quy trình nội bộ của Word đã quyết định ghi luồng nội dung tương ứng bằng cách xuất bảng theo từng hàng, chứ không phải theo từng cột. Đối với người đọc nhìn bình thường xem PDF, những chi tiết cấp thấp này không tạo ra khác biệt gì: bảng hiển thị đúng. Tuy nhiên, với người khiếm thị, cấu trúc tài liệu logic của Word tạo ra kết quả sai vì thứ tự đọc mong muốn (theo cột) không được giữ nguyên: nội dung được đọc to theo thứ tự sai. Bản ghi âm sau đây được tạo bằng tính năng “Read Out Loud” của Adobe Reader DC. Như có thể thấy, văn bản được đọc theo trình tự sai: theo từng hàng, không phải theo từng cột: ![Một bảng được tạo trong Microsoft Word](/files/1987969db282720c8ac4eb3953733be51f09f0dd) Như đã lưu ý ở trên, ví dụ này hơi gượng ép nhưng nó cho thấy việc kết hợp các tính năng phần mềm có thể rất dễ kích hoạt các vấn đề về khả năng truy cập như thế nào — nhưng tác giả tài liệu phải biết trước điều này bằng cách nào? Rất có thể vấn đề này chỉ được phát hiện nếu PDF kết quả trải qua các bài kiểm tra sử dụng khả năng truy cập thực tế — ví dụ, bằng phần mềm hỗ trợ. Có khả năng các tài liệu như vậy có thể vượt qua các bài kiểm tra tuân thủ/xác thực PDF/A nhưng lại thất bại trong sử dụng “thực tế”. Để bảo đảm thứ tự đọc đúng của một tệp PDF như thế này sẽ cần sự can thiệp thủ công có kỹ năng bằng cách sử dụng các công cụ chỉnh sửa PDF nâng cao như Adobe Acrobat Pro DC: một quy trình tốn thời gian và chi phí cao. Hoặc tác giả tài liệu có thể kiềm chế không sử dụng dạng biểu đạt nội dung hay bố cục cụ thể này — nhưng chỉ nếu họ biết nó có vấn đề! ### Sử dụng ký tự khoảng trắng để phân tách các từ Khi bạn nhập văn bản vào trình xử lý văn bản hoặc trình soạn thảo văn bản, bạn dùng ký tự khoảng trắng để đánh dấu kết thúc của một từ và bắt đầu của từ tiếp theo. Nếu sau đó bạn tạo PDF từ tài liệu như vậy, các ký tự khoảng trắng bạn đã gõ tất nhiên sẽ được xuất ra và trở thành một phần của văn bản được lưu trong PDF. Tuy nhiên, các bộ máy TeX không dùng ký tự khoảng trắng để phân tách các từ trong văn bản dàn trang; thay vào đó, chúng chuyển ký tự khoảng trắng thành một dạng giãn cách linh hoạt gọi là glue (xem [bài viết trên Overleaf](/latex/vi/bai-viet-chuyen-sau/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) để biết thêm thông tin về các box và glue của TeX). Trong luồng nội dung của các trang PDF được tạo bởi bộ máy TeX, việc tách từng từ được thực hiện bằng cách di chuyển đến một vị trí khác trên trang và bắt đầu văn bản cho từ tiếp theo — thay vì xuất ra một ký tự khoảng trắng để tạo khoảng cách đó. Hơn nữa, lượng khoảng cách giữa các từ trong các đoạn văn bản được dàn trang bởi bộ máy TeX thay đổi từ dòng này sang dòng khác do thuật toán ngắt dòng của TeX. Sự thay đổi đó được phản ánh trong dữ liệu vị trí được ghi ra luồng nội dung của các trang PDF. Khía cạnh này của việc dàn trang bằng TeX có ảnh hưởng đến việc sao chép/dán văn bản từ các PDF của nó và đến phần mềm hỗ trợ cố gắng đọc to văn bản được dàn trang trong các PDF do bộ máy TeX tạo ra. Phần mềm hỗ trợ phải phân tích luồng nội dung của một trang PDF để trích xuất văn bản mà nó cần xử lý. Rõ ràng, phần mềm như vậy cần một cơ chế nào đó để phát hiện điểm bắt đầu và kết thúc của các từ — giải pháp rõ ràng nhất là dùng ký tự khoảng trắng. Với điều đó trong đầu, các tiêu chuẩn khả năng truy cập yêu cầu từng từ phải được kết thúc rõ ràng (ví dụ, bằng ký tự khoảng trắng), điều này gây vấn đề cho các bộ máy TeX do chúng sử dụng glue giữa các từ. #### Nhưng chưa phải hết đường! Vào năm 2014, pdfTeX đã giới thiệu 2 lệnh nguyên thủy mới để cải thiện hỗ trợ khả năng truy cập bằng cách cho phép sử dụng ký tự khoảng trắng giữa các từ trong các PDF mà nó xuất ra: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Các lệnh này sử dụng một “font giả” chỉ chứa một glyph khoảng trắng. Chi tiết và ví dụ có thể tìm thấy ở trang 29 của [Sổ tay Người dùng pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Sử dụng LuaTeX: Một ví dụ trong Overleaf Gallery LuaTeX không hỗ trợ các lệnh nguyên thủy pdfTeX đó nhưng nó có thể được lập trình để đạt kết quả rất giống pdfTeX bằng cách sử dụng cơ chế callback của LuaTeX. Một dự án Overleaf để chuyển glue thành ký tự khoảng trắng có sẵn trong Overleaf Gallery dưới tiêu đề [Sử dụng LuaTeX để chuyển glue giữa các từ thành khoảng trắng và kern](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Nếu bạn dàn trang mã LaTeX bằng LuaTeX (tức là tùy chọn trình biên dịch LuaLaTeX trên Overleaf) thì, bằng cách sử dụng mã Lua, bạn có thể hậu xử lý một đoạn văn đã dàn trang để tìm bất kỳ glue giữa các từ nào và thay nó bằng một ký tự khoảng trắng cộng với một kern thích hợp. Khoảng cách do độ rộng của ký tự khoảng trắng cung cấp có thể được cộng thêm (hoặc giảm bớt) bằng cách tính một giá trị kern phù hợp để giữ nguyên lượng khoảng cách do glue giữa các từ cung cấp, dẫn đến không có khác biệt trực quan nào đối với kết quả dàn trang. Để hiểu sự khác biệt điều này tạo ra cho người dùng phần mềm hỗ trợ khả năng truy cập, hãy nghe bản ghi âm thanh này được ghi lại từ tính năng *Read Out Loud* của Adobe Reader DC. Nó ghi lại hai dòng văn bản trong dự án đó được đọc to, trước và sau khi chuyển glue thành khoảng trắng. Hãy chú ý cách lần đọc thứ hai của dòng, dùng khoảng trắng, được đọc nhanh và trôi chảy hơn so với dòng dùng glue giữa các từ. Dự án Overleaf là một tệp plain TeX được biên dịch bằng LuaTeX và chỉ được cung cấp cho mục đích thử nghiệm; nó không nhằm trở thành một giải pháp hoàn chỉnh, chất lượng sản xuất. Chủ yếu, nó được thiết kế để hỗ trợ hiểu các vấn đề kỹ thuật liên quan đến PDF có khả năng truy cập. Mã Lua được dùng trong dự án đó dựa trên công trình có trong một bài viết Overleaf sớm hơn nhiều [Hộp và Glue: Giới thiệu ngắn gọn, nhưng trực quan, bằng LuaTeX](/latex/vi/bai-viet-chuyen-sau/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Lưu ý: Để đơn giản, dự án sử dụng bộ nạp phông OpenType rất tối giản của riêng nó, được dẫn xuất từ mã này: . ### Các vấn đề khả năng truy cập khác và PDF có gắn thẻ Mặc dù việc gắn thẻ cho phép xác định các mục nội dung có trong một PDF, một số loại nội dung, chẳng hạn như đồ họa hoặc toán học phức tạp, đòi hỏi dữ liệu hoặc thông tin bổ sung nếu chúng muốn được làm cho có thể truy cập thông qua phần mềm được thiết kế để hỗ trợ người khiếm thị. Để cung cấp và hỗ trợ khả năng truy cập cho nhiều loại nội dung, đặc tả PDF cung cấp khả năng đính kèm “Mô tả thay thế” hoặc “ActualText” cho các mục nội dung, cung cấp các mô tả văn bản phù hợp hoặc các biểu diễn khác có thể đọc được bằng máy. Ví dụ, MathML đã được chỉ định cho mục đích này trong đặc tả PDF 2.0. #### Đó là “nội dung thực” hay chỉ là một phần phụ trợ? Đối với người khiếm thị, quá trình chia nhỏ và hiển thị nội dung thành các khối hình chữ nhật kích thước bằng trang có các tác dụng phụ không mong muốn, chẳng hạn như ngắt từ bằng dấu gạch nối. Hơn nữa, các khía cạnh của thiết kế hay bố cục trang được dùng để nâng cao trình bày trực quan lại hoàn toàn vô nghĩa đối với những người không thể nhìn thấy. Vì những lý do này, việc gắn thẻ nội dung PDF phải thừa nhận rằng một số nội dung trong PDF nên được coi là một *artifact* của trình bày trực quan hoặc phân trang. Ví dụ, số trang, đầu trang và chân trang, nền tô bóng hoặc các dấu hiệu thiết kế khác cần được xác định để phần mềm hỗ trợ xử lý nội dung biết mà bỏ qua chúng. ## Tổng quan về các tiêu chuẩn PDF/A Các yêu cầu tạo PDF có khả năng truy cập thường viện dẫn một tiêu chuẩn ISO có tên [ISO 19005](https://www.iso.org/standard/38920.html), thường được gọi là PDF/A. Tuy nhiên, vì PDF/A là một *họ* bộ tiêu chuẩn, việc chỉ yêu cầu “tuân thủ PDF/A” có thể chưa nêu đầy đủ các yêu cầu thực tế. Để hiểu vì sao, hãy bắt đầu bằng một phác thảo ngắn về PDF/A từ trang web của [Hiệp hội PDF](https://www.pdfa.org/resource/iso-19005-pdfa/) (truy cập ngày 21 tháng 5 năm 2020) mô tả ISO 19005 (PDF/A) như sau: > “Mục đích chính của ISO 19005 là định nghĩa một định dạng tệp dựa trên PDF, được gọi là PDF/A, cung cấp một cơ chế biểu diễn tài liệu điện tử theo cách bảo toàn diện mạo trực quan tĩnh của chúng theo thời gian, độc lập với các công cụ và hệ thống được dùng để tạo, lưu trữ hoặc kết xuất các tệp.
> > Mục đích thứ hai của ISO 19005 là định nghĩa một khuôn khổ để biểu diễn cấu trúc logic và các thông tin ngữ nghĩa khác của tài liệu điện tử trong các tệp tuân thủ.
> > Một mục đích khác của ISO 19005 là cung cấp một khuôn khổ để ghi lại ngữ cảnh và lịch sử của tài liệu điện tử trong siêu dữ liệu bên trong các tệp tuân thủ.” Rõ ràng, PDF/A có một số mục tiêu cốt lõi. ### Sự tiến hóa và phát triển của PDF Tính năng [Đặc tả PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) được công bố vào năm 1993 và chỉ có 230 trang. Tuy nhiên, 13 năm sau, đặc tả cho [Phiên bản 1.7 của PDF của Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) đã vượt quá 1000 trang! Theo thời gian, kích thước và độ phức tạp của đặc tả PDF đã tăng lên bằng cách bổ sung bộ tính năng được hỗ trợ: bao quát các công nghệ mới và các yêu cầu của những quy trình làm việc và trường hợp sử dụng dựa trên PDF ngày càng tinh vi trong các thị trường và cộng đồng khác nhau. Tuy nhiên, có lẽ không có người dùng, hay nhóm người dùng nào, sử dụng hết mọi khả năng: PDF phải “bao quát mọi phương diện” để bảo đảm nó có thể đáp ứng nhu cầu của thị trường rộng nhất có thể. Ví dụ, nhiều tính năng PDF được thiết kế để hỗ trợ in ấn thương mại cao cấp không cần thiết cho việc sử dụng văn phòng hằng ngày điển hình như một định dạng để lưu trữ hoặc chia sẻ tài liệu. ### PDF/A: “trở về những điều cơ bản” của PDF Mục tiêu cốt lõi của PDF/A là bảo đảm các PDF tuân thủ phù hợp cho lưu trữ dài hạn hoặc chứa nội dung có thể truy cập được đối với những người sử dụng nhiều công nghệ hỗ trợ khác nhau để “tiêu thụ” các PDF đó. Để đạt được các mục tiêu này, PDF/A hạn chế tập hợp các tính năng PDF được phép trong các tệp PDF tuân thủ, cấm sử dụng những tính năng có thể làm tổn hại khả năng lưu trữ hoặc khả năng truy cập. Bạn có thể xem PDF/A như một tập hợp các tiêu chuẩn quy định cách các tệp PDF tuân thủ sử dụng một *tập con* phần của đặc tả PDF đầy đủ để tạo ra các tệp phù hợp cho lưu trữ dài hạn hoặc bảo đảm nội dung của chúng có thể truy cập được. Các hạn chế của PDF/A cho phép PDF được dùng như một “giấy số lưu trữ” độc lập với công nghệ đọc PDF và môi trường máy tính được dùng để truy cập nội dung của chúng. Các PDF tuân thủ không nên chứa bất cứ thứ gì có hành vi “phụ thuộc vào cách triển khai” — tức là phụ thuộc vào phần mềm hoặc hệ điều hành cụ thể đang được dùng để xem hay xử lý chúng. PDF cũng phải là *đầy đủ*: các tài nguyên tài liệu quan trọng phải được nhúng trong tệp — chẳng hạn như phông chữ hoặc hồ sơ màu. ### Các phiên bản PDF/A và mức độ tuân thủ Có các *các phiên bản* khác nhau của tiêu chuẩn PDF/A, mỗi loại phản ánh một phiên bản cụ thể của đặc tả PDF chính thức (PDF 1.4, 1.7 và 2.0). Ngoài ra, còn có các *mức độ tuân thủ* xác định khía cạnh nào của tiêu chuẩn PDF/A mà một tệp PDF tuân theo. Do đó, khi tuyên bố hoặc yêu cầu “tuân thủ PDF/A” bạn nên nghĩ đến các tệp PDF tuân theo **PDF/A-** Ví dụ * PDF/A-1a: nghĩa là phiên bản PDF/A 1, mức tuân thủ a * PDF/A-2b: nghĩa là phiên bản PDF/A 2, mức tuân thủ b Chúng ta sẽ tìm hiểu những điều này chi tiết hơn một chút. #### Các phiên bản PDF/A Tiêu chuẩn PDF/A nằm dưới sự bảo trợ của ISO, được công bố dưới dạng một tiêu chuẩn có tên ISO 19005. Như đã lưu ý, đặc tả PDF đã phát triển theo thời gian và điều đó, đến lượt nó, đã đòi hỏi cập nhật ISO 19005, tạo ra bảng dưới đây: | | | | | ------------------- | ------------------ | -------------------------- | | **Phiên bản PDF/A** | **Tiêu chuẩn ISO** | **Dựa trên phiên bản 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) | Tại thời điểm viết bài này (tháng 4/tháng 5 năm 2020), một bản cập nhật PDF/A-4 (ISO 19005-4) đang [được chuẩn bị](https://www.iso.org/standard/71832.html). #### Các mức độ tuân thủ PDF/A Ngoài ba phiên bản PDF/A (PDF/A-1, PDF/A-2 và PDF/A-3) còn có ba *mức độ tuân thủ*: * Mức A (có khả năng truy cập) cho khả năng truy cập (bao gồm các yêu cầu lưu trữ của Mức B) * Mức B (cơ bản) cho lưu trữ * Mức U (Unicode) (= lưu trữ cộng với việc dùng Unicode cho văn bản) Sau đây là mô tả ngắn về các mức độ tuân thủ này: * **Mức B (cơ bản)** là yêu cầu tối thiểu để tuân thủ theo PDF/A. Nó xác định các yêu cầu nhằm bảo đảm các tài liệu PDF tuân thủ phù hợp cho lưu trữ dài hạn — rằng chúng luôn có thể được xem hoặc in một cách đáng tin cậy, độc lập với phần mềm, công cụ hay hệ điều hành cụ thể. * **Mức A (khả năng truy cập)** bao gồm các yêu cầu của mức tuân thủ B nhưng, ngoài ra, còn yêu cầu sử dụng PDF có gắn thẻ để cung cấp cấu trúc logic và thông tin thứ tự đọc cùng với việc sử dụng Unicode để cho phép truy cập vào văn bản của tài liệu. * **Mức U (Unicode)** mức tuân thủ được thêm vào PDF/A-2 và xây dựng trên Mức B bằng cách bổ sung yêu cầu sử dụng Unicode cho văn bản tài liệu, nhưng không đi xa như Mức A ở chỗ bắt buộc thông tin cấu trúc. Các phiên bản PDF/A và mức độ tuân thủ có thể được tóm tắt trong một bảng: | | | | | | ---------------------------- | ----------------------------------------- | -------- | -------- | | **Mức tuân thủ** | **PDF/A-** | | | | Mức A (có khả năng truy cập) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Mức B (cơ bản) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Mức U (Unicode) | Không áp dụng (không tồn tại cho PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Khả năng truy cập phổ quát”) Mặc dù việc tuân thủ Mức A của tiêu chuẩn PDF/A đi được một phần trong việc xác định các yêu cầu cho PDF có khả năng truy cập, một tiêu chuẩn ISO khác có tên [ISO 14289](https://www.iso.org/standard/64599.html), được gọi là PDF/UA, đi xa hơn nữa. PDF/UA tăng cường các yêu cầu về khả năng truy cập và làm rõ hướng dẫn có trong các tiêu chuẩn PDF/A, và đã trở thành tiêu chuẩn được ưu tiên cho PDF có khả năng truy cập. #### Giao thức Matterhorn Những độc giả quan tâm sâu sắc muốn tìm hiểu thêm về tuân thủ PDF/UA có thể quan tâm đến [Giao thức Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) là “danh sách tất cả các cách có thể khiến không tuân thủ PDF/UA”. ### Phần mềm xác thực Để kiểm tra xem một tệp PDF có tuân theo một tiêu chuẩn cụ thể hay không, nó phải được *xác thực* bằng phần mềm tuân thủ quét qua PDF để kiểm tra xem nội dung và cấu trúc của nó có phù hợp với các yêu cầu của tiêu chuẩn đó hay không — chẳng hạn như PDF/UA hoặc PDF/A-*x*a (trong đó *x* = 1, 2 hoặc 3). Lưu ý rằng việc xác thực PDF — xử lý chúng bằng một công cụ xác thực ưa thích — có thể tạo ra các thông báo chẩn đoán hoặc cảnh báo khá khó hiểu đối với người dùng không chuyên — có lẽ do một số dữ liệu PDF cấp thấp (hoặc cấu trúc) không đáp ứng tiêu chuẩn liên quan. Đối với nhiều tác giả, việc diễn giải những cảnh báo đó và chuyển chúng thành một bản sửa chữa có thể áp dụng cho tài liệu của họ có thể là một thách thức khá lớn. #### Phần mềm xác thực miễn phí * [veraPDF](https://verapdf.org/) mà, theo trích dẫn trên trang web của họ (truy cập 28 tháng 5 năm 2020), là một “trình xác thực định dạng tệp, mã nguồn mở, được xây dựng chuyên dụng, bao quát tất cả các phần và mức độ tuân thủ PDF/A”. * (chỉ dành cho Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) là một “...công cụ kiểm tra khả năng truy cập PDF miễn phí đã được thử nghiệm và kiểm chứng từ năm 2010”. #### Phần mềm xác thực thương mại * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) cung cấp một bộ kiểm tra xác thực PDF cùng với các công cụ để chỉnh sửa và sửa các thẻ trong các tệp PDF không tuân thủ. ### Hiệp hội PDF: một nguồn thông tin tuyệt vời Tính năng [Hiệp hội PDF](https://www.pdfa.org/) cung cấp nhiều *tuyệt vời* tài nguyên về PDF/A, PDF/UA và nhiều chủ đề khác liên quan đến PDF — bao gồm video trên [kênh YouTube của họ](https://www.youtube.com/user/ThePDFAssociation/playlists) cùng với các bài viết và ấn phẩm kỹ thuật miễn phí có sẵn trên trang web của họ. Một ấn phẩm như vậy là [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) cung cấp phần giới thiệu vô giá về tiêu chuẩn PDF/UA và các yêu cầu của nó. ## PDF có thể truy cập từ các bộ máy TeX và LaTeX Hy vọng rằng các thảo luận trước đó đã chỉ ra rằng việc tạo ra các tệp PDF có khả năng truy cập đầy đủ và được gắn thẻ đúng là một thách thức kỹ thuật đòi hỏi cao. Hơn nữa, ngay cả ví dụ Microsoft Word đơn giản cũng cho thấy tác giả có thể rất dễ dàng sử dụng các tổ hợp tính năng phần mềm dẫn đến các tài liệu PDF có gắn thẻ nhưng không đạt các tiêu chí khả năng truy cập. Với tư cách là một công cụ soạn thảo, LaTeX cung cấp cho tác giả sự linh hoạt gần như vô hạn về phạm vi và độ phức tạp của các tài liệu bạn có thể tạo ra — điều này có thể chính là lý do chọn nó ngay từ đầu. LaTeX cũng hỗ trợ khả năng mở rộng thông qua hàng nghìn gói bổ trợ mà tác giả có thể dùng trong tài liệu của mình. Thêm vào đó, tác giả có quyền viết các macro TeX hay LaTeX mới, hoặc định nghĩa lại các macro hiện có, để đạt được những hiệu ứng cụ thể. Tuy nhiên, có lẽ sự tự do và linh hoạt này phải trả giá, vì nội dung được tạo ra bởi vô số tương tác của tất cả các gói LaTeX và macro đó “bằng cách nào đó” cần được điều phối nếu LaTeX muốn tự động tạo đầu ra PDF được gắn thẻ đúng và có khả năng truy cập. Trên thực tế, khả năng mở rộng, sức mạnh, tính linh hoạt và “tự do” soạn thảo mà LaTeX mang lại đặt ra các thách thức kỹ thuật cho việc tạo ra liền mạch và minh bạch (“tự động”) các tài liệu PDF có gắn thẻ và khả năng truy cập đầy đủ tuân thủ các tiêu chuẩn PDF/UA hoặc PDF/A-{1|2|3}a. Cộng đồng TeX và LaTeX rộng lớn hơn đang nỗ lực mạnh mẽ để giải quyết những thách thức đó và Nhóm Người dùng TeX (TUG) đang phối hợp các nỗ lực nghiên cứu và phát triển thông qua nhóm làm việc về khả năng truy cập PDF và tiêu chuẩn PDF [nhóm làm việc](https://www.tug.org/twg/accessibility/). Có một [danh sách thảo luận](https://tug.org/mailman/listinfo/accessibility) cung cấp một cách để các bên quan tâm thảo luận về việc tạo các tệp PDF có gắn thẻ bằng TeX và LaTeX. Trong các thảo luận này, cần nhớ rằng LaTeX thực ra không phải là một chương trình dàn trang thực thi, mà là một bộ sưu tập lớn các macro tinh vi (lệnh) được viết bằng một ngôn ngữ cấp thấp hơn gọi là TeX. Nằm giữa tài liệu LaTeX được bạn soạn thảo cẩn thận và tệp PDF dàn trang cuối cùng là một phần mềm gọi là bộ máy TeX, nhiệm vụ của nó là “thực thi” tập hợp các lệnh LaTeX (tức là các macro) được dùng để viết và xây dựng tài liệu của bạn — chuyển chúng thành bản dàn trang của tài liệu được lưu dưới dạng tệp PDF. Những ai mới làm quen với hệ sinh thái TeX/LaTeX thường, và dễ hiểu là, bị bối rối bởi vô số tên gọi nghe bí hiểm dùng cho các công cụ mà họ gặp: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX và LuaLaTeX. Nếu bạn cũng cảm thấy như vậy, đã có sự trợ giúp trong bài viết Overleaf [Tên gọi có ý nghĩa gì: Hướng dẫn về nhiều biến thể của TeX](/latex/vi/bai-viet-chuyen-sau/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) giải thích nguồn gốc và ý nghĩa của tất cả những thuật ngữ đó. Các bộ máy TeX như pdfTeX, XeTeX hay LuaTeX là một lớp phần mềm gọi là *trình biên dịch tài liệu*: chúng lấy mã LaTeX của bạn và biên dịch nó thành dạng dàn trang bằng cách “chuyển đổi” các macro (lệnh) LaTeX trở lại thành các chỉ dẫn ngôn ngữ TeX cấp thấp hơn của chúng, vốn được “thực thi” để tạo ra kết quả dàn trang. Các hệ thống dàn trang dựa trên TeX có khả năng tạo ra nội dung cực kỳ phức tạp — bao gồm toán học nâng cao, ký hiệu nhạc, cấu trúc hóa học, đồ họa và văn bản dàn trang đa ngôn ngữ tinh vi. Để bảo đảm những tài liệu phức tạp đó tuân thủ các tiêu chuẩn và quy định về khả năng truy cập, các bộ máy TeX, cùng với bộ macro LaTeX và các gói LaTeX, cần tạo ra các tệp PDF có gắn thẻ thích hợp bằng cách nhúng rất nhiều dữ liệu bổ sung vào các tệp PDF mà chúng tạo ra. Mặc dù các bộ máy TeX có thể tạo ra các tệp PDF cực kỳ phức tạp, các quy trình nội bộ, thuật toán và hàm của chúng không có *tích hợp sẵn* các tính năng *được thiết kế đặc biệt* để hỗ trợ việc tạo ra các PDF có gắn thẻ và khả năng truy cập. Thay vào đó, hỗ trợ cho việc gắn thẻ và khả năng truy cập phải được đạt tới thông qua lập trình macro phức tạp, vốn “chèn” dữ liệu bổ sung vào các PDF do bộ máy TeX tạo ra — tạo ra các chuỗi nội dung được đánh dấu, các phần tử cấu trúc và cấu trúc dữ liệu cấu trúc logic được lưu trong `StructTreeRoot`. Và đây là nơi mà việc “điều phối” trở nên nổi bật: mã trong lõi (kernel) của LaTeX cùng với mã trong hàng nghìn gói và vô số macro do tác giả tạo ra sẽ phải phối hợp rất cẩn thận để bảo đảm việc thực thi macro tạo ra việc gắn thẻ đúng cho nội dung của các tài liệu kết quả. Sự “điều phối” đó sẽ phải đáng tin cậy — bất kể tác giả chọn kết hợp và sử dụng các tính năng, lệnh và chức năng của LaTeX, hệ thống gói của nó và sức mạnh của các macro TeX như thế nào. ### Nhu cầu của tác giả Đối với hầu hết mọi người, LaTeX chỉ là một công cụ cho phép bạn tạo ra các tài liệu được dàn trang đẹp mắt với sự tự do chọn và dùng các gói để hỗ trợ đạt được điều đó. Phần lớn tác giả dùng LaTeX chỉ đơn giản muốn tài liệu của họ “hoạt động”: dàn trang không lỗi để họ có thể nộp luận văn, bài báo, báo cáo hoặc hoàn thành cuốn sách đã chờ đợi từ lâu. Không phải là vô lý, người dùng LaTeX kỳ vọng tập hợp các gói LaTeX họ chọn sẽ cùng tồn tại hòa thuận, tương tác liền mạch và minh bạch để cung cấp các lệnh và tính năng cần thiết nhằm tạo ra tài liệu của họ. Những mong muốn đó cũng có khả năng xuất hiện khi đối mặt với yêu cầu tạo PDF có gắn thẻ từ LaTeX: nó nên “chỉ chạy”, một cách minh bạch và với mức can thiệp tối thiểu từ tác giả. Thật không may, chúng ta vẫn còn cách khá xa trải nghiệm “Hey Presto! việc gắn thẻ cứ thế xảy ra bất kể tôi làm gì kỳ quặc”. Việc kết hợp các yêu cầu kỹ thuật của khả năng truy cập cùng PDF có gắn thẻ với LaTeX và tự do soạn thảo vốn dĩ đã rất phức tạp và, có lẽ, khó tránh khỏi việc cần một hình thức “kỷ luật tác giả” nào đó nếu muốn các thách thức kỹ thuật trở nên có thể triển khai và giải quyết trong thực tế. Một vấn đề riêng biệt nhưng có liên quan là việc gắn thẻ sai có thể không có tác động trực quan nào lên PDF cuối cùng: về mặt hình thức, nó có thể trông hoàn hảo và có lẽ cũng in ra không gặp vấn đề gì, nhưng tác giả không hề biết, việc gắn thẻ có thể đã “hỏng”, chỉ được phát hiện sau khi các kiểm tra tuân thủ/xác thực PDF/A thất bại và/hoặc qua các thử nghiệm thực tế thêm nữa bằng phần mềm hỗ trợ như trình đọc màn hình. ### Các tệp PDF được tạo trên Overleaf Overleaf cung cấp cho cộng đồng người dùng của mình một trình soạn thảo LaTeX dựa trên trình duyệt cùng với các công cụ quản lý dự án và tài liệu giúp việc soạn thảo cộng tác thuận tiện — tất cả đều được xây dựng trên một bản cài đặt TeX Live tiêu chuẩn. Về thực chất, Overleaf cho phép người dùng “chạy LaTeX từ xa” qua trình duyệt web, cung cấp một lớp che chắn trước những phức tạp của việc quản lý và bảo trì một hệ thống TeX Live đầy đủ. Một hệ quả của việc Overleaf dùng một cài đặt TeX/LaTeX tiêu chuẩn là các PDF được tạo từ mã LaTeX viết trong trình soạn thảo của Overleaf được tạo bằng đúng những công nghệ giống hệt như trong bất kỳ cài đặt TeX Live nào khác cùng phiên bản — bao gồm cả các thiết lập mà người dùng đã cài đặt trên thiết bị cục bộ của họ. Điểm khác duy nhất là các bộ máy TeX biên dịch và xử lý mã LaTeX của Overleaf chạy trên máy chủ từ xa, chứ không phải trên máy cục bộ. Overleaf có làm tuyến tính hóa PDF do TeX tạo ra để tải xuống/hiển thị hiệu quả trong trình duyệt, nhưng quá trình đó không liên quan đến khả năng truy cập của chính nội dung PDF. Việc tạo PDF có khả năng truy cập qua Overleaf phụ thuộc vào các khả năng và tính năng được tích hợp trong các bộ máy TeX tiêu chuẩn cùng với sự sẵn có của các gói macro LaTeX thích hợp mà người dùng có thể triển khai như một phần của tài liệu. Các tài liệu LaTeX được tạo bằng Overleaf phải vẫn tương thích với các cài đặt TeX và LaTeX khác vì người dùng thường cần xuất dự án LaTeX từ Overleaf để nộp cho nhiều hệ thống tạp chí/nhà xuất bản khác nhau. Việc đưa các tính năng đặc thù của Overleaf vào các tài liệu LaTeX của nó, hoặc vào các bộ máy TeX nền tảng, sẽ cản trở nghiêm trọng quyền tự do của người dùng trong việc sử dụng công trình của họ ở nơi khác. Overleaf nhận thức và hỗ trợ nhu cầu về các PDF có khả năng truy cập đầy đủ được tạo từ các hệ thống soạn thảo TeX/LaTeX: chúng tôi đầu tư thời gian nghiên cứu các vấn đề về khả năng truy cập, khám phá những phát triển mới nhất trong các bộ máy TeX và các gói LaTeX thử nghiệm hỗ trợ PDF có gắn thẻ. Cuối cùng, tại thời điểm viết bài này, vẫn chưa có giải pháp “cài là chạy” nào mà tác giả LaTeX có thể dùng (thông qua `\usepackage`) để tạo liền mạch và minh bạch các PDF có khả năng truy cập đầy đủ và tuân thủ PDF/UA từ các tài liệu LaTeX tổng quát. Khi các giải pháp đó có sẵn thông qua các bản cập nhật TeX Live, dĩ nhiên chúng sẽ trở thành sẵn có cho cộng đồng người dùng Overleaf. ### Một số gói LaTeX để khám phá việc gắn thẻ và khả năng truy cập Đối với nhiều người, [tex.stackexchage](https://tex.stackexchange.com/) là nơi đầu tiên tìm đến để được trợ giúp về TeX, LaTeX hoặc ConTeXt. Đây là một tài nguyên tuyệt vời và có rất nhiều câu hỏi về chủ đề [khả năng truy cập](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) và việc tạo PDF có khả năng truy cập thông qua LaTeX. Nếu bạn đọc và duyệt những câu hỏi này, cùng với dòng trả lời và bình luận tiếp theo, chỉ có một kết luận là không thể tránh khỏi: hiện tại không có giải pháp hoàn chỉnh, ở cấp độ sản xuất, để tự động tạo ra PDF có gắn thẻ, tuân thủ tiêu chuẩn và khả năng truy cập đầy đủ từ mọi loại tài liệu LaTeX. Tuy nhiên, có một số gói hỗ trợ gắn thẻ — dù, có lẽ, trong phạm vi sử dụng và loại tài liệu hạn chế. Danh sách sau đây được cung cấp cho độc giả muốn khám phá việc gắn thẻ PDF dựa trên LaTeX: * [`tagpdf` gói](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): gói có năng lực rất cao, được thiết kế để thử nghiệm gắn thẻ PDF. Hỗ trợ pdfTeX và LuaTeX, đồng thời cung cấp tài liệu cực kỳ hữu ích và thú vị, chứa nhiều ghi chú xuất sắc về các thách thức kỹ thuật của việc tạo PDF có gắn thẻ qua các bộ máy TeX; đây là tài liệu rất đáng đọc cho bất kỳ ai muốn hiểu rõ hơn các vấn đề liên quan. Hướng phát triển tương lai có khả năng là LuaTeX. * [`axessibility` gói](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov và Đại học Turin): cung cấp khả năng truy cập các công thức trong tệp PDF cho các công nghệ hỗ trợ. * [`khả năng truy cập` gói](https://ctan.org/pkg/accessibility) (Andy Clifton): tạo các tệp PDF có gắn thẻ và có cấu trúc. Ghi chú CTAN cho biết gói này “nhắm tới người dùng các lớp tài liệu KOMA-Script”. * [`accsupp` gói](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): gói thử nghiệm nhằm cung cấp hỗ trợ khả năng truy cập tốt hơn cho các tệp PDF. Một tài liệu tham khảo đáng chú ý khác là bài báo năm 2018 [Triển khai các tiêu chuẩn PDF cho xuất bản toán học](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) của Tiến sĩ Ross Moore thuộc Khoa Toán học, Đại học Macquarie. Trong bài đó, Tiến sĩ Moore đưa ra một phác thảo ngắn về các thách thức của việc gắn thẻ PDF trong LaTeX: > “Nguồn khó khăn chính nằm ở cách các môi trường khác nhau có thể tương tác với nhau. Có nhiều tình huống trong LaTeX mà một môi trường hoặc cấu trúc thực sự chưa hoàn tất cho đến khi môi trường tiếp theo bắt đầu. Vì vậy, không chỉ là vấn đề bao quanh mọi phần nội dung được cung cấp bằng các thẻ bắt đầu và kết thúc. Thay vào đó, người ta cần hiểu sự tinh tế về cách các môi trường khác nhau và các cấu trúc khác thực sự bắt đầu và kết thúc, trong bối cảnh được thiết lập bởi vật liệu xung quanh.” Tiến sĩ Moore cũng là người duy trì hiện tại của [`pdfx`](https://ctan.org/pkg/pdfx) gói và là một chuyên gia cũng như người tiên phong về PDF có gắn thẻ bằng TeX/LaTeX. Công trình của ông rất đáng để tìm hiểu — bao gồm cả video này trên YouTube, cung cấp những hiểu biết thú vị: {% embed url="" %} #### Lưu ý về gói pdfx Tính năng [`pdfx`](https://ctan.org/pkg/pdfx) gói (Ross Moore và cộng sự) cung cấp hỗ trợ tuyệt vời cho PDF/A-1|2|3b (lưu trữ), và các tùy chọn khác, nhưng vẫn chưa tạo ra PDF có gắn thẻ. --- # 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/vi/chu-de-khac/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.