Teknologi untuk Mengonversi PDF ke Markdown dengan Cepat dan Akurasi Tinggi

 (github.com/VikParuchuri)
2 poin oleh GN⁺ 2023-12-02 | 1 komentar | Bagikan ke WhatsApp
  • Marker adalah tool document intelligence yang mengonversi dokumen PDF serta gambar, PPTX, DOCX, XLSX, HTML, dan EPUB ke Markdown, JSON, chunks, atau HTML dengan cepat dan akurat
  • Mendukung pemformatan tabel, formulir, rumus, matematika inline, tautan, referensi, dan blok kode, serta ekstraksi/penyimpanan gambar dan penghapusan artefak seperti header/footer
  • Untuk meningkatkan akurasi, LLM dapat digunakan bersama melalui --use_llm; default-nya gemini-2.0-flash, dan pengguna dapat memilih Gemini, Ollama, Claude, OpenAI, Azure OpenAI, dan lainnya
  • Dalam benchmark, Marker mencatat rata-rata 2,83837 detik per satu halaman PDF, skor heuristik 95,6709, dan skor LLM 4,23916; pada mode batch H100, throughput diperkirakan mencapai 25 pages/second
  • Membutuhkan Python 3.10+ dan PyTorch; kode berlisensi GPL, sementara bobot model memakai lisensi AI Pubs OpenRAIL-M yang dimodifikasi, dengan ketentuan gratis untuk riset, penggunaan pribadi, dan startup dengan funding/revenue di bawah $2M

Dokumen yang Dikonversi Marker dan Outputnya

  • Marker mengonversi dokumen ke Markdown, JSON, chunks, dan HTML
  • Format input mencakup PDF, gambar, PPTX, DOCX, XLSX, HTML, dan EPUB, serta memproses dokumen dalam semua bahasa
  • Cakupan pemrosesan elemen dokumen:
    • Tabel, formulir, rumus, matematika inline
    • Tautan, referensi, blok kode
    • Ekstraksi dan penyimpanan gambar
    • Penghapusan header, footer, dan artefak lainnya
  • Dapat diperluas dengan formatting dan logic sendiri
  • Jika diberi skema JSON, dapat melakukan ekstraksi terstruktur; fitur ini masih beta
  • Berjalan di GPU, CPU, dan MPS

Platform Terkelola Datalab

  • Platform terkelola Datalab menjalankan model open source terbaru Chandra
  • Chandra diperkenalkan sebagai model yang memberikan akurasi lebih tinggi daripada Marker, tanpa penyimpanan data secara default, serta menyediakan SOC 2 Type 2 dan BAA kustom
  • Layanan batch processing untuk workload berkapasitas besar pernah memproses 200M+ halaman per minggu
  • Saat mendaftar, pengguna mendapatkan kredit gratis $5, dan tersedia juga playground publik
  • Untuk self-hosting komersial diperlukan lisensi, sementara lisensi on-premises perlu ditanyakan secara terpisah

Performa dan Mode Hybrid LLM

  • Marker menyajikan hasil benchmark yang kompetitif dibanding layanan cloud seperti Llamaparse dan Mathpix maupun tool open source lain
  • Hasil performa lengkap di README didasarkan pada eksekusi serial untuk satu halaman PDF
  • Dalam mode batch, Marker lebih cepat, dan di H100 throughput diperkirakan mencapai 25 pages/second
  • Untuk akurasi tertinggi, LLM dapat digunakan bersama melalui flag --use_llm
    • Menggabungkan tabel yang melewati batas halaman
    • Memproses matematika inline
    • Meningkatkan pemformatan tabel
    • Mengekstrak nilai dari formulir
  • Mode hybrid LLM memiliki akurasi benchmark tabel yang lebih tinggi dibanding Marker saja atau Gemini Flash saja

Instalasi dan Penggunaan Dasar

  • Membutuhkan Python 3.10+ dan PyTorch
  • Instalasi yang berfokus pada PDF: 
    pip install marker-pdf
  • Untuk memproses format dokumen selain PDF, instal dependensi tambahan 
    pip install marker-pdf[full]
  • Konversi satu file: 
    marker_single /path/to/file.pdf
  • Konversi banyak file per folder: 
    marker /path/to/input/folder
  • Konversi di beberapa GPU: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES adalah jumlah GPU yang digunakan dan harus 2 atau lebih
    • NUM_WORKERS adalah jumlah proses paralel per GPU

