Mengubah PDF menjadi teks adalah masalah yang sulit

 (marginalia.nu)
4 poin oleh GN⁺ 2025-05-15 | 1 komentar | Bagikan ke WhatsApp
  • Pengindeksan PDF telah ditambahkan ke mesin pencari, tetapi mendapatkan teks terstruktur yang layak dipakai untuk pencarian dari PDF jauh lebih rumit dibanding memproses HTML
  • PDF lebih dekat ke format grafis berbasis koordinat daripada dokumen teks, sehingga glif bisa ditempatkan dalam keadaan berotasi, saling tumpang tindih, atau urutannya tercampur
  • PDFTextStripper dari PDFBox bisa menjadi titik awal, tetapi tidak cukup mempertahankan struktur semantik seperti judul dan paragraf, sehingga ada batasan dalam menilai relevansi pencarian
  • Untuk membedakan judul dan paragraf, heuristik seperti statistik ukuran font per halaman dan median jarak antarbaris lebih berguna daripada acuan tingkat seluruh dokumen
  • Karena ekstraksi teks PDF yang sempurna itu sulit, target yang realistis untuk mesin pencari adalah solusi yang cukup baik untuk memperoleh struktur judul, abstrak, dan isi secara stabil

Masalah yang terungkap saat menambahkan pengindeksan PDF

  • Mesin pencari baru-baru ini menjadi mampu mengindeks format berkas PDF, dan perubahan tersebut akan diluncurkan selama beberapa bulan ke depan
  • Dari sudut pandang mesin pencari, HTML yang rapi adalah yang paling mudah ditangani, tetapi PDF tidak langsung menyediakan teks terstruktur pada tingkat yang sama
  • Meski secara tampilan teks terlihat ada, memulihkan kalimat dan paragraf yang bisa dicari dari dalam PDF pada dasarnya merupakan persoalan terpisah

Mengapa PDF sulit untuk ekstraksi teks

  • PDF bukan format teks biasa, melainkan lebih dekat ke format grafis
  • Representasi internalnya lebih mirip penempatan glif pada koordinat di atas “kertas” daripada kalimat atau paragraf
  • Glif bisa berada dalam kondisi berikut
    • diputar
    • saling bertumpuk
    • muncul tidak sesuai urutan baca
    • hanya memiliki sangat sedikit informasi semantik yang menempel
  • Fakta bahwa pencarian ctrl+f bisa bekerja di penampil PDF atau browser sendiri sudah merupakan hasil yang cukup mengagumkan
  • Model machine learning berbasis visi mungkin merupakan pendekatan yang baik saat ini, tetapi tidak cocok untuk skala pemrosesan ratusan GB PDF di satu server tanpa GPU

Bisa mulai dengan PDFBox, tetapi belum cukup

  • Ini bukan masalah yang sepenuhnya belum dijelajahi, jadi kelas PDFTextStripper dari PDFBox bisa dijadikan titik awal
  • PDFTextStripper mengekstrak teks dari PDF, tetapi sesuai namanya, fokusnya adalah “mengupas” teks
  • Bagi mesin pencari, informasi semantik seperti judul adalah sinyal relevansi yang penting, tetapi dari hasil ekstraksi dasar saja struktur semacam ini sulit diperoleh secara memadai

Heuristik untuk menemukan judul

  • Deteksi judul yang paling sederhana adalah mencari baris dengan ketebalan semibold atau lebih yang terpisah dari teks lain
  • Namun, tidak semua judul ditampilkan tebal, dan banyak dokumen membedakan judul lewat ukuran font
  • Titik acuan ukuran font global mudah berubah antar dokumen
    • ada dokumen yang memakai isi 10pt dan judul 16pt
    • dokumen lain bisa memakai isi 14pt dan judul 20pt
  • Terkadang statistik per halaman lebih cocok daripada statistik seluruh dokumen
    • halaman pertama bisa sangat berbeda dari halaman lainnya dalam pemilihan font karena adanya abstrak dan daftar penulis
    • pada dokumen contoh, judul dokumen memakai font ukuran 17, sedangkan judul-judul berikutnya memakai font ukuran 14
  • Tiap halaman umumnya memiliki ukuran font dominan yang sesuai dengan isi utama
  • Dengan menambahkan koefisien sekitar 20% pada ukuran font median per halaman, judul bisa diidentifikasi dengan cukup stabil
  • Masih ada pengecualian, tetapi sebagian besar kasus penting bisa ditangkap

