> 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/id/topik-lainnya/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Pengantar file PDF bertag: bagian dalam dan tantangan aksesibilitas ## Pembaruan: Januari 2026 Silakan lihat [petunjuk Overleaf tentang membuat PDF bertag](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Fitur [tim LaTeX](https://latex-project.org/) telah merilis fitur-fitur baru yang memungkinkan penandaan PDF otomatis, persyaratan utama untuk aksesibilitas PDF. Fitur-fitur baru ini tersedia di Overleaf dalam [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), dengan pembaruan yang lebih baru tersedia dalam rilis TeX Live rolling yang tersedia melalui [Overleaf Labs](https://www.overleaf.com/labs/participate). Kini dimungkinkan untuk menghasilkan PDF bertag dari sumber LaTeX yang sesuai dengan WCAG 2.1 Level AA dengan mengikuti [dokumentasi pengguna kami](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) menggunakan rilis TeX Live yang tersedia di Overleaf. Artikel di bawah ini dari tahun 2020, meskipun tidak diperbarui dengan informasi terbaru tentang aksesibilitas LaTeX, masih dapat dibaca untuk menarik minat dan sebagai latar belakang tentang penandaan PDF. *** ## Apa yang dibahas artikel ini? Tujuan artikel ini adalah untuk memberikan pengantar tentang PDF bertag beserta gambaran umum tentang beberapa tantangan teknis yang dihadapi perangkat lunak, termasuk mesin TeX dan LaTeX, yang bertujuan menghasilkan file PDF bertag dan aksesibel. Aksesibilitas, khususnya pada PDF, adalah topik yang luas dan kompleks, yang juga memiliki tantangan teknis yang tidak selalu memiliki satu solusi yang disepakati atau diterima secara universal—seperti bagaimana merepresentasikan matematika kompleks di dalam PDF secara aksesibel: menggunakan MathML atau kode LaTeX? Meskipun kami tidak dapat membahas secara mendalam setiap topik, dan harus menyederhanakan banyak detail, kami dapat melihat isi PDF untuk menunjukkan apa sebenarnya yang terlibat dalam penandaan PDF. Overleaf berharap artikel ini akan menjadi pengantar yang berguna, memberikan latar belakang yang cukup untuk membantu pembaca lebih memahami tantangan teknis dan mendukung pembacaan serta penjelajahan lebih lanjut tentang PDF bertag dan aksesibilitas. Sumber daya dalam artikel ini meliputi: * [video berdurasi 8 menit](#video-showing-the-logical-structure-of-a-tagged-pdf) menjelajahi PDF bertag yang dihasilkan oleh LaTeX; * [proyek Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) untuk menjelajahi penggunaan karakter spasi di LuaTeX; * [rekaman suara](#tagged-yes-but-the-reading-order-is-incorrect) yang mendemonstrasikan masalah aksesibilitas PDF. ## Pendahuluan Memastikan aksesibilitas konten digital memang diakui sebagai aspek penting dalam produksi dan penyebaran konten. Selain itu, pemerintah, termasuk [Britania Raya](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) dan [Amerika Serikat](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), sedang mengesahkan undang-undang yang mewajibkan konten yang diproduksi di bawah yurisdiksi mereka untuk mematuhi kriteria aksesibilitas yang ditetapkan. Kepatuhan melalui penyebaran konten dalam HTML tidak terlalu memberatkan, tetapi memastikan tingkat aksesibilitas yang diperlukan untuk dokumen yang didistribusikan dalam format PDF dapat menjadi tantangan teknis yang signifikan—tergantung pada perangkat lunak yang digunakan untuk membuat konten yang akan dikeluarkan sebagai file PDF. PDF muncul pada awal 1990-an sebagai solusi untuk masalah seputar transfer dokumen yang andal dan sejarah telah menunjukkan bahwa format ini sangat berhasil. Namun, PDF juga merupakan format file yang kompleks yang muncul sebelum pengakuan dan penerimaan secara luas atas kebutuhan untuk memfasilitasi aksesibilitas konten dokumen. Meski demikian, seiring waktu spesifikasi PDF telah berkembang untuk menyediakan fitur yang memungkinkan dan mendukung pembuatan dokumen PDF aksesibel menggunakan varian PDF yang “bergaya” yang oleh Adobe disebut *PDF bertag*. Dalam praktiknya, pembuatan PDF bertag—*dan sepenuhnya aksesibel*—file PDF menempatkan persyaratan teknis tambahan yang signifikan pada perangkat lunak yang menghasilkan PDF—dan itu mencakup mesin TeX serta ekosistem makro dan paket tambahan LaTeX. ## Asal mula PDF sebagai kertas digital bentuk akhir Fitur [asal mula Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) berasal dari era ketika transfer dokumen antar komputer sarat dengan kesulitan, sering kali disebabkan oleh konversi file yang mengakibatkan aliran ulang halaman dan perbedaan lainnya yang diperparah oleh font dan pengodean teks yang tidak kompatibel yang digunakan pada sistem operasi yang berbeda (terutama Windows dan Macintosh). Penulis dokumen ini saat itu bekerja di bidang penerbitan dan memiliki kenangan yang sangat jelas tentang menghadapi tantangan-tantangan tersebut! PDF dirancang untuk mengatasi masalah berbagi file melalui pengenalan kertas digital universal berbentuk akhir (tidak dapat diedit), yang memungkinkan transfer dokumen mandiri secara mulus yang membawa font yang diperlukan untuk menampilkannya. Pengguna akhirnya dapat mentransfer berbagai macam dokumen dengan keyakinan yang wajar bahwa penerima, terlepas dari platform komputernya, dapat membuka dan membacanya—kesetiaan dokumen terjaga dan aliran ulang halaman yang berantakan serta masalah kompatibilitas/ketersediaan font menjadi masa lalu. ### Kertas digital: baik untuk semua pengguna? Silsilah PDF, sebagai bentuk kertas digital, secara alami mengasumsikan penggunaan nomor halaman cetak, tipografi, atau elemen desain sebagai petunjuk untuk navigasi visual kontennya—di layar atau di atas kertas. Namun, petunjuk/mekanisme visual tersebut tentu saja tidak bermakna bagi orang dengan gangguan penglihatan berat. Saat ini, peningkatan aksesibilitas konten digital memang diakui sebagai aspek penting dalam produksi dan penyebaran konten. Tantangan bagi PDF adalah menyediakan mekanisme yang memfasilitasi akses nonvisual ke konten yang terkunci dalam sebuah “wadah” yang awalnya dirancang untuk meniru media visual halaman cetak. Versi pertama spesifikasi PDF (PDF 1.0) adalah [dirilis secara resmi pada 15 Juni 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) diikuti oleh versi-versi baru dengan pembaruan yang pada tahun 2001 (PDF 1.4) mencakup pengenalan “PDF bertag” yang [“...memungkinkan pengguna teknologi bantu”](https://www.adobe.com/accessibility/pdf.html). Rilis-rilis berikutnya dari spesifikasi PDF telah memperluas dan meningkatkan fitur-fitur PDF, yang berpuncak pada rilis terbaru (PDF 2.0) yang, berdasarkan [laporan](https://www.pdfa.org/tagged-pdf-2-0/), telah secara signifikan memperbarui fitur aksesibilitas—meskipun PDF 2.0 belum didukung dengan baik oleh mesin TeX. ## Konten di dalam PDF Untuk memahami isu-isu yang terlibat, ada baiknya menelaah bagaimana file PDF sebenarnya merepresentasikan konten halaman yang dikandungnya. Di dalam file PDF, konten untuk setiap halaman berada dalam *aliran konten*: urutan operator PDF (“perintah”) yang menempatkan teks atau grafis pada lokasi halaman tertentu untuk dirender (ditampilkan) oleh perangkat lunak yang digunakan untuk *melihat* PDF tersebut. Pada dasarnya, aliran konten menyediakan deskripsi grafis atau “resep” yang memberi tahu aplikasi pembaca PDF bagaimana “menggambar” setiap halaman—menentukan apa yang harus ditampilkan di halaman, dan di mana. Tentu saja, rangkaian operator itu mencakup instruksi untuk memilih font tertentu pada ukuran spesifik, memilih warna, menentukan lebar garis, menggambar garis, kurva, dan sebagainya—semua yang diperlukan untuk memberikan deskripsi grafis lengkap untuk penyajian visual sebuah halaman. Untuk mengurangi ukuran file, aliran konten PDF dikompresi dan disimpan dalam format biner yang ringkas, tetapi jika Anda memiliki akses ke perangkat lunak yang sesuai, seperti Adobe Acrobat Pro DC, Anda dapat menggunakannya untuk melihat versi teks biasa yang “didekompresi” dari aliran konten halaman. Mari pertimbangkan bagaimana operator PDF mungkin “menggambar” sebuah tabel: aliran konten PDF akan berisi urutan operator yang sesuai untuk menghasilkan garis horizontal/vertikal, memilih font yang berbeda, dan mengeluarkan teks yang ditempatkan di berbagai lokasi halaman untuk menghasilkan isi tabel. Untuk mendemonstrasikan ini, mari pertimbangkan sebuah dokumen PDF tidak bertag yang sangat sederhana yang tidak berisi apa pun selain tabel dasar dengan beberapa teks—dibuat di Microsoft Word karena alasan yang akan menjadi jelas nanti dalam artikel ini. Berikut cuplikan layar yang menampilkan PDF sederhana kami: ![Sebuah tabel yang dibuat di Microsoft Word](/files/da717053ae877ad01cb6c01434137d3ea4583346) Jika kita mengekstrak aliran konten halaman (yang telah didekompresi) untuk file ini dan menempelkan beberapa baris pertama ke editor teks, kita dapat meringkas beberapa operator PDF untuk mendapatkan “gambaran” tentang bagaimana file PDF “menjelaskan” konten yang ditampilkan di halaman ini. ![Gambar aliran konten dalam file PDF](/files/4e62efee82f20a46118824ca3283a0a3fb3258e7) Jika Anda memiliki akses ke Adobe Acrobat Pro DC, Anda dapat menggunakannya untuk menampilkan daftar operator yang terdapat dalam aliran konten halaman PDF. Berikut *Struktur internal PDF* tampilan Acrobat atas PDF yang sama yang dengan membantu memberikan deskripsi satu baris untuk setiap operator yang digunakan untuk “menggambar” satu halaman kami yang berisi tabel dasar—perhatikan bahwa deskripsi singkat ini disediakan oleh Adobe Acrobat Pro DC, dan *berisi nilai data aktual yang disimpan dalam* tidak terdapat dalam file PDF itu sendiri: ![Gambar aliran konten PDF yang dilihat di Adobe Acrobat Pro DC](/files/183687b4a30539c2b8b889d9344ca2a2e9cc7a43) Namun, perhatikan bahwa tidak satu pun dari instruksi menggambar (operator) tersebut menyimpan “makna” atau “deskripsi” dari apa yang sebenarnya mereka hasilkan: mereka hanyalah seperangkat operator grafis yang menghasilkan konstruksi sesuatu yang oleh seorang *pengamat awas dikenali* sebagai tabel. Jelas, bagi mereka dengan gangguan penglihatan berat, menampilkan tabel yang dihasilkan dari operator grafis tersebut dalam aliran konten PDF bukanlah metode yang layak untuk mengakses konten itu. Yang diperlukan adalah mekanisme agar file PDF memuat deskripsi nonvisual (dapat dibaca mesin) yang sesuai tentang tabel tersebut—dan, tentu saja, semua item konten lain yang terdapat di dalam halaman-halaman dalam file PDF. Untuk memungkinkan akses nonvisual ke konten, file PDF perlu memuat data tambahan yang menempelkan “makna” atau semantik pada kumpulan atau kelompok operator yang digunakan untuk “menggambar” suatu bagian konten tertentu. Tentunya, prinsip pemberian atau penyediaan “makna” ini harus berlaku untuk semua bentuk konten yang ada dalam PDF: mekanisme itu ada dan disebut *penandaan* PDF untuk menghasilkan “varian” PDF yang, tidak mengejutkan, disebut *PDF bertag*. ## Memperkenalkan PDF bertag PDF bertag adalah nama yang diberikan untuk jenis file PDF tertentu yang memuat data tambahan (dan struktur data) yang tidak terdapat dalam file PDF tidak bertag. Meskipun prinsip/gagasan di balik PDF bertag cukup dapat dijelaskan secara garis besar, rincian lengkapnya kompleks dan menempati banyak halaman dalam spesifikasi resmi PDF. Adobe merancang PDF bertag untuk mencapai sejumlah tujuan yang mencakup membuat konten dapat diakses oleh pengguna dengan gangguan penglihatan, tetapi juga mencakup daftar berikut yang diambil dari Bagian 10.7 dari [spesifikasi PDF 1.7 Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * ekstraksi teks dan grafis secara sederhana untuk ditempelkan ke aplikasi lain; * aliran ulang otomatis teks dan grafis terkait agar pas dengan halaman berukuran berbeda dari yang diasumsikan untuk tata letak asli; * memproses teks untuk tujuan seperti pencarian, pengindeksan, dan pemeriksaan ejaan; * konversi ke format file umum lainnya (seperti HTML, XML, dan RTF) dengan struktur dokumen dan informasi gaya dasar tetap terjaga. Selain itu, PDF bertag juga mengharuskan: * teks di dalam konten PDF direpresentasikan dalam bentuk yang dapat dikonversi ke Unicode; * pemisahan kata harus direpresentasikan secara eksplisit—perhatikan bahwa mesin TeX tidak menggunakan karakter spasi untuk memisahkan kata, melainkan menggunakan spasi fleksibel TeX yang disebut glue (lihat di bawah); * konten nyata (“sebenarnya”) dibedakan dari artefak tata letak dan penomoran halaman. Yang mendasari PDF bertag adalah dua konsep utama yang akan kita tinjau: * mendefinisikan struktur logis konten dalam file PDF; * markup (penandaan) konten PDF dengan seperangkat jenis konten standar. ## Struktur logis Dalam dokumen yang lebih panjang, konten biasanya dibagi menjadi urutan item konten yang lebih kecil; misalnya, buku biasanya dipecah menjadi bab-bab yang kemudian dibagi lagi menjadi bagian dan subbagian yang berisi paragraf, tabel, gambar/grafik, daftar berpoin atau bernomor, catatan kaki dan referensi, dan sebagainya. Struktur dan organisasi konten dalam buku seperti itu, atau jenis dokumen lainnya, disebut sebagai *struktur logis*. Gagasan tentang struktur logis dokumen memainkan peran penting dalam aksesibilitas PDF, tetapi sebagai konsep, struktur logis bisa terasa agak samar dan sulit dipahami. Definisi berikut dari [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) memberikan wawasan yang membantu: > “Struktur logis merujuk pada cara informasi dalam sebuah dokumen diorganisasi; ia mendefinisikan hierarki informasi dan hubungan antara bagian-bagian yang berbeda dari dokumen. Struktur logis menunjukkan bagaimana sebuah dokumen disusun, bukan apa yang dikandungnya.” Perhatikan bahwa definisi struktur logis ini tidak merujuk secara tepat pada *bagaimana* bahwa informasi struktural itu disimpan secara fisik; hanya bahwa ia menyediakan representasi dari struktur dan organisasi dokumen. Rincian tepat tentang bagaimana struktur logis sebuah dokumen disimpan atau direpresentasikan bergantung pada implementasi: fungsi dari perangkat lunak yang digunakan untuk menghasilkan dan memprosesnya. ### Struktur logis dalam PDF Spesifikasi PDF menyediakan mekanisme yang memungkinkan struktur logis suatu dokumen dicatat di dalam file PDF—untuk digunakan oleh perangkat lunak yang, misalnya, mungkin ingin mengekspor konten PDF ke format lain seperti XML, HTML, atau Microsoft Word. Proses ekspor tersebut perlu menghasilkan dokumen teks yang terstruktur dengan benar dan sesuai dengan aturan format file tujuan—yang paling baik dicapai ketika pemrosesan ekspor dipandu oleh informasi struktur logis yang disediakan di dalam PDF. Selain itu, struktur logis sebuah file PDF penting bagi perangkat lunak aksesibilitas yang, misalnya, mungkin ingin melakukan operasi text-to-speech, membacakan konten dengan suara keras kepada seseorang dengan gangguan penglihatan. Proses text-to-speech perlu memastikan konten dibacakan dalam urutan/sekuens yang benar, jika tidak hasilnya akan tidak masuk akal. Perhatikan juga bahwa konsep halaman itu sendiri mungkin tidak bermakna bagi aplikasi aksesibilitas yang hanya tertarik pada konten PDF dan struktur dokumen, bukan pemisahan visual dan penyajian ke dalam potongan seukuran halaman. #### Penamaan item konten Pencatatan (penyimpanan) struktur logis sebuah dokumen PDF memerlukan sejumlah nama bermakna yang diberikan kepada berbagai *jenis* item konten yang kemungkinan ditemukan sebagai bagian dari dokumen PDF biasa—mengidentifikasi bagian konten yang mewakili judul, paragraf, tabel, daftar, dan sebagainya. Selain itu, beberapa item konten seperti daftar isi, daftar bernomor/berpoin, dan materi tabular memiliki struktur yang cukup kompleks sehingga juga diperlukan beberapa panduan/aturan untuk menentukan bagaimana item konten yang lebih kompleks itu disusun—substrukturnya. Persyaratan lain adalah mengidentifikasi dengan jelas setiap konten PDF yang harus diabaikan oleh perangkat lunak bantu yang memproses PDF; misalnya, header dan footer halaman adalah artefak penomoran halaman yang berisi teks yang tidak perlu bagi mereka yang memiliki gangguan penglihatan berat: konten tersebut harus diabaikan. Mekanisme yang digunakan PDF untuk mendefinisikan struktur logis dokumen dirancang agar fleksibel, sehingga, pada prinsipnya, aplikasi berbeda yang menghasilkan dan memproses file PDF dapat menggunakan nama untuk jenis konten dengan konvensi apa pun yang mereka pilih. Namun, untuk memaksimalkan pertukaran dokumen dan memungkinkan aplikasi pemrosesan PDF yang berbeda memberikan hasil yang konsisten, Adobe mendefinisikan seperangkat nama standar untuk jenis item konten yang harus diikuti oleh perangkat lunak pembuat PDF. Dalam spesifikasi PDF, nama-nama standar tersebut disebut sebagai tag, sehingga melahirkan gagasan tentang *bertag* PDF. ### Markup konten PDF: Sekilas “di balik kap mesin” Agar pembahasan sedikit kurang abstrak, kita akan melihat sekilas bagian dalam file PDF bertag—meskipun kami tidak bisa membahas semua detailnya karena PDF bertag adalah topik yang sangat luas dan kompleks. #### Urutan konten bertanda: blok penyusun PDF bertag Pada tingkat paling dasar, proses pencatatan makna konten yang terdapat dalam sebuah halaman PDF (yaitu, di dalam aliran kontennya) dimulai dengan *urutan konten bertanda* yang digunakan untuk mengidentifikasi (memberi “makna” pada) kelompok atau grup operator PDF. Urutan konten bertanda diberi sebuah pengenal numerik yang disebut `MCID` (*pengenal konten bertanda*) yang merupakan bilangan bulat yang berjalan dari 0 hingga suatu maksimum N pada setiap halaman. Nilai-nilai `MCID` tersebut menyediakan cara untuk mengidentifikasi secara unik urutan operator yang terdapat dalam aliran konten halaman tertentu. Untuk memperjelas, untuk setiap halaman `MCID` pengenal dimulai dari 0 dan meningkat secara berurutan hingga suatu nilai maksimum yang bergantung pada berapa banyak urutan konten bertanda yang terkandung dalam aliran konten halaman tertentu. Urutan konten bertanda pada dasarnya adalah “blok penyusun” fundamental yang digunakan untuk merakit struktur data tingkat lebih tinggi yang disebut *elemen struktur*. Elemen struktur tersebut memuat sebuah tag, yaitu nama yang digunakan untuk mengidentifikasi jenis item konten yang mereka wakili. #### Contoh elemen struktur Di sini kita sedikit melompat ke depan, tetapi ada baiknya meninjau sebuah contoh. Misalkan Anda memiliki 3 potongan teks kecil dari konten halaman dan masing-masing diidentifikasi dalam aliran konten oleh urutan konten bertanda yang berbeda. Masing-masing dari 3 potongan teks tersebut dapat dikemas ke dalam elemen strukturnya sendiri, dengan sebuah tag, dan ketiganya dapat “dihubungkan bersama” menggunakan elemen struktur lain untuk mewakili item konten tingkat lebih tinggi seperti satu baris dalam daftar isi. ![Gambar yang menjelaskan elemen struktur dan urutan konten bertanda](/files/1e8bdbaccc4461572262219fef30602fd87ec478) Melalui bentuk hubungan data induk–anak, kumpulan elemen struktur digabungkan untuk menciptakan struktur data tertaut yang merepresentasikan item data yang lebih kompleks seperti daftar bernomor dan berpoin, tabel, matematika, dan sebagainya. Pada akhirnya, seluruh kumpulan elemen struktur yang terdapat dalam keseluruhan file PDF dihubungkan lebih lanjut dan digabungkan untuk menciptakan struktur logis dokumen PDF—kita akan meninjaunya lagi nanti dalam artikel ini. ### Apa itu urutan konten bertanda? Dalam pembahasan di atas, kita menggunakan dokumen PDF tidak bertag sederhana yang berisi sebuah tabel (dibuat di Microsoft Word), tetapi jika kita meminta Word membuat PDF bertag, kita dapat melihat bahwa beberapa markup tambahan telah muncul dalam aliran konten halaman. Di sini, kita hanya mempertimbangkan beberapa baris pertama dari aliran konten (ada ratusan baris) tetapi perhatikan adanya operator tambahan seperti `/P <> BDC` dan `EMC` yang digunakan untuk mengidentifikasi urutan konten bertanda. Kami tidak akan membahas sintaks lengkap urutan konten bertanda, tetapi merujuk pembaca ke halaman 862 dari [spesifikasi resmi PDF 1.7 Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Gambar yang menunjukkan urutan konten bertanda dalam aliran konten PDF bertag](/files/6a78bfef398df861622540003cf06540045462c9) Untuk memudahkan referensi, kami kembali menampilkan versi tidak bertag: ![Gambar yang menunjukkan aliran konten PDF](/files/4e62efee82f20a46118824ca3283a0a3fb3258e7) Pada *tidak bertag* PDF, operator seperti `/P <> BDC` dan `EMC` tidak ada, tetapi operator lainnya tetap tidak berubah: PDF tidak bertag tidak memiliki markup tambahan yang digunakan untuk mengidentifikasi urutan/kumpulan operator tertentu. Sekali lagi kita juga dapat menggunakan fitur Adobe Acrobat untuk *Struktur internal PDF* melihat urutan konten bertanda dalam aliran konten—di sini, kami menyorotnya dengan bingkai hijau: ![Gambar yang menunjukkan urutan konten bertanda dalam aliran konten PDF bertag yang dilihat di Adobe Acrobat Pro DC](/files/a96890615bb43729dcbdb69688c55275d8ff8803) Perhatikan bahwa beberapa bagian konten ditandai dengan `/Artifact` yang mengidentifikasi materi pada halaman PDF yang seharusnya *diabaikan* oleh aplikasi perangkat lunak bantu, seperti yang membacakan teks dengan suara keras kepada orang dengan gangguan penglihatan. Cuplikan layar berikut menunjukkan tampilan yang diperluas dari urutan konten bertanda pertama—yang memiliki `MCID` nilai `0`. Akhir dari urutan konten bertanda diidentifikasi oleh operator PDF `EMC`. ![Gambar yang menunjukkan detail operator yang tercakup oleh aliran konten bertanda](/files/c6635d0e436acd1df27c6cf84f9367ae19085863) ### Menyimpan struktur logis Seperti telah disebutkan, selain memberikan deskripsi item konten individual (paragraf, daftar, tabel, dll.) dokumen PDF aksesibel perlu memuat representasi seluruh dokumen dalam bentuk struktur logisnya. Potongan-potongan konten aksesibel harus dihubungkan bersama untuk menciptakan dokumen yang lengkap, dapat dinavigasi, dan aksesibel—mirip dengan bagaimana satu dokumen HTML dibangun dari paragraf, grafis, tabel untuk membuat sebuah halaman web. Selain itu, sangat penting bahwa struktur logis sebuah dokumen PDF memastikan semua konten dapat dinavigasi dalam *urutan baca*, terlepas dari urutan konten halaman ditulis ke aliran konten halaman PDF. Kita akan membahas urutan baca lebih rinci di bawah. #### Struktur logis: “pohon” elemen struktur Kita telah mencatat bahwa PDF menggunakan sesuatu yang disebut *elemen struktur* untuk merepresentasikan item konten individual, dan bahwa elemen struktur memuat tag untuk mengidentifikasi jenis konten yang diwakilinya. Untuk menyediakan representasi struktur logis dokumen, semua elemen struktur dihubungkan bersama, menggunakan hubungan induk—anak, dan diorganisasi ke dalam “pohon struktur”. Secara internal, file PDF bertag memuat objek yang disebut `StructTreeRoot` yang berisi (menunjuk ke) elemen struktur yang bertindak sebagai titik awal atau “akar” dari pohon struktur logis dokumen. Biasanya, “akar” pohon struktur dimulai dengan satu elemen struktur yang diberi tag `Document` yang memuat banyak *anak* elemen struktur yang secara kolektif merepresentasikan seluruh konten dokumen. Setiap perangkat lunak yang dirancang untuk menghasilkan PDF aksesibel melalui penandaan harus membangun struktur data yang sangat kompleks ini (dan lainnya!)—dan itu mencakup mesin TeX dan LaTeX. Contoh pohon struktur dokumen seperti itu (`StructTreeRoot`) ditampilkan dalam cuplikan layar berikut dari PDF bertag yang dibuka di Adobe Acrobat Pro DC: ![Gambar yang menunjukkan StructTreeRoot dalam PDF bertag](/files/bce61a89a078c23f0179d0d21c6d2986835a57a6) Bandingkan struktur di atas dengan versi PDF tidak bertag: ![Gambar yang menunjukkan ketiadaan StructTreeRoot dalam PDF tidak bertag](/files/6b1c604ea2804eebb3de009824c71a44b9282307) ### Menjelajahi struktur logis PDF Kita mulai dengan beberapa grafik untuk merangkum apa yang telah kita bahas dan diakhiri dengan video yang menggunakan Adobe Acrobat Pro DC untuk menunjukkan detail lebih lanjut tentang struktur logis file PDF bertag. Pertama, kita mulai dengan skema yang menunjukkan prinsip umum: sebuah halaman PDF dengan aliran kontennya diberi markup menggunakan urutan konten bertanda (MCS). ![Grafik yang menunjukkan konsep urutan konten bertanda dalam halaman dokumen PDF](/files/b38e66da6a0b544da2236750f8665c35e0743bec) MCS tersebut kemudian digabungkan menjadi *elemen struktur* yang menjadi dasar bagi jenis konten yang lebih besar yang kemudian dihubungkan lebih lanjut untuk menyimpan struktur logis PDF di dalam sebuah objek yang disebut `StructTreeRoot`. ![Grafik yang menunjukkan struktur logis file PDF bertag](/files/57849684845ab748c6de7a29db79e158d0653cd1) #### Video yang menunjukkan struktur logis PDF bertag Video berikut (8 menit) menggunakan Adobe Acrobat Pro DC untuk membawa Anda dalam “tur berpemandu” guna menjelajahi detail struktur logis file PDF bertag yang dihasilkan menggunakan LaTeX. File PDF bertag yang digunakan dalam video disebut `tagpdf.pdf`, yang merupakan contoh yang sangat baik dan berisi dokumentasi untuk paket LaTeX eksperimental [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). Tujuan dari `tagpdf` paket ini adalah menyediakan “alat untuk bereksperimen dengan penandaan dan aksesibilitas menggunakan pdfLaTeX dan LuaTeX”. {% embed url="" %} ### Catatan tentang penandaan dan fleksibilitas Spesifikasi HTML menyediakan sejumlah besar tag yang telah ditentukan sebelumnya untuk digunakan dalam menyusun halaman web, tetapi juga memungkinkan fleksibilitas dalam cara Anda menggabungkannya untuk membuat dokumen HTML pilihan Anda. Demikian pula, spesifikasi PDF bertag Adobe menyediakan seperangkat nama tag yang telah ditentukan sebelumnya tetapi hanya memberlakukan sangat sedikit batasan pada cara Anda menggabungkan tag-tag tersebut untuk merepresentasikan item konten kompleks di dalam PDF—secara desain, ada banyak fleksibilitas. Selain itu, pada spesifikasi sebesar dan sekompleks PDF, tak terhindarkan jika beberapa ambiguitas, atau isu kejelasan, masuk ke dalam spesifikasi tertulis. Pengembang perangkat lunak yang ditugaskan mengimplementasikan spesifikasi yang kompleks seperti itu mungkin harus membuat “penilaian” saat menafsirkannya karena mereka harus mengubah deskripsi tertulis menjadi kode yang berfungsi. Fleksibilitas bawaan PDF bertag bersama dengan penafsiran spesifikasi (atau standar aksesibilitas) secara alami berdampak pada pengembang aplikasi pembuat dokumen: kombinasi tag apa yang harus digunakan untuk merepresentasikan konten buatan pengguna saat mengeluarkannya ke file PDF bertag? Jika Anda mempertimbangkan kemampuan pengguna yang tak terbatas untuk menyusun berbagai jenis konten dengan memanfaatkan fitur-fitur perangkat lunak pembuat dokumen, maka Anda bisa melihat bahwa produksi otomatis PDF bertag yang aksesibel memang cukup menantang! Mungkin mencerminkan kompleksitas yang tak terhindarkan dalam menghasilkan PDF bertag yang sepenuhnya sesuai dengan standar aksesibilitas, web dipenuhi dengan saran “cara”, “tips”, dan “praktik terbaik” tentang membuat PDF bertag melalui perangkat lunak seperti Adobe InDesign atau Microsoft Word. Selain itu, PDF Association telah menghasilkan dokumen yang berguna berjudul [Panduan Praktik Terbaik PDF Bertag](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) yang ditulis untuk membantu pengembang menghadapi tantangan dalam mengimplementasikan PDF bertag dan PDF/UA. ## Punya PDF, tapi apakah aksesibel? Untuk menentukan apakah file PDF tertentu memenuhi standar aksesibilitas yang disyaratkan seperti PDF/A atau PDF/UA (lihat di bawah), file tersebut harus *divalidasi* menggunakan proses validasi atau alat perangkat lunak yang disepakati. Namun, validasi biasanya dilakukan setelah dokumen selesai, tetapi proses itu mungkin tidak dilakukan oleh penulis dokumen melainkan oleh spesialis aksesibilitas dalam organisasi atau badan yang meminta kepatuhan. Jika PDF gagal validasi, mungkin diperlukan intervensi manual yang terampil melalui Adobe Acrobat Pro DC untuk memperbaiki penandaan (jika memungkinkan). Sebagai alternatif, dokumen itu bahkan mungkin harus dikembalikan kepada penulis untuk merevisi dokumen aslinya, mungkin dengan menghindari penggunaan fitur perangkat lunak pembuat yang menyebabkan masalah—yang bisa sangat sulit dilakukan karena mungkin berada di luar kendali penulis. ### Urutan baca dan urutan konten Seperti disebutkan, produksi PDF yang benar-benar aksesibel menempatkan persyaratan teknis tambahan pada perangkat lunak pembuat dan, berpotensi, pada penulis dokumen juga dengan menegakkan “disiplin penulisan” dalam cara mereka menggunakan/menerapkan fitur-fitur perangkat lunak pembuat. Meskipun PDF bertag adalah mekanisme yang *memungkinkan* produksi PDF yang sepenuhnya aksesibel, hanya karena sebuah PDF bertag tidak *berisi nilai data aktual yang disimpan dalam* otomatis berarti PDF tersebut sepenuhnya aksesibel, seperti akan kita lihat pada contoh di bawah. Untuk menghasilkan PDF yang sepenuhnya aksesibel, semua item konten dalam PDF harus diberi tag untuk membuat struktur logis yang memastikan konten dapat diakses dan dibaca dalam urutan yang benar—disebut *urutan baca*. Ini mungkin tampak “jelas” tetapi ketika perangkat lunak menulis file PDF, ia dapat mengeluarkan grafis dan teks ke aliran konten halaman dalam urutan apa pun yang dipilihnya. Misalnya, anggap sebuah halaman dimulai dengan beberapa teks, diikuti tabel dan diakhiri dengan grafis, memberikan *urutan baca* dari: 1. teks 2. table 3. grafis Saat ditulis ke PDF, perangkat lunak yang menghasilkan aliran konten untuk halaman itu bisa memulai dengan operator untuk menggambar tabel, lalu mengeluarkan operator untuk menghasilkan grafis diikuti operator untuk teks, yang dalam aliran konten akan menghasilkan sebuah *urutan konten* dari: 1. table 2. grafis 3. teks Tentu saja, semuanya akan ditempatkan pada posisi yang benar saat halaman itu dilihat. Bagi pembaca yang sepenuhnya awas, urutan penyimpanan item-item tersebut di dalam aliran konten halaman tidak menarik perhatian: mereka melihat halaman yang dirender secara lengkap dengan semuanya di lokasi yang benar. Namun, jika perangkat lunak bantu harus bergantung pada pengurutan item dalam aliran konten (urutan konten), ia akan menghadapi kesulitan jika urutan konten berbeda dengan urutan baca alami; misalnya, alat pembaca keras akan membacakan materi dalam urutan yang salah. Untungnya, perangkat lunak bantu dapat menggunakan urutan logis (struktur) PDF bertag yang harus diorganisasi untuk mencerminkan urutan konten yang semestinya dibaca. Karena alasan-alasan inilah data yang merepresentasikan struktur logis dokumen disimpan terpisah dari konten aktual yang ditampilkan pada halaman-halaman yang terlihat, agar memungkinkan > “... pengurutan dan penyarangan elemen konten logis sepenuhnya independen dari urutan dan lokasi objek grafis pada halaman-halaman dokumen.” (halaman 856 dari [The PDF Reference, edisi keenam, November 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) Dalam praktiknya, memastikan urutan logis yang mempertahankan urutan baca jauh lebih menantang daripada yang tampak, jadi mari kita gunakan contoh sederhana, meskipun dibuat-buat, yang memberikan gambaran tentang isu-isu yang terlibat. #### Urutan baca yang salah: Contoh menggunakan Microsoft Word Penulis dokumen mungkin menggunakan fitur perangkat lunak pembuat yang dipilihnya untuk mencapai efek visual tertentu—misalnya menggunakan tabel untuk membuat tata letak teks tertentu. Sebagai contoh, cuplikan layar berikut menunjukkan dokumen Microsoft Word yang digunakan dalam contoh sebelumnya. Dokumen itu berisi tabel yang telah digunakan untuk membuat serangkaian paragraf bernomor berdampingan. Namun, saat menandai konten ini, bagaimana seharusnya diperlakukan: ditandai sebagai tabel atau daftar bernomor? Kedua jenis konten tersebut memerlukan struktur penandaan yang kompleks agar dapat merepresentasikannya dengan benar. Pada gambar berikut, perhatikan urutan pembacaan paragraf bernomor: kolom demi kolom, bukan baris demi baris. ![Gambar tabel yang dibuat di Microsoft Word](/files/85a947203d7359467f573f58c8788db221475a83) Jika kita meminta Word menyimpan dokumen ini ke PDF menggunakan ekspor bawaan—bukan plugin Acrobat PDFMaker—kita dapat memintanya membuat PDF bertag: ![Kotak dialog Opsi dari proses ekspor Microsoft Word](/files/13c90c4c60ea935fa668f600dbd3ad6b1a2a721e) Jadi, bagaimana Word menandai tata letak ini? Dalam video yang sangat singkat berikut (14 detik) kita menggunakan Adobe Acrobat Pro DC untuk memeriksa struktur penandaan yang dihasilkan oleh Microsoft Word. {% embed url="" %} Untuk dokumen ini, Word telah membuat dokumen PDF bertag yang menggunakan sebuah `Tabel` tag yang berisi dua subtag: `THead` untuk grup baris header tabel dan dan `TBody` untuk merepresentasikan kelompok baris untuk badan tabel. `THead` dan `TBody` keduanya berisi `TR` tag untuk merepresentasikan baris-baris konten individual. Tag `TR` berisi tag tambahan untuk merepresentasikan item daftar bernomor yang ada di setiap sel. Gambar layar berikut menunjukkan struktur penandaan yang tersarang sangat dalam dan struktur logis yang sesuai, yang diperlukan untuk merepresentasikan bahkan dokumen yang sangat mendasar ini! ![Gambar yang menunjukkan struktur penandaan yang tersarang sangat dalam dan struktur logis dari tabel sederhana yang dibuat di Microsoft Word](/files/27a7218d597437bb06b6d98ec716039753292e9b) Dibandingkan dengan PDF yang dihasilkan oleh TeX dan LaTeX, contoh Word ini adalah dokumen yang sangat sederhana, tetapi tetap memerlukan struktur logis yang kompleks untuk merepresentasikannya. Bayangkan tingkat kompleksitas penandaan yang diperlukan untuk merepresentasikan PDF yang dihasilkan LaTeX yang berisi matematika dan tabel yang kompleks! #### Bertag, ya, tetapi urutan bacaannya salah Meskipun Word memang menghasilkan sebuah [PDF bertag](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) ini menunjukkan salah satu tantangan mendasar yang dihadapi oleh aplikasi apa pun yang berusaha menghasilkan PDF yang sepenuhnya aksesibel: merepresentasikan urutan baca yang dimaksudkan dengan benar dari konten. Selama pembuatan PDF bertag, proses internal Word memutuskan untuk menulis aliran konten yang sesuai dengan mengeluarkan tabel secara baris demi baris, bukan kolom demi kolom. Bagi pembaca yang dapat melihat sepenuhnya saat melihat PDF, detail tingkat rendah ini tidak membuat perbedaan: tabel ditampilkan dengan benar. Namun, bagi orang dengan gangguan penglihatan, struktur dokumen logis Word menghasilkan hasil yang salah karena urutan baca yang diinginkan (kolom demi kolom) tidak dipertahankan: konten dibacakan dengan urutan yang salah. Rekaman audio berikut dibuat menggunakan fitur “Read Out Loud” Adobe Reader DC. Seperti terlihat jelas, teks dibacakan dalam urutan yang salah: baris demi baris, bukan kolom demi kolom: ![Sebuah tabel yang dibuat di Microsoft Word](/files/e06faed599f01b1d5f719810ba1c1ff19b642073) Seperti disebutkan di atas, contoh ini agak dibuat-buat tetapi memang menunjukkan betapa mudahnya menerapkan kombinasi fitur perangkat lunak yang memicu masalah aksesibilitas—tetapi bagaimana penulis dokumen diharapkan mengetahuinya sebelumnya? Kemungkinan besar masalah ini hanya akan terdeteksi jika PDF yang dihasilkan menjalani pengujian penggunaan aksesibilitas praktis—misalnya, dengan menggunakan perangkat lunak bantu. Berpotensi, dokumen semacam itu dapat lolos uji kepatuhan/validasi PDF/A tetapi gagal dalam penggunaan “dunia nyata”. Memastikan urutan baca yang benar dari file PDF seperti ini akan memerlukan intervensi manual yang terampil menggunakan alat pengedit PDF lanjutan seperti Adobe Acrobat Pro DC: sebuah proses yang memakan waktu dan mahal. Sebagai alternatif, penulis dokumen dapat menahan diri untuk tidak menggunakan bentuk ekspresi konten atau tata letak tertentu ini—tetapi hanya jika mereka tahu bahwa hal itu bermasalah! ### Menggunakan karakter spasi untuk memisahkan kata Saat Anda mengetik teks ke dalam pengolah kata atau editor teks, Anda menggunakan karakter spasi untuk menandai akhir satu kata dan awal kata berikutnya. Jika kemudian Anda membuat PDF dari dokumen semacam itu, karakter spasi yang Anda ketik tentu akan dikeluarkan dan menjadi bagian dari teks yang disimpan dalam PDF. Namun, mesin TeX tidak menggunakan karakter spasi untuk memisahkan kata dalam teks yang ditata huruf; sebaliknya, mereka mengubah karakter spasi menjadi bentuk spasi fleksibel yang disebut glue (lihat ini [artikel Overleaf](/latex/id/artikel-mendalam/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) untuk informasi lebih lanjut tentang kotak TeX dan glue). Dalam aliran konten halaman PDF yang dibuat oleh mesin TeX, pemisahan kata-kata individual dicapai dengan berpindah ke posisi berbeda pada halaman dan memulai teks untuk kata berikutnya—bukan dengan mengeluarkan karakter spasi untuk mencapai jarak tersebut. Selain itu, jumlah spasi antar kata dalam paragraf teks yang ditata oleh mesin TeX bervariasi dari baris ke baris karena algoritma pemenggalan baris TeX. Variasi itu tercermin dalam data posisi yang ditulis ke aliran konten halaman PDF. Aspek penataan huruf TeX ini berdampak pada menyalin/menempel teks dari PDF-nya dan pada perangkat lunak bantu yang mencoba membacakan teks yang ditata dalam PDF yang dihasilkan oleh mesin TeX. Perangkat lunak bantu harus mengurai aliran konten halaman PDF untuk mengekstrak teks yang perlu diproses. Jelas, perangkat lunak semacam itu membutuhkan mekanisme untuk mendeteksi awal dan akhir kata—solusi yang paling jelas adalah menggunakan karakter spasi. Dengan mempertimbangkan hal itu, standar aksesibilitas mengharuskan kata-kata individual diakhiri dengan jelas (mis., dengan karakter spasi) yang menjadi masalah bagi mesin TeX karena penggunaan glue antar kata. #### Tetapi belum semuanya hilang! Pada 2014 pdfTeX memperkenalkan 2 primitif baru untuk meningkatkan dukungan aksesibilitas dengan memungkinkan penggunaan karakter spasi di antara kata-kata dalam PDF yang dihasilkannya: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Perintah ini memanfaatkan “font dummy” yang hanya berisi glif spasi. Rincian dan contoh dapat ditemukan pada halaman 29 dari [Panduan Pengguna pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Menggunakan LuaTeX: Sebuah contoh di Galeri Overleaf LuaTeX tidak mendukung primitif pdfTeX tersebut, tetapi dapat diprogram untuk menghasilkan hasil yang sangat mirip dengan pdfTeX menggunakan mekanisme yang disebut callback pada LuaTeX. Sebuah proyek Overleaf untuk mengubah glue menjadi karakter spasi tersedia di Galeri Overleaf dengan judul [Menggunakan LuaTeX untuk mengubah glue antar kata menjadi spasi dan kern](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Jika Anda menata kode LaTeX Anda menggunakan LuaTeX (yaitu, opsi kompilator LuaLaTeX di Overleaf) maka, dengan menggunakan kode Lua, Anda dapat memproses pasca sebuah paragraf yang telah ditata untuk menemukan glue antar kata dan menggantinya dengan karakter spasi plus kern yang sesuai. Jarak yang disediakan oleh lebar karakter spasi dapat ditambahkan ke (atau dikurangi dengan) menghitung nilai kern yang tepat untuk mempertahankan jumlah spasi yang diberikan oleh glue antar kata, sehingga tidak ada perbedaan visual pada hasil penataan huruf. Untuk memahami perbedaan yang ditimbulkan hal ini bagi pengguna perangkat lunak aksesibilitas, dengarkan rekaman suara ini yang diambil dari fitur Adobe Reader DC *Read Out Loud* fitur. Fitur ini merekam dua baris teks dalam proyek tersebut yang dibacakan dengan suara keras, sebelum dan sesudah mengubah glue menjadi spasi. Perhatikan bagaimana pembacaan kedua baris, yang menggunakan spasi, dibacakan dengan cepat dan lancar dibandingkan dengan baris yang menggunakan glue antar kata. Proyek Overleaf ini adalah file plain TeX yang dikompilasi menggunakan LuaTeX dan disediakan hanya untuk penggunaan eksperimental; proyek ini tidak dimaksudkan sebagai solusi lengkap berkualitas produksi. Terutama, proyek ini dirancang untuk membantu memahami isu teknis terkait PDF aksesibel. Kode Lua yang digunakan dalam proyek tersebut didasarkan pada karya yang terdapat dalam artikel Overleaf yang jauh lebih awal [Kotak dan Glue: Pengantar Singkat, tetapi Visual, Menggunakan LuaTeX](/latex/id/artikel-mendalam/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Catatan: Demi kesederhanaan, proyek ini menggunakan pemuat font OpenType sangat minimal miliknya sendiri yang diturunkan dari kode ini: . ### Masalah aksesibilitas lainnya dan PDF bertag Meskipun penandaan memungkinkan identifikasi item konten yang ada dalam sebuah PDF, beberapa jenis konten, seperti grafis atau matematika kompleks, memerlukan data atau informasi tambahan jika ingin dibuat aksesibel melalui perangkat lunak yang dirancang untuk mendukung orang dengan gangguan penglihatan. Untuk menyediakan dan mendukung aksesibilitas bagi berbagai jenis konten, spesifikasi PDF menyediakan kemampuan untuk melampirkan “Deskripsi Alternatif” atau “ActualText” pada item konten, memberikan deskripsi tekstual yang sesuai atau representasi lain yang dapat dibaca mesin. Misalnya, MathML telah ditetapkan untuk tujuan ini dalam spesifikasi PDF 2.0. #### Apakah itu “konten nyata” atau hanya sebuah artefak? Bagi orang dengan gangguan penglihatan, proses membagi dan menampilkan konten dalam potongan persegi panjang seukuran halaman memiliki efek samping yang tidak diinginkan, seperti pemenggalan kata. Selain itu, aspek desain halaman atau tata letak yang digunakan untuk meningkatkan penyajian visual sama sekali tidak bermakna bagi mereka yang tidak dapat melihatnya. Karena alasan ini, penandaan konten PDF harus mengenali bahwa beberapa konten dalam PDF harus diperlakukan sebagai sebuah *artefak* dari penyajian visual atau pemaginan. Misalnya, nomor halaman, header dan footer halaman, latar belakang berbayang, atau isyarat desain lainnya perlu diidentifikasi agar perangkat lunak aksesibilitas yang memproses konten tahu untuk mengabaikannya. ## Gambaran umum standar PDF/A Permintaan untuk menghasilkan PDF aksesibel biasanya merujuk pada standar ISO yang disebut [ISO 19005](https://www.iso.org/standard/38920.html), yang lebih umum disebut PDF/A. Namun, karena PDF/A merupakan sebuah *keluarga* kumpulan standar, sekadar meminta “kepatuhan PDF/A” mungkin tidak sepenuhnya menentukan persyaratan sebenarnya. Untuk melihat alasannya, mari mulai dengan gambaran singkat tentang PDF/A dari [situs web PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (diakses 21 Mei 2020) yang menjelaskan ISO 19005 (PDF/A) sebagai berikut: > “Tujuan utama ISO 19005 adalah mendefinisikan format file berbasis PDF, yang dikenal sebagai PDF/A, yang menyediakan mekanisme untuk merepresentasikan dokumen elektronik dengan cara yang mempertahankan tampilan visual statisnya dari waktu ke waktu, terlepas dari alat dan sistem yang digunakan untuk membuat, menyimpan, atau merender file tersebut. > > Tujuan sekunder ISO 19005 adalah mendefinisikan kerangka kerja untuk merepresentasikan struktur logis dan informasi semantik lainnya dari dokumen elektronik dalam file yang sesuai. > > Tujuan lain ISO 19005 adalah menyediakan kerangka kerja untuk merekam konteks dan sejarah dokumen elektronik dalam metadata di dalam file yang sesuai.” Jelas, PDF/A memiliki beberapa tujuan inti. ### Evolusi dan pertumbuhan PDF Fitur [Spesifikasi PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) diterbitkan pada 1993 dan hanya berisi 230 halaman. Namun, 13 tahun kemudian spesifikasi untuk [versi PDF 1.7 dari Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) jauh melebihi 1000 halaman! Seiring waktu, ukuran dan kompleksitas spesifikasi PDF telah berkembang dengan menambah set fitur yang didukung: mencakup teknologi baru dan kebutuhan alur kerja serta kasus penggunaan berbasis PDF yang semakin canggih di berbagai pasar dan komunitas. Namun, kemungkinan tidak ada pengguna, atau sekelompok pengguna, yang pernah memanfaatkan semua kemungkinan tersebut: PDF harus “mencakup semuanya” agar dapat melayani kebutuhan pasar seluas mungkin. Misalnya, banyak fitur PDF yang dirancang untuk mendukung pencetakan komersial kelas atas tidak diperlukan oleh penggunaan kantor sehari-hari yang khas sebagai format untuk menyimpan atau berbagi dokumentasi. ### PDF/A: “kembali ke dasar” untuk PDF Tujuan inti PDF/A adalah memastikan PDF yang sesuai cocok untuk pengarsipan jangka panjang atau berisi konten yang dapat diakses oleh orang-orang yang menggunakan berbagai teknologi bantu untuk “mengonsumsi” PDF tersebut. Untuk mencapai tujuan ini, PDF/A membatasi kumpulan fitur PDF yang diizinkan dalam file PDF yang sesuai, melarang penggunaan fitur yang dapat mengompromikan kemampuan arsip atau aksesibilitas. Anda dapat menganggap PDF/A sebagai seperangkat standar yang menentukan bagaimana file PDF yang sesuai menggunakan sebuah *subset* dari spesifikasi PDF lengkap untuk menghasilkan file yang cocok untuk pengarsipan jangka panjang atau memastikan kontennya dapat diakses. Pembatasan PDF/A memungkinkan PDF digunakan sebagai “kertas digital arsip” yang independen dari teknologi pembaca PDF dan lingkungan komputasi yang digunakan untuk mengakses kontennya. PDF yang sesuai tidak boleh memuat apa pun yang perilakunya “bergantung pada implementasi”—yaitu, bergantung pada perangkat lunak atau sistem operasi tertentu yang digunakan untuk melihat atau memprosesnya. PDF juga harus *lengkap*: sumber daya dokumen utama harus disematkan dalam file—seperti font atau profil warna. ### Versi PDF/A dan tingkat kepatuhan Ada berbagai *versi* dari standar PDF/A, masing-masing mencerminkan versi tertentu dari spesifikasi PDF formal (PDF 1.4, 1.7, dan 2.0). Selain itu, ada berbagai *tingkat kepatuhan* yang menentukan aspek mana dari standar PDF/A yang dipatuhi oleh sebuah file PDF. Oleh karena itu, saat mengklaim atau mensyaratkan “kepatuhan PDF/A”, Anda harus memikirkan file PDF yang sesuai dengan **PDF/A-** Sebagai contoh * PDF/A-1a: berarti PDF/A versi 1, tingkat kepatuhan a * PDF/A-2b: berarti PDF/A versi 2, tingkat kepatuhan b Kita membahas ini sedikit lebih rinci. #### Versi PDF/A Standar PDF/A berada di bawah naungan ISO, diterbitkan sebagai standar bernama ISO 19005. Seperti disebutkan, spesifikasi PDF telah berkembang seiring waktu dan hal itu, pada gilirannya, mengharuskan pembaruan terhadap ISO 19005, menghasilkan tabel di bawah ini: | | | | | --------------- | ---------------- | ------------------------- | | **Versi PDF/A** | **Standar ISO** | **Berdasarkan versi 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) | Pada saat penulisan ini (April/Mei 2020) PDF/A-4 yang diperbarui (ISO 19005-4) sedang [dalam persiapan](https://www.iso.org/standard/71832.html). #### Tingkat kepatuhan PDF/A Selain tiga versi PDF/A (PDF/A-1, PDF/A-2, dan PDF/A-3) ada tiga *tingkat kepatuhan*: * Level A (aksesibel) untuk aksesibilitas (mencakup persyaratan pengarsipan Level B) * Level B (dasar) untuk pengarsipan * Level U (Unicode) (= pengarsipan plus menggunakan Unicode untuk teks) Berikut deskripsi singkat tentang tingkat kepatuhan ini: * **Level B (dasar)** adalah persyaratan minimum untuk kepatuhan di bawah PDF/A. Ini mendefinisikan persyaratan untuk memastikan dokumen PDF yang sesuai cocok untuk pengarsipan jangka panjang—bahwa dokumen tersebut dapat selalu dilihat atau dicetak dengan andal, terlepas dari perangkat lunak, alat, atau sistem operasi tertentu. * **Level A (aksesibilitas)** mencakup persyaratan kepatuhan Level B tetapi, sebagai tambahan, mensyaratkan penggunaan PDF bertag untuk menyediakan struktur logis dan informasi urutan baca bersama dengan penggunaan Unicode untuk memungkinkan akses ke teks dokumen. * **Level U (Unicode)** kepatuhan ditambahkan ke PDF/A-2 dan dibangun di atas Level B dengan tambahan mengharuskan penggunaan Unicode untuk teks dokumen, tetapi tidak sejauh Level A karena tidak mewajibkan informasi struktur. Versi PDF/A dan tingkat kepatuhan dapat diringkas dalam sebuah tabel: | | | | | | --------------------- | --------------------------------------- | -------- | -------- | | **Tingkat kepatuhan** | **PDF/A-** | | | | Level A (aksesibel) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Level B (dasar) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Level U (Unicode) | Tidak berlaku (tidak ada untuk PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Aksesibilitas Universal”) Meskipun kepatuhan Level A dari standar PDF/A cukup membantu mendefinisikan persyaratan untuk PDF aksesibel, standar ISO lain yang disebut [ISO 14289](https://www.iso.org/standard/64599.html), yang disebut PDF/UA, melangkah lebih jauh. PDF/UA memperkuat persyaratan aksesibilitas dan memperjelas panduan yang terdapat dalam standar PDF/A dan telah menjadi standar pilihan untuk PDF aksesibel. #### Protokol Matterhorn Pembaca yang sangat tertarik untuk mempelajari lebih lanjut tentang kepatuhan PDF/UA mungkin tertarik pada [Protokol Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) yang merupakan “daftar semua kemungkinan cara untuk gagal memenuhi kepatuhan PDF/UA”. ### Perangkat lunak validasi Untuk memeriksa apakah sebuah file PDF sesuai dengan standar tertentu, file itu harus *divalidasi* diperiksa menggunakan perangkat lunak kepatuhan yang memindai PDF untuk memeriksa apakah konten dan strukturnya sesuai dengan persyaratan standar tersebut—seperti PDF/UA atau PDF/A-*x*a (di mana *x* = 1, 2, atau 3). Perhatikan bahwa validasi PDF—memprosesnya dengan alat validasi pilihan—dapat menghasilkan pesan diagnostik atau peringatan yang bisa sangat samar bagi pengguna non-ahli—mungkin karena beberapa data (atau struktur) PDF tingkat rendah yang gagal memenuhi standar yang relevan. Bagi banyak penulis, menafsirkan peringatan tersebut dan mengubahnya menjadi perbaikan yang dapat ditindaklanjuti untuk dokumen mereka bisa menjadi tantangan yang cukup besar. #### Perangkat lunak validasi gratis * [veraPDF](https://verapdf.org/) yang, mengutip situs web mereka (diakses 28 Mei 2020), adalah “validator format file sumber terbuka yang dibuat khusus, mencakup semua bagian dan tingkat kepatuhan PDF/A”. * (hanya Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) yang merupakan “...alat pemeriksa aksesibilitas PDF gratis yang telah diuji dan dicoba sejak 2010”. #### Perangkat lunak validasi komersial * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) menyediakan serangkaian pengujian validasi PDF beserta alat untuk mengedit dan memperbaiki tag dalam file PDF yang tidak sesuai. ### PDF Association: sumber informasi yang sangat baik Fitur [PDF Association](https://www.pdfa.org/) menghasilkan banyak *dokumentasi yang sangat baik* sumber daya tentang PDF/A, PDF/UA, dan banyak topik lain terkait PDF—termasuk video di [kanal YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) beserta artikel dan publikasi teknis gratis yang tersedia di situs web mereka. Salah satu publikasi tersebut adalah [PDF/UA secara Singkat](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) yang memberikan pengantar yang sangat berharga tentang standar PDF/UA dan persyaratannya. ## PDF aksesibel dari mesin TeX dan LaTeX Mudah-mudahan, pembahasan sebelumnya telah menunjukkan bahwa produksi file PDF yang sepenuhnya aksesibel dan bertag dengan benar adalah tantangan teknis yang berat. Selain itu, bahkan contoh Microsoft Word yang sederhana menunjukkan bahwa penulis dengan sangat mudah dapat menggunakan kombinasi fitur perangkat lunak yang menghasilkan dokumen PDF bertag yang gagal memenuhi kriteria aksesibilitas. Sebagai alat penulisan, LaTeX memberi penulis fleksibilitas yang nyaris tak terbatas dalam rentang dan kompleksitas dokumen yang dapat Anda buat—yang mungkin justru menjadi alasan memilihnya sejak awal. LaTeX juga mendukung ekstensibilitas melalui ribuan paket tambahan yang dapat digunakan penulis sebagai bagian dari dokumen mereka. Selain itu, penulis bebas menulis makro TeX atau LaTeX baru, atau mendefinisikan ulang yang sudah ada, untuk mencapai efek tertentu. Namun, mungkin kebebasan dan fleksibilitas ini ada harganya karena konten yang dihasilkan oleh interaksi sangat banyak dari semua paket dan makro LaTeX itu “entah bagaimana” perlu diorkestrasi jika LaTeX ingin secara otomatis menghasilkan keluaran PDF yang bertag dan aksesibel dengan benar. Dalam praktiknya, ekstensibilitas, kekuatan, fleksibilitas, dan “kebebasan” penulisan yang diberikan oleh LaTeX menimbulkan tantangan teknis bagi produksi dokumen PDF bertag yang sepenuhnya aksesibel secara mulus dan transparan (“otomatis”) yang sesuai dengan standar PDF/UA atau PDF/A-{1|2|3}a. Komunitas TeX dan LaTeX yang lebih luas sedang berusaha keras mengatasi tantangan tersebut dan The TeX User Group (TUG) mengoordinasikan upaya penelitian dan pengembangan melalui aksesibilitas PDF dan standar PDF [kelompok kerja](https://www.tug.org/twg/accessibility/). Ada sebuah [milis diskusi](https://tug.org/mailman/listinfo/accessibility) yang menyediakan cara bagi pihak-pihak yang tertarik untuk mendiskusikan produksi file PDF bertag menggunakan TeX dan LaTeX. Dalam diskusi ini, penting diingat bahwa LaTeX sebenarnya bukan program penataan huruf yang dapat dieksekusi, melainkan kumpulan besar makro (perintah) canggih yang ditulis dalam bahasa tingkat lebih rendah yang disebut TeX. Di antara dokumen LaTeX yang Anda susun dengan cermat dan PDF bertata huruf akhir terdapat perangkat lunak yang disebut mesin TeX yang tugasnya adalah “mengeksekusi” kumpulan perintah LaTeX (yaitu, makro) yang digunakan untuk menulis dan menyusun dokumen Anda—mengubahnya menjadi representasi tertata huruf dari dokumen Anda yang disimpan sebagai file PDF. Mereka yang baru mengenal ekosistem TeX/LaTeX sering kali, dan dapat dimengerti, bingung oleh banyaknya nama yang terdengar samar yang digunakan untuk alat yang mereka temui: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX, dan LuaLaTeX. Jika Anda merasakan hal yang sama, bantuan tersedia dalam artikel Overleaf [Apa Arti Sebuah Nama: Panduan untuk Berbagai Ragam TeX](/latex/id/artikel-mendalam/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) yang menjelaskan asal-usul dan arti dari semua istilah tersebut. Mesin TeX seperti pdfTeX, XeTeX, atau LuaTeX adalah kelas perangkat lunak yang disebut *kompilator dokumen*: mereka mengambil kode LaTeX Anda dan mengompilasinya ke bentuk tertata huruf dengan “mengonversi” makro LaTeX (perintah) kembali menjadi instruksi bahasa TeX tingkat lebih rendah yang kemudian “dieksekusi” untuk menghasilkan hasil tertata huruf. Sistem penataan huruf berbasis TeX mampu menghasilkan konten yang sangat kompleks—termasuk matematika tingkat lanjut, notasi musik, struktur kimia, grafis, dan teks tertata huruf multibahasa yang canggih. Untuk memastikan dokumen-dokumen kompleks tersebut mematuhi standar dan regulasi aksesibilitas, mesin TeX, bersama dengan kumpulan makro LaTeX, dan paket LaTeX, perlu menghasilkan file PDF bertag yang sesuai dengan menyematkan banyak data tambahan ke dalam file PDF yang mereka hasilkan. Meskipun mesin TeX dapat menghasilkan file PDF yang sangat kompleks, proses internal, algoritma, dan fungsinya tidak memiliki *bawaan* fitur *yang secara khusus dirancang* untuk mendukung produksi PDF bertag dan aksesibel. Sebaliknya, dukungan untuk penandaan dan aksesibilitas harus dicapai melalui pemrograman makro yang kompleks yang “menyuntikkan” data tambahan ke dalam PDF yang dihasilkan oleh mesin TeX—menciptakan urutan konten bertanda, elemen struktur, dan struktur data struktur logis yang disimpan dalam `StructTreeRoot`. Dan di sinilah “orkestrasi” itu menjadi sangat penting: kode di dalam inti (kernel) LaTeX bersama dengan kode dalam ribuan paket dan makro yang dibuat penulis tanpa terhitung jumlahnya harus bekerja sama dengan sangat hati-hati untuk memastikan eksekusi makro menghasilkan penandaan yang benar pada konten dokumen yang dihasilkan. “Orkestrasi” itu harus andal—tidak peduli bagaimana penulis memilih untuk menggabungkan dan menggunakan fitur, perintah, dan fungsionalitas LaTeX, sistem paketnya, dan kekuatan makro TeX. ### Kebutuhan para penulis Bagi kebanyakan orang, LaTeX hanyalah alat yang memungkinkan Anda membuat dokumen yang ditata huruf dengan indah dengan kebebasan untuk memilih paket guna membantu Anda mencapainya. Sebagian besar penulis LaTeX hanya ingin dokumen mereka “berjalan”: tertata huruf tanpa kesalahan sehingga mereka dapat menyerahkan tesis, artikel, laporan, atau menyelesaikan buku yang telah lama ditunggu-tunggu itu. Wajar jika pengguna LaTeX mengharapkan kumpulan paket LaTeX pilihan mereka dapat hidup berdampingan dengan damai, beroperasi bersama secara mulus dan transparan untuk menyediakan perintah dan fitur yang diperlukan guna menghasilkan dokumen mereka. Keinginan yang sama kemungkinan besar muncul saat dihadapkan pada persyaratan untuk menghasilkan PDF bertag dari LaTeX: semuanya harus “langsung bekerja”, secara transparan dan dengan intervensi penulis seminimal mungkin. Sayangnya, kita masih jauh dari pengalaman “Hei Presto! penandaan terjadi begitu saja apa pun hal aneh yang saya lakukan”. Menggabungkan persyaratan teknis aksesibilitas plus PDF bertag dengan LaTeX dan kebebasan menulis pada dasarnya memang kompleks dan, mungkin, tidak terelakkan bahwa beberapa bentuk “disiplin penulis” mungkin diperlukan jika tantangan teknis itu ingin menjadi layak untuk implementasi dan penyelesaian praktis. Masalah terpisah, tetapi terkait, adalah bahwa penandaan yang salah mungkin tidak berdampak visual pada PDF akhir: secara visual, file itu mungkin tampak sempurna dan kemungkinan juga akan dicetak tanpa masalah, tetapi tanpa sepengetahuan penulis, penandaannya mungkin “rusak”, baru diketahui melalui kegagalan berikutnya pada pemeriksaan kepatuhan/validasi PDF/A dan/atau pengujian praktis lebih lanjut melalui perangkat lunak aksesibilitas seperti pembaca layar. ### File PDF yang dihasilkan di Overleaf Overleaf menyediakan kepada komunitas penggunanya editor LaTeX berbasis peramban beserta alat manajemen proyek dan dokumen yang memfasilitasi penulisan kolaboratif—semuanya dibangun di atas instalasi TeX Live standar. Pada dasarnya, Overleaf memungkinkan pengguna untuk “menjalankan LaTeX dari jarak jauh” melalui peramban web, memberikan lapisan perlindungan dari kompleksitas mengelola dan memelihara sistem TeX Live penuh. Konsekuensi dari penggunaan instalasi TeX/LaTeX standar oleh Overleaf adalah bahwa PDF yang dihasilkan dari kode LaTeX yang ditulis di editor Overleaf dibuat menggunakan teknologi yang persis sama seperti yang ada di instalasi TeX Live versi sama lainnya—termasuk pengaturan yang diinstal pengguna pada perangkat lokal mereka. Satu-satunya perbedaan adalah mesin TeX yang mengompilasi dan memproses kode LaTeX Overleaf berjalan di server jarak jauh, bukan di mesin lokal. Overleaf memang melinearkan PDF yang dihasilkan TeX agar unduh/tampil lebih efisien di peramban, tetapi proses itu tidak terkait dengan aksesibilitas konten PDF itu sendiri. Produksi PDF aksesibel melalui Overleaf bergantung pada kemampuan dan fitur yang dibangun ke dalam mesin TeX standar bersama dengan ketersediaan paket makro LaTeX yang sesuai yang dapat digunakan pengguna sebagai bagian dari dokumen mereka. Dokumen LaTeX yang dibuat menggunakan Overleaf harus tetap kompatibel dengan instalasi TeX dan LaTeX lainnya karena pengguna sering perlu mengekspor proyek LaTeX mereka dari Overleaf untuk dikirim ke berbagai sistem jurnal penerbit. Memasukkan fitur khusus Overleaf ke dalam dokumen LaTeX-nya, atau ke mesin TeX yang mendasarinya, akan sangat menghambat kebebasan pengguna untuk menggunakan karya mereka di tempat lain. Overleaf mengakui dan mendukung kebutuhan akan PDF yang sepenuhnya aksesibel yang dihasilkan dari sistem penulisan TeX/LaTeX: kami menginvestasikan waktu untuk meneliti isu aksesibilitas, mengeksplorasi perkembangan terbaru dalam mesin TeX dan paket LaTeX eksperimental yang mendukung PDF bertag. Pada akhirnya, pada saat penulisan ini, belum ada solusi “siap pakai” yang dapat digunakan penulis LaTeX (melalui `\usepackage`) untuk menghasilkan secara mulus dan transparan PDF yang sepenuhnya aksesibel dan patuh PDF/UA dari dokumen LaTeX generik. Ketika solusi tersebut tersedia melalui pembaruan TeX Live, tentu saja solusi itu akan tersedia bagi komunitas pengguna Overleaf. ### Beberapa paket LaTeX untuk mengeksplorasi penandaan dan aksesibilitas Bagi banyak orang, [tex.stackexchage](https://tex.stackexchange.com/) adalah tujuan pertama untuk mencari bantuan terkait TeX, LaTeX, atau ConTeXt. Ini adalah sumber daya yang luar biasa dan memiliki banyak pertanyaan tentang topik [aksesibilitas](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) dan produksi PDF aksesibel melalui LaTeX. Jika Anda membaca dan menjelajahi pertanyaan-pertanyaan ini, serta aliran jawaban dan komentar yang menyusul, hanya satu kesimpulan yang tak terelakkan: saat ini belum ada solusi penuh, tingkat produksi, untuk secara otomatis membuat PDF bertag yang sepenuhnya aksesibel dan sesuai standar dari setiap jenis dokumen LaTeX. Namun, ada beberapa paket yang mendukung penandaan—meski mungkin dalam rentang kasus penggunaan dan jenis dokumen yang terbatas. Daftar berikut disediakan bagi pembaca yang ingin menjelajahi penandaan PDF berbasis LaTeX: * [`tagpdf` ke preambel dokumen Anda (seperti disarankan](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): paket yang sangat mumpuni yang dirancang untuk bereksperimen dengan penandaan PDF. Mendukung pdfTeX dan LuaTeX dan menyediakan dokumentasi yang sangat berguna dan menarik yang berisi beberapa catatan sangat baik tentang tantangan teknis pembuatan PDF bertag melalui mesin TeX; sangat direkomendasikan untuk dibaca bagi siapa pun yang ingin lebih memahami isu-isu yang terlibat. Arah pengembangan ke depan kemungkinan besar ke LuaTeX. * [`axessibility` ke preambel dokumen Anda (seperti disarankan](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov dan Universitas Turin): menyediakan akses ke rumus dalam file PDF melalui teknologi bantu. * [`aksesibilitas` ke preambel dokumen Anda (seperti disarankan](https://ctan.org/pkg/accessibility) (Andy Clifton): membuat file PDF bertag dan terstruktur. Catatan CTAN menyatakan bahwa paket ini “Ditujukan untuk pengguna kelas dokumen KOMA-Script”. * [`accsupp` ke preambel dokumen Anda (seperti disarankan](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): paket eksperimental untuk memberikan dukungan aksesibilitas yang lebih baik bagi file PDF. Referensi penting lainnya adalah sebuah makalah tahun 2018 [Menerapkan standar PDF untuk Publikasi Matematika](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) oleh Dr Ross Moore dari Department of Mathematics, Macquarie University. Dalam makalah itu, Dr Moore mencantumkan gambaran singkat tentang tantangan penandaan PDF di LaTeX: > “Sumber utama kesulitan terletak pada cara lingkungan yang berbeda dapat saling berinteraksi. Ada banyak situasi dalam LaTeX di mana satu lingkungan atau struktur sebenarnya belum selesai sampai lingkungan berikutnya dimulai. Jadi, ini bukan sekadar masalah membungkus tag awal dan akhir di sekitar setiap bagian konten yang disediakan. Sebaliknya, seseorang perlu memahami seluk-beluk bagaimana lingkungan yang berbeda dan struktur lainnya benar-benar dimulai dan diakhiri, dalam konteks yang dibentuk oleh materi di sekitarnya.” Dr Moore juga merupakan pemelihara saat ini dari [`pdfx`](https://ctan.org/pkg/pdfx) paket serta seorang ahli dan pelopor PDF bertag menggunakan TeX/LaTeX. Karyanya sangat layak dicari—termasuk video di YouTube ini yang memberikan wawasan menarik: {% embed url="" %} #### Catatan tentang paket pdfx Fitur [`pdfx`](https://ctan.org/pkg/pdfx) paket (Ross Moore dkk.) menyediakan dukungan yang sangat baik untuk PDF/A-1|2|3b (pengarsipan), dan opsi lainnya, tetapi belum menghasilkan PDF bertag. --- # 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/id/topik-lainnya/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.