Opsi CLI Utama

  • --page_range TEXT: menentukan nomor dan rentang halaman yang akan diproses
  • --output_format [markdown|json|html|chunks]: menentukan format output
  • --output_dir PATH: menentukan direktori penyimpanan file output
  • --paginate_output: menyisipkan nomor halaman dan garis pemisah dalam output
  • --use_llm: meningkatkan akurasi dengan LLM
  • --force_ocr: memaksa OCR pada seluruh dokumen dan juga memformat matematika inline dengan benar
  • --block_correction_prompt: menentukan prompt untuk mengoreksi output Marker dalam mode LLM
  • --strip_existing_ocr: menghapus teks OCR yang sudah ada dan melakukan OCR ulang dengan surya
  • --redo_inline_math: meningkatkan kualitas konversi matematika inline bersama --use_llm
  • --disable_image_extraction: tidak mengekstrak gambar dari PDF
  • --converter_cls: memilih marker.converters.pdf.PdfConverter default atau marker.converters.table.TableConverter khusus tabel
  • --llm_service: menentukan layanan LLM saat memakai --use_llm; default-nya marker.services.gemini.GoogleGeminiService
  • --workers: menentukan jumlah worker konversi bersamaan
    • Menggunakan maksimal 5GB VRAM per worker, rata-rata 3,5GB VRAM

Python API dan Manipulasi Blok Internal

  • Dapat dikonversi langsung dari Python dengan PdfConverter 
    from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)
  • rendered untuk output Markdown memiliki atribut markdown, metadata, dan images
  • rendered untuk output JSON memiliki children, block_type, dan metadata
  • ConfigParser dapat digunakan untuk mengonfigurasi format output, processor, renderer, layanan LLM, dan lainnya
  • Dokumen tersusun sebagai tree halaman dan blok; halaman juga dapat berisi blok lagi
  • Dengan contained_blocks, blok tertentu seperti formulir dapat diekstrak secara programatis

Jenis Converter

  • PdfConverter: converter default untuk mengonversi PDF secara menyeluruh
  • TableConverter: hanya mengekstrak dan mengonversi tabel
    • Jika force_layout_block=Table ditentukan, deteksi layout dilewati dan semua halaman diasumsikan sebagai tabel
    • Jika memakai output_format=json, bounding box sel juga bisa diperoleh
  • OCRConverter: hanya menjalankan OCR
    • Jika --keep_chars disetel, karakter individual dan bounding box dipertahankan
  • ExtractionConverter: converter ekstraksi terstruktur berstatus beta
    • Perlu konfigurasi layanan LLM terlebih dahulu
    • Mengembalikan nilai ekstraksi dalam output JSON
    • Jika original_markdown dari eksekusi sebelumnya diteruskan sebagai existing_markdown, reparsing dokumen dapat dilewati

Format Output

  • Output Markdown:
    • Tautan gambar
    • Tabel terformat
    • Rumus LaTeX yang diapit $$
    • Blok kode triple backticks
    • Superscript untuk catatan kaki
  • Output HTML:
    • Gambar dengan tag img
    • Rumus dengan tag <math>
    • Kode dengan tag pre
  • Output JSON:
    • Halaman direpresentasikan sebagai list, dan tiap halaman adalah blok dalam skema internal Marker
    • Memiliki key id, block_type, html, polygon, children
    • Blok anak memiliki tambahan section_hierarchy dan images
    • Struktur blok berbentuk tree
  • Output Chunks:
    • Mirip JSON, tetapi semuanya diratakan menjadi satu list
    • Dengan menyertakan HTML penuh tiap blok, output ini dapat digunakan secara fleksibel untuk chunking RAG
  • Semua format output mengembalikan metadata
    • table_of_contents, yaitu daftar isi PDF yang dihitung
    • page_stats, yang berisi metode ekstraksi teks per halaman dan jumlah blok