Menggabungkan judul multi-baris menjadi satu

  • Karena gaya penulisan, judul sering terpecah menjadi beberapa baris, sehingga baris-baris judul yang berurutan kadang perlu digabung menjadi satu
  • Menentukan kapan harus menggabungkannya bukan hal yang sederhana
  • Dalam contoh, kondisi berikut muncul bersamaan
    • judul dua baris
    • judul rata kanan
    • nama penulis semibold yang mengikuti judul
    • judul tidak tebal yang berada beberapa baris di bawahnya
  • Indentasi juga dipakai sebagai sinyal pemisah paragraf, sehingga judul rata kanan membuat penilaian jadi lebih sulit
  • Menggabungkan judul berurutan yang memiliki ukuran font dan ketebalan sama umumnya bekerja cukup baik, tetapi juga bisa menghasilkan keluaran yang tidak diinginkan

Jebakan yang ditimbulkan jarak antarbaris dalam identifikasi paragraf

  • PDFTextStripper melakukan identifikasi paragraf dengan cukup baik
  • Ia menentukan lokasi pemisahan paragraf dengan melihat jarak antarbaris dan indentasi secara bersamaan
  • Masih ada ruang perbaikan, terutama pada logika jarak antarbaris
  • Masalah besar PDFTextStripper adalah ia memakai acuan tetap untuk pemisahan baris
    • jika jarak antarbaris lebih besar dari acuan, maka dianggap bukan paragraf yang sama
    • pendekatan ini tidak cukup mencerminkan fakta bahwa jarak antarbaris berbeda-beda antar dokumen
  • Dalam draf akademik dan preprint, jarak antarbaris 1,5~2 kali cukup umum
  • Jika nilai acuannya dibuat terlalu besar, beberapa judul bisa terserap ke paragraf isi dan mengganggu identifikasi judul

Mengoreksi dengan statistik jarak antarbaris

  • Mirip dengan penanganan ukuran font, teknik statistik juga bisa diterapkan pada jarak antarbaris
  • Jika dibuat histogram jarak antarbaris pada halaman teks, biasanya akan muncul outlier besar
  • Nilai rata-rata mudah goyah oleh outlier, tetapi median kadang tepat cocok dengan jarak antarbaris yang dipakai pada isi utama
  • Dengan menambahkan koefisien tertentu pada median, bisa dibuat heuristik pemisahan paragraf yang tahan terhadap berbagai jarak antarbaris

Target realistis adalah stabilitas, bukan kesempurnaan

  • Pekerjaan mengekstrak teks dari PDF sulit menjadi sempurna
  • Format PDF sendiri tidak dirancang untuk pekerjaan semacam itu, dan saat memilih solusi yang “cukup baik”, akan muncul berbagai trade-off
  • Mesin pencari terutama tertarik pada informasi berikut
    • sinyal relevansi seperti judul
    • identifikasi abstrak
    • struktur yang cukup konsisten untuk sisa teks
  • Untuk target seperti ini, dimungkinkan mendekati solusi yang dapat memproses sebagian besar dokumen relevan tanpa terlalu banyak kesulitan