Layanan LLM yang Didukung

  • Layanan yang dapat dipilih saat memakai --use_llm:
    • Gemini: secara default memakai Gemini developer API dan membutuhkan --gemini_api_key
    • Google Vertex: membutuhkan --vertex_project_id dan menentukan marker.services.vertex.GoogleVertexService
    • Ollama: memakai model lokal dan mengatur --ollama_base_url, --ollama_model
    • Claude: mengatur --claude_api_key, --claude_model_name
    • OpenAI: mendukung endpoint kompatibel OpenAI dan mengatur --openai_api_key, --openai_model, --openai_base_url
    • Azure OpenAI: mengatur --azure_endpoint, --azure_api_key, --deployment_name

Struktur Internal dan Titik Ekstensi

  • Marker berjalan sebagai pipeline model deep learning
    • Ekstraksi teks, melakukan OCR jika perlu
    • Deteksi layout halaman dan deteksi urutan baca
    • Pembersihan dan pemformatan tiap blok
    • Peningkatan kualitas dengan LLM jika perlu
    • Penggabungan blok dan post-processing teks keseluruhan
  • Tahap terkait OCR dan layout memakai surya
  • Untuk formatting terkait rumus, digunakan texify
  • Komponen utama:
    • Providers: menyediakan informasi dari file sumber seperti PDF
    • Builders: membuat blok dokumen awal dan mengisi teks
    • Processors: memproses blok tertentu, seperti formatter tabel
    • Renderers: merender blok ke format output
    • Schema: class untuk semua tipe blok
    • Converters: menjalankan pipeline end-to-end secara menyeluruh
  • Untuk mengubah perilaku pemrosesan, definisikan ulang processors
  • Format output baru ditambahkan dengan menulis renderer baru
  • Format input baru ditambahkan dengan menulis provider baru

Server API dan Deployment

  • Server FastAPI sederhana dapat dijalankan 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • Server dapat diakses di localhost:8001, dan opsi endpoint dapat dilihat di localhost:8001/docs
  • Server API ini bukan API yang robust dan hanya ditujukan untuk penggunaan skala kecil
  • Jika membutuhkan opsi konversi yang lebih robust, gunakan Datalab API yang di-hosting
  • Contoh deployment mencakup deployment web endpoint melalui Modal

Pemecahan Masalah

  • Jika ada masalah akurasi, gunakan LLM dengan --use_llm
    • Dalam kasus ini, Gemini API key harus disetel sebagai GOOGLE_API_KEY
  • Jika terlihat teks rusak, lakukan OCR ulang pada dokumen dengan force_ocr
  • Device torch yang digunakan dapat dipaksa dengan TORCH_DEVICE
  • Jika terjadi error kehabisan memori, kurangi jumlah worker atau pecah PDF panjang menjadi beberapa file
  • Opsi debug menyimpan gambar halaman yang berisi layout dan teks yang terdeteksi, serta file JSON berisi informasi bounding box

Hasil Benchmark

  • Benchmark konversi PDF penuh memakai benchmark set yang dibuat dengan mengekstrak satu halaman PDF dari common crawl
  • Skor dihitung dengan heuristik yang menyelaraskan segmen teks ground truth serta metode LLM-as-judge
  • Hasil konversi PDF penuh:
    • marker: waktu rata-rata 2,83837, heuristik 95,6709, LLM 4,23916
    • llamaparse: waktu rata-rata 23,348, heuristik 84,2442, LLM 3,97619
    • mathpix: waktu rata-rata 6,36223, heuristik 86,4281, LLM 4,15626
    • docling: waktu rata-rata 3,69949, heuristik 86,7073, LLM 3,70429
  • marker dan docling dijalankan di H100, sedangkan llamaparse dan mathpix memakai layanan cloud
  • Benchmark throughput PDF panjang memakai Think Python
    • marker: 0,18 detik per halaman
    • 43,42 detik per dokumen
    • VRAM 3,17GB
    • Karena 22 proses individual dapat dijalankan di H100, throughput diperkirakan mencapai 122 pages/second
  • Benchmark konversi tabel membandingkan representasi HTML dari test split FinTabNet
    • marker: skor rata-rata 0,816, total 99 tabel
    • marker w/use_llm: skor rata-rata 0,907, total 99 tabel
    • gemini: skor rata-rata 0,829, total 99 tabel
  • Tabel yang tidak dapat disejajarkan dengan ground truth karena perbedaan cara deteksi antara FinTabNet dan model layout difilter