Teks sampel yang digunakan

  • Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
  • Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
  • The theory of ideas and Plato’s philosophy of mathematics (2019)
  • Dembiński, B.
  • The role of phronesis in Knowledge-Based Economy (2024)
  • Anna Ceglarska, Cymbranowicz Katarzyna

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-15
Komentar Hacker News

  • Kadang kita benar-benar lupa bahwa dulu pernah mendalami sesuatu selama berbulan-bulan atau bertahun-tahun sampai level ahli, lalu belakangan merasa, “ini baru dan menarik ya”
    Padahal sudah cukup banyak mengerjakan hal-hal menarik, tetapi hilang dari ingatan, sehingga sampai ada sesuatu yang memicunya, rasanya seperti orang yang memulai hidup dari awal
    Saya samar-samar ingat pernah mengerjakan sesuatu yang cukup keren dengan PDF dan OCR sekitar 6–7 tahun lalu, dan setelah dicari sepertinya itu Tesseract

    • Sekitar 2006, di perangkat e-book awal bernama iRex, penyalinan teks dari makalah ilmiah multikolom tidak bisa dilakukan, jadi saya menelusuri penyebabnya. Karena PDF reader-nya secara internal memakai Poppler, saya memodifikasi Poppler agar dapat menyimpulkan urutan baca dokumen multikolom dengan mengacu pada algoritma OCR yang dipublikasikan oleh Thomas Breuel, penulis Tesseract
      Itu lebih mirip hack berbasis heuristik, dan seingat saya API lama Poppler saat itu tidak merepresentasikan text run dengan cara yang cocok untuk accessibility API
      Fitur seleksi multikolom sempat masuk sampai batas tertentu, tetapi usulan peningkatan performa setelahnya sulit meyakinkan maintainer karena heuristiknya sedikit berbeda sehingga hasil seleksi berubah dalam beberapa situasi
      Sejak awal memang tidak ada satu “jawaban benar”, jadi menuntut hasil yang identik tidak masuk akal, dan begitulah seleksi multikolom di kpdf kurang lebih terbentuk
      Sekarang, untuk penggunaan seperti ini, kemungkinan lebih masuk akal memakai Tesseract secara langsung
    • Puluhan tahun-waktu tenaga manusia yang secara kolektif terbakar karena format ini tidak akan pernah bisa dikembalikan
      Entah kapan kegilaan ini akan berakhir
    • Tesseract sudah lama menjadi OCR open-source terbaik, tetapi sekarang menurut saya docTR lebih baik
      Akurasi bawaannya lebih tinggi, mendukung akselerasi GPU, dan mengimplementasikan berbagai arsitektur model deteksi serta pengenalan teks sebagai pipeline yang bisa dikombinasikan
      Modelnya juga bisa dilatih dan di-fine-tune dengan PyTorch atau TensorFlow untuk lebih meningkatkan performa pada domain tertentu
    • Pernah ketika seseorang bertanya soal C++, saya menjawab “saya tidak pernah bekerja serius dengan C++”, lalu baru teringat bahwa sekitar 20 tahun lalu saya menulis kode klien messenger privat yang dipakai ribuan orang dengan Borland C++
      Jadi hal seperti itu memang benar-benar terjadi
    • Setiap kali menyelesaikan proyek, sering muncul perasaan, “Sekarang saya jadi ahli mengerjakan ini. Tapi mungkin tidak akan pernah melakukannya lagi”
      Pekerjaan berikutnya berada di bidang yang sama sekali berbeda, jadi harus mulai lagi dari dasar

  • Akan bagus kalau ada yang membuat semacam developer tools browser untuk PDF
    Seperti “inspect element”, kita bisa melihat content stream PDF sebagai sumber, lalu memeriksa bagaimana operator teks BT … ET atau operator penempatan teks Tj menentukan dan menghasilkan setiap piksel
    Ini kebalikan dari tren sekarang, yaitu model visual yang “melihat” dan membaca PDF seperti manusia, tetapi akan jauh lebih baik kalau kita bisa memahami apa yang sebenarnya ada di dalam file PDF
    Ada beberapa alat untuk memeriksa isi PDF (https://news.ycombinator.com/item?id=41379101), tetapi berhenti di level objek PDF, sehingga seluruh content stream hanya terlihat sebagai satu objek
    Misalnya, pada halaman PDF 8 dari dokumen 6 halaman yang disebut di artikel, https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2..., teks ditempatkan dengan operator seperti BT, pengaturan font, Td, dan TJ
    Kalau “source” seperti ini dan PDF yang sudah dirender bisa dilihat berdampingan, lalu saat mouse diarahkan ke salah satu sisi area terkait di sisi lain ikut disorot, rasanya kita bisa men-debug PDF seperti halaman HTML

    • Jika PDF dirender ke DOM dengan PDF.js dari Mozilla, hasilnya bisa cukup mendekati
      Misalnya tiap Tj menjadi satu elemen DOM, dan TJ menjadi semacam kumpulan beberapa elemen
      Karena harus mencerminkan dokumen asli dengan benar agar berfungsi, kemungkinan konversinya cukup setia
    • Dengan cpdf, ini bisa dilakukan sampai taraf tertentu
      Buat JSON dengan cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json, lalu setelah JSON itu diubah, kembalikan lagi menjadi PDF dengan cpdf -j out.json -o out.pdf
      Namun tidak ada sinkronisasi dua arah secara real-time
    • Mungkin yang dimaksud adalah open-source atau gratis, tetapi Acrobat Pro yang saya pakai beberapa tahun lalu juga punya fitur yang hampir mirip
      Hanya saja caranya bukan memeriksa halaman, melainkan menelusuri content tree, dan objek di halaman memang disorot
      Bukan sampai level perintah, hanya sampai level objek atau stream
    • Notebook ini tidak persis seperti yang diinginkan, tetapi menyediakan fitur untuk memeriksa berbagai operasi menggambar di dalam PDF secara “real-time”
      https://observablehq.com/@player1537/pdf-utilities
    • Yang dibuat Tensorlake juga mendekati kombinasi ini
      Arahnya bukan sekadar “melihat” PDF seperti manusia dan membaca teks, melainkan memahami isi yang mencakup tabel, gambar, teks, rumus, hingga tulisan tangan
      Jadi mereka mem-parsing PDF dan menjalankan beberapa model untuk mengekstrak potongan Markdown atau JSON, sehingga data nyata bisa dimasukkan ke AI agent, LLM, dan aplikasi lainnya
      https://tensorlake.ai

  • “PDF ke teks” adalah ungkapan yang terlalu disederhanakan
    Di dalam kategori ini ada 1) OCR yang andal untuk indeks pencarian atau input basis data vektor, 2) ekstraksi data terstruktur untuk mengambil nilai tertentu, dan 3) pipeline dokumen end-to-end seperti otomatisasi pengajuan hipotek
    Yang perlu dipecahkan Marginalia adalah OCR nomor 1, dan berkat model seperti Gemini Flash, ini dengan cepat menjadi komoditas umum
    Saya melihat beberapa perusahaan mengganti pipeline OCR lama mereka dengan Flash dan memangkas biaya secara besar-besaran, dan itu cukup mengejutkan
    Namun nomor 2 dan 3 jauh lebih sulit, dan masih ada jurang besar dari keluaran OCR mentah hingga pipeline dokumen mission-critical di lingkungan operasional
    LLM dan model bahasa visual bukan sihir, dan Anda akan terkejut jika mengharapkan otomatisasi 100%
    Pembangunan dan pelabelan dataset, orkestrasi pipeline klasifikasi -> pemisahan -> ekstraksi, deteksi ketidakpastian dan peninjauan manusia, fine-tuning, dan lain-lain masih tetap diperlukan
    Dalam jangka panjang, mungkin bisa mendekati otomatisasi yang hampir penuh, tetapi itu butuh waktu dan upaya, dan masa depan tampaknya jelas bergerak ke arah ini
    Terkait hal itu, saya memulai perusahaan pemrosesan dokumen LLM bernama https://extend.ai

    • Dari sudut pandang aksesibilitas, kita juga membutuhkan nomor 4, yaitu OCR dan ekstraksi makna yang andal yang berfungsi di berbagai jenis dokumen
      Workflow bisnis sering kali hanya menangani beberapa dokumen yang sudah ditentukan, tetapi pembaca PDF serbaguna tidak tahu dokumen apa yang akan dibuka pengguna
      Ia harus mengenali bukan hanya teks, tetapi juga tabel, header dan footer, catatan kaki, judul, rumus matematika, dan sebagainya
      Karena ditujukan untuk konsumsi manusia, kesalahan harus diminimalkan, sehingga OCR tidak boleh digunakan saat tidak diperlukan; ia harus memanfaatkan teks dasar yang tertanam di PDF sekaligus mengekstrak struktur semantik
      Pada akhirnya diperlukan dua jalur: satu untuk PDF yang hanya berisi gambar, dan satu untuk PDF yang bisa memperoleh informasi dari content stream
      Namun content stream bisa berisi teks yang berbeda dari tampilan sebenarnya. Contohnya informasi yang disembunyikan dengan huruf putih, atau implementasi ala LaTeX yang menggambar tanda aksen dengan perintah alih-alih menggunakan aksen Unicode
      Biasanya ini berjalan sebagai aplikasi lokal di perangkat pengguna yang berperforma rendah, dan besar kemungkinan tidak ada server atau model berlangganan, sehingga model AI cloud pun tidak bisa digunakan
      Pengguna perangkat lunak aksesibilitas mungkin sulit mencetak lalu mengisi dengan pena, jadi bukan hanya formulir rapi yang sesuai spesifikasi, formulir untuk dicetak pun harus bisa diproses
      Ini masih merupakan masalah terbuka yang sama sekali belum mendekati penyelesaian, dan semua solusi saat ini kurang dalam satu atau lain cara; tidak ada satu solusi pun yang benar-benar memecahkan kelima hal di atas
    • Dari posisi saya yang harus membuat alat sendiri karena model bahasa visual terlalu tidak stabil, perusahaan yang memakai VLM pada gambar yang belum diproses kemungkinan besar akan mengalami banyak penderitaan
      Model ini sangat bagus untuk pelabelan gambar, dan cukup baik untuk dokumen sederhana seperti teks satu kolom, judul satu tahap yang rata tengah, atau satu gambar atau tabel per halaman
      Kebanyakan demo MVP menampilkan contoh seperti ini
      Namun untuk dokumen kompleks yang mencampur tabel dan gambar, sepertinya masih dibutuhkan jauh lebih banyak parameter bahkan untuk mencapai “tingkat buruk” sekalipun
      Saat ini halusinasinya terlalu parah, sampai tabel sederhana dengan judul di atas, data di tengah, dan ringkasan di bawah pun sulit dipakai apa adanya
    • Saya terus mengutak-atik pemrosesan PDF menjadi Markdown, dan seperti tulisan asli, saya terbentur deteksi header serta berbagai masalah lain
      OCR masa kini sangat bagus, tetapi mempertahankan struktur global dokumen jauh lebih rumit
      Mendapatkan HTML yang konsisten dari dokumen besar masih tampak jauh, dan untuk Markdown, hasilnya lumayan baik dengan cara melewatkan dokumen beberapa kali melalui LLM untuk mengekstrak struktur dokumen, lalu memasukkannya sebagai konteks pada ekstraksi per halaman

  • Di Apple, kami menangani masalah ini selama bertahun-tahun dengan cukup sukses, dan rahasia utamanya adalah menerima semuanya sebagai struktur geometri serta mencoba membedakan spasi antar-kata dan spasi antar-huruf dengan analisis klaster
    Pada banyak PDF, ini bekerja sangat baik, tetapi jenis PDF terlalu beragam sehingga selalu ada kasus ketika hasilnya kurang bagus
    Jika mengerjakannya lagi sekarang, saya rasa saya akan mempertahankan struktur geometri dan sepenuhnya menghindari OCR, tetapi menggunakan machine learning
    Keunggulan besar machine learning adalah tahap pelatihan bisa sepenuhnya diotomatisasi dengan memanfaatkan alat yang sudah ada untuk membuat PDF dari teks yang diketahui
    Adegan Bertrand Serlet mengumumkan fitur ini di WWDC 2009: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • Solusi yang lebih baik adalah menyematkan dokumen sumber yang dapat diedit bersama-sama di dalam PDF
    Ini mudah dilakukan di LibreOffice, dan karena kompresinya bagus, biasanya hampir tidak memakan ruang
    Dengan begitu kita bisa memperoleh informasi yang jauh lebih baik tentang teks dan makna, dan tetap berfungsi baik di pembaca PDF yang ada

    • Memang benar, tetapi kepentingan pembuat dan konsumen PDF harus selaras
      Dalam bidang e-discovery, penyedia bukti sering sengaja membuangnya sebagai PDF agar pengacara pihak lawan sulit mengonsumsi isinya
      Jika kedua pihak punya banyak uang, itu bukan penghalang, tetapi misalnya pembela umum tidak punya dana untuk mempekerjakan orang yang memproses PDF menjadi format yang mudah dibaca, sehingga waktu pemrosesan menjadi jauh lebih lama dan beban psikologis pada terdakwa meningkat
      Bahkan bisa saja datanya tidak diproses dengan benar
      Solusinya adalah membuat praktik seperti ini ilegal
      Misalnya, data penyadapan harus disediakan dalam format yang dapat dibaca mesin yang terstandardisasi, dan tidak ada alasan etis mengapa gesekan teknis sederhana boleh memengaruhi hasil proses pidana
    • Aneh bahwa solusi yang lebih baik untuk masalah mesin pencari yang harus mengekstrak teks dari PDF yang sudah ada adalah saran tentang cara membuat PDF
      Saya bertanya-tanya berapa lama waktu yang dibutuhkan sampai solusi ini berdampak
    • Benar, tetapi ini juga menciptakan kerentanan di mana dokumen sumber bisa berbeda secara sewenang-wenang dari konten PDF yang dirender
    • Sepertinya 90% ruang masalahnya adalah PDF legacy
      Di perusahaan juga ada ribuan berkas seperti ini; sebagian adalah hasil scan yang buruk, sebagian memiliki OCR Adobe yang disematkan, tetapi kebanyakan tidak punya apa-apa
    • Ini cara yang bagus jika Anda punya akses ke dokumen sumber yang digunakan untuk membuat PDF
      Namun secara umum, kita tidak punya kendali seperti itu

  • PDF di bawah ini sebenarnya adalah file .txt
    Jika disimpan dengan ekstensi .pdf, file ini bisa dibuka di PDF viewer dan juga bisa diubah dengan editor teks
    Misalnya, dengan mengedit file teks ini, saat PDF dibuka kita bisa mengubah teks yang ditampilkan di layar, font, ukuran huruf, jarak baris, jumlah karakter maksimum per baris, jumlah baris per halaman, lebar dan tinggi kertas, hingga orientasi portrait maupun landscape
    Contoh ini adalah struktur PDF minimal yang diawali dengan %PDF-1.4, dengan Catalog, Pages, Font, Page, Contents, xref, trailer, dan sebagainya ditulis langsung sebagai teks

    • PDF juga bisa berisi stream biner yang di-embed
      PDF dibuat bukan untuk teks, melainkan untuk layout dan grafik
      Contohnya memang bagus, tetapi setiap baris bisa saja dipecah menjadi satu pemanggilan per karakter, satu pemanggilan per kata, dan urutannya juga bisa tercampur
    • “PDF” adalah singkatan dari “Portable Document Format”
      Dalam dokumen referensi PDF 1.0 bagian “2.3.2 Portability”, file PDF dijelaskan sebagai file ASCII 7-bit, dan dokumen yang mencakup gambar serta karakter khusus pun disebut dideskripsikan hanya dengan subset ASCII yang dapat dicetak
      Hasilnya, dokumen itu dijelaskan sebagai sangat portabel di berbagai lingkungan hardware dan sistem operasi
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • Ini mendekati Hello World-nya PDF
      Sebagian besar PDF saat ini memiliki semua objek yang dikompresi dengan deflate
      Selain itu, agar lebih sulit ditelusuri, banyak PDF membungkus sebagian besar objeknya ke dalam objek bertipe object stream lalu mengompresinya lagi
      Jadi meskipun ingin menelusuri akhir dari 6 0 R, kita tidak bisa mencari 6 0 Obj di editor teks

  • Ada dokumen favorit yang menunjukkan kesulitan yang dijelaskan dalam tulisan ini: https://academic.oup.com/auk/article/126/4/717/5148354
    Sejak halaman pertama sudah ada teks dua kolom yang khas, judul rata tengah, dan kotak teks yang terselip di antara dua kolom sehingga mengubah panjang baris serta indentasi
    Setelah itu muncul header yang berubah pada halaman ganjil dan genap, serta aturan heading section yang sangat berbeda
    Lebih parah lagi, tidak ada spasi tambahan antarparagraf dan indentasi baris pertama juga tidak selalu ada, sehingga hampir semua kesulitan terkumpul di sana

    • API PDF CoreGraphics di MacOS pada dasarnya menyediakan teks per halaman sesuai urutan yang dienkode dalam dictionary
      Sekitar 95% hasilnya cukup baik, dan selama bertahun-tahun itu sudah cukup untuk PDFKit dan Preview di Mac
      Jika membayangkan aplikasi asli yang membuat PDF, misalnya word processor, besar kemungkinan aplikasi itu merender teks dari buffer teksnya sendiri ke konteks PDF dalam urutan yang cukup masuk akal
      Karena itu, bahkan pada dokumen dua kolom pun teks sering mengalir dengan benar dari kolom kiri ke kolom kanan, dan di dalam PDF pun sudah berada dalam urutan yang benar
      Namun untuk footer atau header halaman, kita tidak bisa tahu dalam urutan apa aplikasi pembuat PDF menumpahkannya ke konteks

  • Mengekstrak teks dari PDF, bahkan teks terstruktur, sama sekali tidak mudah
    Mengambil tabel dari dokumen HTML sering kali sederhana meskipun situs memakai antipola yang membuat semuanya menjadi div, dan akan lebih mudah lagi jika memakai elemen yang bermakna
    PDF tidak demikian
    Karena saya bukan pakar format ini, saya tidak tahu seberapa jauh dukungan struktur semantiknya, tetapi saya sering melihat PDF yang membuat tabel sebagai kumpulan longgar elemen grafis dan teks yang hanya tampak seperti tabel saat dirender
    Dalam praktiknya, saya cukup berhasil mengekstrak data tabel dengan mengubah PDF menjadi HTML menggunakan utilitas Poppler PDF, lalu mencari header tabel yang diharapkan dan menghitung kolom berdasarkan koordinat x tiap nilai untuk mengekstrak nilai per baris
    Caranya memang berantakan, tetapi bekerja stabil untuk kebutuhan tersebut, dan jauh lebih baik daripada teks biasa berformat yang jaraknya tidak konsisten atau memiliki line break di tengah baris

    • Karena frustrasi bahwa data dari PDF tidak bisa diambil seperti memakai BeautifulSoup pada halaman web, saya membuat library yang melakukan hal serupa sampai batas tertentu
      Ada berbagai fungsi tambahan juga, tetapi tujuan utamanya adalah berinteraksi dengan cara yang lebih manusiawi, seperti page.find('text:bold:contains("Summary").below().extract_text()
      Karena tiap PDF adalah mimpi buruk kustomnya sendiri, saya sedang mengumpulkan contoh-contoh yang sulit diekstrak untuk dijadikan dasar library metodologi
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • Di antara dokumen resmi pemerintah, yang paling saya sukai adalah kasus ketika teks yang dirender dan teks yang keluar saat diekstrak dengan cara umum benar-benar berbeda
    • Saya berharap suatu hari software pembersihan data saya bisa melakukan ekstraksi data tabel dari PDF
      Jika ada yang tahu library ekstraksi tabel PDF yang bisa diintegrasikan ke aplikasi C++ dan gratis atau harganya di bawah beberapa ratus dolar, beri tahu saya
    • PDF pada dasarnya adalah format markup/XML dan standarnya pun terbuka sehingga bisa dipelajari
      Ada sangat banyak cara untuk membuat PDF yang sama
      Sebagian tool lebih mirip mengekspor layout yang berisi teks dan grafik dari editor grafis, sementara tool lain lebih mirip mengekspor teks dan grafik yang berpusat pada kata, seperti word processor
      Sudut pandang aplikasi pembuat dalam menangani informasi sering memengaruhi cara output PDF-nya
      Jika mencari utilitas siap pakai, tool seperti cisdem sudah menyelesaikan masalah ini sampai tingkat yang cukup baik dalam mengekstrak data terstruktur untuk pengguna lokal
      Tool semacam ini banyak, dan banyak pula yang menjanjikan dukungan data terstruktur, tetapi harus cocok dengan pekerjaan yang ingin dilakukan

  • PDF adalah format tampilan
    Dioptimalkan untuk mata manusia dan printer, dan fiturnya makin bertambah
    Sebagai sarana transfer data antarmesin, ini buruk sekali, tetapi sangat bagus untuk dibaca manusia atau menyimpan satu halaman A4
    Jika kita mulai dari asumsi bahwa karena .pdf menyimpan teks maka teks itulah yang kita inginkan, itu sama saja seperti disuruh memperbesar mata
    Kalau tidak, kita harus menangani sesuatu yang sangat rumit
    Pertama-tama, apakah teks itu benar-benar teks atau gambar saja sudah menjadi masalah
    Mata manusia bisa membacanya tanpa masalah cukup dengan memakai ulang kacamata, tetapi parser bisa rusak karena kesalahan segmentasi
    Karena PDF ditujukan untuk dibaca manusia, untuk membaca PDF kita harus meniru manusia

  • Dulu saya pernah membuat parser PDF mainan, dan setelah memahami cara format itu bekerja, saya sangat terkejut
    Jika memikirkan hal itu, semakin aneh bahwa PDF sering dipakai untuk kebutuhan yang banyak teks
    Terutama teringat kasus seperti faktur
    Sistem digital seharusnya dapat mengekstrak data dari file dengan mudah, sekaligus diformat agar nyaman dilihat manusia
    Rasanya akan jauh lebih baik jika industri teknologi beralih ke format yang lebih baik

    • XML+XSLT hampir menjadi solusi seperti itu, tetapi sayangnya browser kini tidak lagi mendukung file XML lokal dan hanya mendukung XML dari server jarak jauh