Keterbatasan dan Lisensi

  • PDF adalah format yang sulit ditangani, sehingga Marker tidak selalu bekerja sempurna
  • Keterbatasan yang diketahui:
    • Layout yang sangat kompleks dengan tabel dan formulir bersarang mungkin tidak berfungsi
    • Rendering formulir mungkin tidak berjalan baik
  • Sebagian besar masalah ini dapat diatasi dengan meneruskan flag --use_llm dan --force_ocr
  • Bobot model memakai lisensi AI Pubs OpenRAIL-M yang dimodifikasi
    • Gratis untuk riset, penggunaan pribadi, dan startup dengan funding/revenue di bawah $2M
  • Kode berlisensi GPL
  • Lisensi komersial yang lebih luas atau penghapusan persyaratan GPL tersedia melalui pricing page

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-02
Komentar Hacker News

  • Cara repo ini membandingkannya dengan Nougat secara keseluruhan agak membingungkan
    Nougat adalah model yang dilatih khusus untuk dokumen akademik, dan menurut saya tidak pernah diklaim sebagai model OCR terbaik. Di benchmark juga tertulis bahwa untuk dokumen arXiv, akurasi Nougat lebih tinggi. Selain itu, marker disebut mengonversi rumus lebih sedikit daripada Nougat, jadi membandingkan kecepatannya dengan Nougat juga terasa agak kurang pas karena Nougat memang model untuk dokumen akademik
    Jika ingin OCR PDF yang berisi matematika, Nougat sangat layak dicoba. Mudah dipasang sebagai paket Python, dan dengan satu perintah bisa mengekstrak rumus, teks, tabel, dan lain-lain ke file .mmd. Untuk penggunaan pribadi, kecepatannya juga cukup baik; di laptop i5 berusia 4 tahun, butuh sekitar 30 detik untuk mengonversi dokumen 6 halaman hanya dengan CPU

    • Membandingkan dua hal bukan berarti yang lama sedang dipromosikan sebagai yang terbaik
      Itu hanya cara untuk melihat alat baru berdampingan dengan pembanding yang sudah dikenal. Seperti yang Anda katakan, Nougat mudah dipasang dan dijalankan, jadi wajar dijadikan pembanding. Tentu akan lebih baik dan berguna jika perbandingannya juga mencakup lebih banyak library
    • Saya penasaran seberapa baik Nougat menangani PDF buku aturan RPG
      Saya sedang mencari model OCR yang bisa membantu memindahkan sebagian buku RPG ke Markdown. Kalau bisa, penekanan seperti tebal atau miring juga ikut dipertahankan
      Kombinasi teks, angka, dan simbol matematika tampak mirip dengan dokumen teknis/akademik, tetapi sering bercampur dengan format aneh, kotak teks di margin, dan banyak diagram
    • Saya penulisnya. Use case saya adalah konversi massal PDF sains, jadi Nougat adalah solusi terbaik, dan karena itu saya menjadikannya pembanding utama
      Di bagian bawah juga saya bandingkan dengan ekstraksi teks sederhana. Nougat adalah model yang hebat dan mengonversi banyak PDF dengan baik, tetapi saya ingin sesuatu yang lebih cepat dan lebih mudah digeneralisasi
    • Saya ingin mengekstrak laporan keuangan dalam bentuk tabel di dalam PDF; apakah Nougat cocok juga untuk kegunaan seperti itu?

  • Dampak alat seperti ini jangan diremehkan. Ini soal membuka begitu banyak pengetahuan yang terkunci dalam format yang “bagus untuk dibaca, buruk untuk didistribusikan”
    Sangat menjanjikan. Akan bagus jika ada pipeline: semua PDF → konversi semuanya ke Markdown → simpan semuanya di archive.org

    • Untuk tujuan pengarsipan, pipeline itu tampaknya kurang tepat. Urutan yang lebih baik adalah semua PDF → simpan dokumen asli → konversi ke Markdown
      Dengan begitu, setiap kali bug diperbaiki atau ada peningkatan, proses konversi bisa dijalankan ulang. Dalam preservasi arsip, umumnya lebih disukai menyimpan materi sedekat mungkin dengan bentuk aslinya, karena setiap konversi setelahnya hanya berpotensi menimbulkan kehilangan data
    • PDF sebenarnya format yang sangat baik untuk distribusi
      Anda bisa menyisipkan data mentah yang dipakai untuk membuat dokumen yang dilihat pengguna akhir dalam format apa pun tanpa terlihat. Misalnya, jika membuat PDF dengan merender HTML memakai PrinceXML, Anda bisa memasukkan JSON asli yang digunakan untuk menghasilkan semua teks, grafik, bagan, dan sebagainya ke dalam PDF. Tentu kebanyakan orang tidak benar-benar melakukannya, tetapi itu bukan kesalahan spesifikasinya
    • Saya penulisnya. Itu memang salah satu alasan saya membuat alat ini
      https://github.com/VikParuchuri/libgen_to_txt juga layak dilihat. Itu belum saya integrasikan dengan marker, dan saat ini masih memakai ekstraksi teks sederhana
    • Ada permintaan yang sangat besar untuk alat seperti ini. Terutama di organisasi besar yang punya banyak dokumen PDF dengan bentuk beragam, minatnya pasti tinggi
      Bahkan jika hanya menangani sebagian kebutuhan atau use case, alat seperti ini akan sangat berguna bila benar-benar bekerja dengan baik
    • Ini juga sangat berguna dari sisi aksesibilitas
      Membuat aksesibilitas PDF benar-benar sesuai standar itu pekerjaan besar, dan bahkan jika sudah sesuai pun, besar kemungkinan penampil PDF yang dipakai pengguna tidak mendukung standar yang diperlukan

  • Sepertinya saya harus mencobanya sendiri akhir pekan ini
    Saya sering menyalin ulang secara manual scan PDF RPG dari sumber tak jelas yang tidak punya teks yang bisa dipilih karena belum di-OCR, atau kalau pun sudah, kualitasnya buruk
    Kadang benar-benar lebih cepat mengetik ulang dari nol daripada memperbaiki kesalahan copy-paste atau mengoreksi hasil OCR yang sudah dijadikan teks
    Bahkan PDF resmi pun formatnya sering rusak, sehingga ada spasi ganda/tiga atau tab di antara kata-kata. Kalau ini bisa dipakai dengan baik, sepertinya akan sangat menghemat waktu

    • Saya juga memikirkan use case ini. Saya sudah mencoba dengan satu buku, tetapi hasilnya tidak terlalu bagus
      Banyak tabel dan kotak teks yang rusak. Saya mendapat hasil yang lumayan baik dengan mengambil screenshot tabel lalu menempelkannya ke ChatGPT untuk mengubahnya menjadi tabel Markdown. Dengan sedikit prompt seperti “baca per baris. Header kolomnya X, Y, Z. X adalah teks, Y angka, Z kata”, tabel yang tidak beraturan pun bisa ditangani
    • Banyak materi terkait RPG yang tidak pernah terbit dalam media fisik, dan menjadi yatim secara hak kekayaan intelektual, jadi saya langsung memikirkan hal itu

  • Akhir-akhir ini, seberapa bagus Tesseract OCR? Saat saya mencobanya dulu, hasilnya jauh di bawah OCR online dari AWS, Azure, dan GCP

    • Ada cukup banyak pembaruan baru-baru ini, dan di git disebutkan Tesseract 5 sebagai dependensi. Kemungkinan besar hasilnya sudah jauh lebih baik dibanding saat terakhir saya mencobanya
      https://github.com/tesseract-ocr/tesseract/releases
      Pada akhirnya sepertinya tergantung use case. Untuk pekerjaan pribadi seperti ini, kemungkinan besar sudah memadai, dan tidak perlu data pengguna atau kartu kredit juga
    • Ternyata cukup hebat, dan performanya di dalam browser juga mengesankan
      Hanya saja sangat sensitif terhadap resolusi. Begitu ukuran gambar turun di bawah titik tertentu, meski masih cukup terbaca oleh manusia, output Tesseract jadi berantakan
    • Butuh cukup banyak prapemrosesan. Saya hanya pernah memakai solusi GCP, dan menurut pengalaman saya yang itu lebih baik
    • Saya memakainya belum lama ini, dan tetap gagal bahkan pada gambar yang sangat dasar
      Saya juga mencoba iOS Vision API, tetapi tetap gagal. Kasus uji saya adalah foto halaman buku yang diambil dengan jelas

  • Pertanyaan untuk penulis: mengapa Markdown? Bagian sulit dari alat ini tampaknya adalah mem-parsing PDF dengan akurasi tinggi, bukan format ekspor setelahnya.
    Jadi akan bagus jika pengguna bisa memilih format keluaran. Jika ada parser PDF berakurasi tinggi, saya ingin memakainya untuk membuat EPUB

    • Sejenis markup tetap diperlukan untuk mempertahankan markup struktural sebanyak mungkin.
      Saya mengelola ebook di penerbit universitas, dan ada banyak daftar lama yang menunggu dikonversi, sementara cukup banyak di antaranya hanya tersisa sebagai pindaian halaman dari edisi cetak lama. Untuk menyediakannya sebagai EPUB, kita perlu tahu di mana letak pembagian bab, judul, tabel, bagan, rumus, kutipan, dan sebagainya. Vendor outsourcing bisa mengerjakannya, tetapi untuk beberapa buku biaya konversinya lebih besar daripada pendapatan penjualannya. Akan bagus jika setidaknya sebagian bisa kami kerjakan sendiri
    • Saya setuju bahwa format perantara sebaiknya mendekati teks biasa yang secara opsional bisa dikonversi ke format lain.
      Hanya saja di sini Markdown tampaknya dipakai sebagai format perantara. Ia dekat dengan teks biasa, tetapi masih bisa mempertahankan informasi tata letak sederhana. Dalam praktiknya, saya kemungkinan akan mengambil keluaran Markdown lalu menghubungkannya ke alat yang mengubahnya ke format keluaran akhir yang saya inginkan
    • Alasan memilih Markdown adalah karena saya ingin mempertahankan rumus, tabel, informasi tebal/miring, dan judul.
      Rumus bisa dibungkus dengan $/$$. Saya belum melihat keluaran EPUB, tetapi karena kebutuhan seperti inilah teks biasa dikesampingkan

  • Ada satu kasus penggunaan yang agak unik yang saya masih belum temukan solusi bagusnya: membaca dokumen konstruksi.
    Gambar kerja selalu datang dalam bentuk PDF, padahal hasilnya jauh lebih baik saat mem-parsing file DXF(AutoCAD). Tetapi bahkan jika saya adalah kontraktor umum penanggung jawab lapangan, tidak selalu mudah meminta arsitek mengirimkan file DXF

  • Saya biasanya membaca tulisan panjang dengan pembaca ebook.
    PDF, terutama dengan tata letak multi-kolom, nyaris seperti mimpi buruk di Amazon Kindle atau Pocketbook dengan fitur bawaannya. Alat ini tampaknya bisa cukup meningkatkan pengalaman membaca

  • Kerja yang bagus.
    Saya penasaran dari mana asal halusinasi yang terlihat pada keluaran Nougat. Jika Anda menelusuri keluaran Nougat untuk contoh Think Python, Anda akan mengerti maksud saya.
    Setelah saya lihat lagi, tertulis bahwa ia melewati LLM, jadi halusinasi memang sesuatu yang bisa diduga

    • Saya rasa alat seperti ini berbahaya sampai tingkat halusinasi pada teks atau pemformatannya lebih rendah daripada tingkat kesalahan ketika pembaca yang teliti membaca ulang dokumen berkali-kali.
      Tingkat itu nyaris mendekati 0, dan tergantung penggunaannya mungkin benar-benar harus 0. Jika isi dokumen yang akurat tidak penting, mungkin umumnya tidak masalah, tetapi saya rasa jarang ada begitu banyak dokumen yang tidak penting bagi siapa pun sekarang maupun nanti, namun tetap perlu lebih mudah diakses daripada PDF

  • Ini tampak seperti alat yang mungkin membantu memindahkan catatan saya dari OneNote

  • Cukup menarik. Mungkin bagus jika menambahkan beberapa contoh sebelum dan sesudah konversi di repo.
    Saya penasaran jenis PDF seperti apa yang sedang disesuaikan. Bagaimana penanganan anotasi tulisan tangan?