PDF’yi Metne Dönüştürmek Zor Bir Sorun

 (marginalia.nu)
4 puan yazan GN⁺ 2025-05-15 | 1 yorum | WhatsApp'ta paylaş
  • Arama motoruna PDF indeksleme eklendi, ancak PDF’lerden aramada kullanılabilecek yapılandırılmış metin elde etmek, HTML işlemeye kıyasla çok daha zorlu
  • PDF, bir metin belgesinden çok koordinat tabanlı bir grafik biçimine daha yakın; bu yüzden glifler döndürülmüş, üst üste binmiş veya sıraları karışmış halde yerleştirilebiliyor
  • PDFBox’ın PDFTextStripper aracı bir başlangıç noktası olabilir, ancak başlık ve paragraf gibi anlamsal yapıları yeterince koruyamadığı için arama ilgililiğini değerlendirmede sınırlamalar yaratıyor
  • Başlıklarla paragrafları ayırmak için belge geneli yerine sayfa bazlı yazı tipi boyutu istatistikleri ve satır aralığı medyanı gibi sezgisel yöntemler daha kullanışlı
  • Kusursuz PDF metin çıkarımı zor olduğundan, arama motoru için başlık, özet ve gövde yapısını istikrarlı biçimde elde eden yeterince iyi bir çözüm daha gerçekçi bir hedef

PDF indeksleme eklenirken ortaya çıkan sorun

  • Arama motoru artık PDF dosya biçimini indeksleyebiliyor ve değişiklikler birkaç ay boyunca dağıtıma çıkacak
  • Arama motoru açısından temiz HTML en kolay işlenen biçim, ancak PDF aynı düzeyde yapılandırılmış metni doğrudan sunmuyor
  • Dışarıdan metin görünse bile, PDF içinde aranabilir cümleleri ve paragrafları geri oluşturmak neredeyse ayrı bir problem

PDF neden metin çıkarmayı zorlaştırıyor

  • PDF, tipik bir metin biçimi değil; daha çok grafik biçimine yakın
  • İç temsili, cümle veya paragraflardan çok “kâğıt” üzerindeki koordinatlara gliflerin yerleştirilmesine benziyor
  • Glifler şu durumlarda olabilir
    • döndürülmüş
    • birbirinin üstüne binmiş
    • okuma sırasından farklı konumlandırılmış
    • iliştirilmiş anlamsal bilgisi çok az
  • PDF görüntüleyicisinde ya da tarayıcıda ctrl+f ile arama yapılabilmesi başlı başına oldukça etkileyici
  • Görüntü tabanlı makine öğrenimi modelleri şu anda iyi bir yaklaşım olabilir, ancak GPU’suz tek bir sunucuda yüzlerce GB PDF işlenecek ölçekte uygun değil

PDFBox ile başlanabilir ama yeterli değil

  • Bu tamamen keşfedilmemiş bir alan değil; PDFBox içindeki PDFTextStripper sınıfı başlangıç noktası olabilir
  • PDFTextStripper, PDF’lerden metin çıkarıyor, ama adından da anlaşılacağı gibi odak noktası metni “soyup almak”
  • Arama motorları için başlık gibi anlamsal bilgiler önemli bir ilgililik sinyali, ancak temel çıkarım sonucu tek başına bu tür yapıları yeterince vermiyor

Başlık bulmak için sezgisel yöntemler

  • En basit başlık tespiti, diğer metinden ayrılmış semibold ya da daha kalın satırları bulmak
  • Ancak her başlık kalın yazılmıyor; birçok belge başlıkları yazı tipi boyutuyla ayırıyor
  • Küresel yazı tipi boyutu eşikleri belgeler arasında tutarsızlık gösterebiliyor
    • bir belgede gövde metni 10pt, başlık 16pt olabilir
    • başka bir belgede gövde metni 14pt, başlık 20pt olabilir
  • Belge genelinden çok sayfa bazlı istatistikler daha uygun olabiliyor
    • ilk sayfa, özet ve yazar listesi nedeniyle diğer sayfalardan çok farklı yazı tipi seçimleri içerebilir
    • örnek belgede belge başlığında 17 punto, sonraki başlıklarda ise 14 punto yazı tipi kullanılıyor
  • Her sayfada genellikle gövde metnine karşılık gelen baskın bir yazı tipi boyutu bulunuyor
  • Sayfa bazlı medyan yazı tipi boyutuna yaklaşık %20’lik bir katsayı eklemek, başlıkları oldukça istikrarlı biçimde belirleyebiliyor
  • İstisnalar kalsa da, önemli vakaların çoğu yakalanabiliyor

Çok satırlı başlıkları tek parça haline getirmek

  • Başlıklar biçimlendirme nedeniyle sık sık birden fazla satıra bölünüyor; bu yüzden art arda gelen başlık satırlarını bazen birleştirmek gerekiyor
  • Ne zaman birleştirileceğine karar vermek basit değil
  • Örnekte şu koşullar birlikte görülüyor
    • iki satırlı bir başlık
    • sağa hizalı bir başlık
    • başlığın ardından gelen semibold yazar adı
    • birkaç satır aşağıda yer alan kalın olmayan bir başlık
  • Girinti paragraf ayrımı için de sinyal olarak kullanıldığından, sağa hizalı başlıklar kararı daha da zorlaştırıyor
  • Aynı yazı tipi boyutu ve kalınlığa sahip ardışık başlıkları birleştirme yaklaşımı genel olarak iyi çalışıyor, ancak istenmeyen sonuçlar da üretebiliyor

Paragraf tanımada satır aralığının yarattığı tuzaklar

  • PDFTextStripper, paragraf tanımlamayı oldukça iyi yapıyor
  • Satır aralığı ve girintiye birlikte bakarak paragrafın nerede bölüneceğine karar veriyor
  • Özellikle satır aralığı mantığında geliştirme payı var
  • PDFTextStripper’ın büyük sorunu, satır ayrımı için sabit bir eşik kullanması
    • satırlar arası boşluk eşikten büyükse, aynı paragraf olmadığına karar veriyor
    • belgeler arasındaki satır aralığı farklarını yeterince hesaba katmıyor
  • Akademik taslaklarda ve preprint’lerde 1,5–2 kat satır aralığı oldukça yaygın
  • Eşik çok yüksek seçilirse bazı başlıklar gövde paragraflarına karışarak başlık tespitini bozabiliyor

Satır aralığı istatistikleriyle düzeltme

  • Yazı tipi boyutu işlemeye benzer şekilde, satırlar arasındaki mesafeye de istatistiksel teknikler uygulanabiliyor
  • Metin sayfasında satırlar arası mesafe histogramı oluşturulunca, büyük aykırı değerler çıkma eğiliminde oluyor
  • Ortalama aykırı değerlerden kolay etkilenirken, medyan bazen gövde metninde kullanılan satır aralığıyla tam olarak örtüşebiliyor
  • Medyana belirli bir katsayı eklenirse, farklı satır aralıklarında da dayanıklı bir paragraf ayırma sezgisi kurulabiliyor

Gerçekçi hedef mükemmellik değil, istikrar

  • PDF’den metin çıkarma işi kusursuz hale getirilmesi zor bir alan
  • PDF biçimi zaten bu iş için tasarlanmadı ve “yeterince iyi” bir çözüm seçerken çeşitli ödünleşimler ortaya çıkıyor
  • Arama motorunun özellikle ilgilendiği bilgiler şunlar
    • başlık gibi ilgililik sinyalleri
    • özetin tespiti
    • kalan metnin bir ölçüde tutarlı yapısı
  • Bu hedeflerle, ilgili belgelerin çoğunu nispeten sorunsuz işleyen bir çözüme yaklaşmak mümkün

Kullanılan örnek metinler

  • 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

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-15
Hacker News yorumları

  • Bazen aylarca, yıllarca derinlemesine uğraşıp uzman seviyesine geldiğim bir şeyi tamamen unutuyorum; sonra da ileride “Bu yeni ve ilginçmiş” diye hissediyorum
    Oldukça ilginç işler yapmış olsam da hafızadan siliniyor; bir şey tetikleyene kadar kendimi hayata yeniden başlayan biri gibi hissediyorum
    6–7 yıl kadar önce PDF ve OCR ile epey havalı bir şeyler yaptığımı belli belirsiz hatırlıyorum; bakınca bunun Tesseract olduğunu düşünüyorum

    • 2006 civarında iRex adlı erken dönem bir e-kitap cihazında çok sütunlu bilimsel makalelerden metin kopyalanamamasının nedenini araştırmıştım; PDF okuyucu içeride Poppler kullanıyordu, ben de Tesseract yazarı Thomas Breuel’in sunduğu OCR algoritmasından yararlanıp çok sütunlu belgelerin okuma sırasını çıkarsayacak şekilde Poppler’ı değiştirmiştim
      Bu daha çok sezgisel bir hack’ti ve o dönemde Poppler’ın eski API’si metin akışlarını erişilebilirlik API’lerine uygun biçimde ifade etmiyordu sanırım
      Çok sütunlu seçim özelliği bir ölçüde eklendi, ama sonradan performans iyileştirme önerilerini kabul ettirmek zordu; çünkü sezgiseller biraz farklı olduğundan bazı durumlarda seçim sonucu değişiyordu
      Zaten baştan tek bir “doğru cevap” yoktu; dolayısıyla sonuçların birebir aynı olmasını istemek anlamsızdı ve böylece kpdf’in çok sütunlu seçim özelliği bir seviyeye kadar oluştu
      Bugün böyle bir kullanım için Tesseract’ı doğrudan kullanmak muhtemelen daha mantıklı
    • Bu format yüzünden topluca yakıp tükettiğimiz on yıllar düzeyindeki insan emeğini geri getirmek mümkün değil
      Bu deliliğin ne zaman biteceğini bilmiyorum
    • Tesseract uzun süre en iyi açık kaynak OCR’dı, ama artık docTR’ın daha iyi olduğunu düşünüyorum
      Varsayılan doğruluğu daha yüksek, GPU hızlandırması var ve birden fazla metin algılama/tanıma modeli mimarisini birleştirilebilen bir pipeline olarak sunuyor
      PyTorch veya TensorFlow ile eğitip ince ayar yaparak belirli alanlardaki performansı daha da yükseltebilirsiniz
    • Birisi C++ hakkında soru sorduğunda “C++ ile ciddi biçimde hiç çalışmadım” diye cevap verip, sonra yaklaşık 20 yıl önce Borland C++ ile binlerce kişinin kullandığı özel bir mesajlaşma istemcisinin kodunu yazdığımı hatırladığım olmuştu
      Yani gerçekten böyle şeyler oluyor
    • Her proje bittiğinde sık sık “Artık bunda uzman oldum. Ama muhtemelen bir daha asla yapmam” diye hissediyorum
      Sonraki iş tamamen başka bir alanda oluyor, ben de yine temelden başlıyorum

  • Keşke biri PDF’ler için tarayıcı geliştirici araçları gibi bir şey yapsa
    “Ögeyi incele” benzeri şekilde PDF’nin içerik akışını kaynak olarak görebilsek ve BT … ET metin operatörlerinin ya da Tj metin yerleştirme operatörlerinin her pikseli nasıl belirleyip ürettiğini inceleyebilsek harika olurdu
    Bu, güncel akımda olduğu gibi görsel modellerin PDF’ye insan gibi “bakıp” okumasının tersi; ama PDF dosyasının içinde gerçekten ne olduğunu anlayabilmek çok daha iyi olurdu
    PDF içeriğini inceleyen birkaç araç var (https://news.ycombinator.com/item?id=41379101), ama bunlar PDF nesnesi seviyesinde duruyor ve tüm içerik akışı tek bir nesne gibi görünüyor
    Örneğin yazıda anılan https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2... bağlantısındaki PDF’nin 6. sayfası, belge içindeki 8. PDF sayfasında, BT, yazı tipi ayarları, Td, TJ gibi operatörlerle metni yerleştiriyor
    Böyle bir “kaynağı” ve render edilmiş PDF’yi yan yana görüp bir tarafta fareyi gezdirince diğer taraftaki karşılık gelen alanın vurgulanması sağlansa, HTML sayfalarında olduğu gibi hata ayıklamak mümkün olurdu

    • PDF’yi Mozilla’nın PDF.js ile DOM’a render ederseniz buna oldukça yakın bir sonuç elde edilebilir
      Örneğin her Tj tek bir DOM ögesi olur, TJ ise birden fazla ögenin grubu gibi davranır
      Çalışabilmesi için özgün belgeyi doğru yansıtması gerekir; bu yüzden oldukça sadık bir dönüşüm olabilir
    • cpdf ile bir ölçüde yapılabiliyor
      cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json ile JSON üretebilir, sonra o JSON’u düzenleyip cpdf -j out.json -o out.pdf ile yeniden PDF’ye dönebilirsiniz
      Ama gerçek zamanlı çift yönlü bağlantı yok
    • Muhtemelen açık kaynak ya da ücretsiz bir şey kastediliyordu ama birkaç yıl önce kullandığım Acrobat Pro da neredeyse buna benzer bir özelliğe sahipti
      Yalnız sayfayı incelemek yerine içerik ağacında gezinme şeklindeydi ve sayfadaki nesneleri vurguluyordu
      Komut düzeyine kadar inmiyordu; yalnızca nesne veya akış seviyesine kadar gidiyordu
    • Bu notebook tam olarak istenen şey değil ama PDF içindeki çeşitli çizim işlemlerini “gerçek zamanlı” olarak inceleme imkânı veriyor
      https://observablehq.com/@player1537/pdf-utilities
    • Tensorlake’in yaptığı şey de bu kombinasyona yakın
      PDF’ye insan gibi “bakıp” yalnızca metni okumak yerine; tablo, görsel, metin, formül ve el yazısı dâhil içeriği anlamaya çalışıyorlar
      Bu yüzden PDF’yi parse edip birden çok modeli çalıştırarak Markdown parçaları veya JSON çıkarıyorlar; böylece gerçek veriler AI ajanlarına, LLM’lere ve diğer uygulamalara aktarılabiliyor
      https://tensorlake.ai

  • “PDF’yi metne dönüştürme” ifadesi fazla basitleştirilmiş
    Bu kategorinin içinde 1) arama indeksleme veya vektör DB girdisi için güvenilir OCR, 2) belirli değerleri çıkaran yapılandırılmış veri çıkarımı, 3) ipotek başvurusu otomasyonu gibi uçtan uca belge iş akışları var
    Marginalia’nın çözmeye çalıştığı şey 1 numaralı OCR ve Gemini Flash gibi modeller sayesinde hızla genelleşiyor
    Birçok şirketin mevcut OCR hattını Flash ile değiştirip maliyeti ciddi biçimde düşürdüğünü gördüm ve bu oldukça şaşırtıcı
    Ama 2 ve 3 çok daha zor; ham OCR çıktısından üretim ortamındaki görev açısından kritik belge iş akışlarına gitmek arasında hâlâ büyük bir boşluk var
    LLM’ler ve görsel dil modelleri sihir değil; %100 otomasyon beklerseniz şaşırırsınız
    Veri kümesi oluşturma ve etiketleme, sınıflandırma -> bölütleme -> çıkarım hattı orkestrasyonu, belirsizlik tespiti ve insan incelemesi, ince ayar gibi şeyler hâlâ gerekiyor
    Uzun vadede neredeyse tam otomasyona yaklaşabiliriz, ancak bu zaman ve emek gerektiriyor; yine de geleceğin bu yöne gittiği açık görünüyor
    Bununla ilgili olarak https://extend.ai adlı bir LLM belge işleme şirketi kurdum

    • Erişilebilirlik açısından 4 numara, yani farklı belge türleri genelinde çalışan güvenilir OCR ve anlamsal çıkarım da gerekli
      İş dünyasındaki iş akışları çoğu zaman birkaç sabit belgeyle uğraşır, ama genel amaçlı bir PDF okuyucu kullanıcının hangi belgeyi açacağını bilemez
      Sadece metni değil; tabloları, üstbilgi ve altbilgileri, dipnotları, başlıkları, matematik ifadelerini de tanıması gerekir
      İnsan tüketimi için olduğundan hataları en aza indirmek gerekir; bu yüzden gereksiz olduğunda OCR kullanılmamalı, PDF’ye gömülü temel metinden yararlanılırken anlamsal yapı da çıkarılmalıdır
      Sonuçta hem sadece görüntüden oluşan PDF’ler hem de içerik akışından bilgi alınabilen PDF’ler için iki ayrı yol gerekir
      Ancak içerik akışında gerçek ekrandakinden farklı metin bulunabilir. Beyaz yazıyla gizlenmiş bilgiler ya da Unicode aksanları yerine komutlarla aksan işareti çizen LaTeX tarzı uygulamalar gibi durumlar vardır
      Bu genellikle kullanıcının düşük performanslı cihazında yerel uygulama olarak çalışır ve sunucu ya da abonelik modeli olmayabilir; bu yüzden bulut yapay zeka modelleri de kullanılamaz
      Erişilebilirlik yazılımı kullanıcıları çıktıyı alıp kalemle doldurmakta zorlanabilir; bu nedenle yalnızca spesifikasyona uygun temiz formlar değil, baskı amaçlı formlar da işlenebilmelidir
      Bu, çözülmeye hiç de yakın olmayan açık bir problem; mevcut çözümlerin hepsi bir şekilde yetersiz ve yukarıdaki 5 unsurun tamamını gerçekten çözen tek bir çözüm yok
    • Görsel dil modelleri fazla kararsız olduğu için doğrudan araç geliştirmek zorunda kalmış biri olarak, işlenmemiş görüntüler üzerinde VLM kullanan şirketlerin ciddi sıkıntı yaşama ihtimali yüksek
      Görüntü etiketlemede çok iyiler ve tek sütunlu metin, ortalanmış tek seviyeli başlık, sayfa başına tek görsel veya tablo gibi basit belgelerde fena değiller
      MVP demolarının çoğu bu tür örnekleri gösteriyor
      Ama tablo ve görsellerin karıştığı karmaşık belgelerde, “kötü seviyede” bile olabilmesi için çok daha fazla parametre gerektiği hissi var
      Şu anda halüsinasyon o kadar fazla ki, üstte başlığı olan, ortasında veriler bulunan ve altta özeti olan basit bir tabloyu bile olduğu gibi kullanmak zor
    • PDF’yi Markdown’a dönüştürmek için sürekli ince ayar yapıyorum; orijinal yazıda olduğu gibi başlık algılama ve çeşitli sorunlarla karşılaşıyorum
      Günümüz OCR’ı mükemmel, ancak belgenin küresel yapısını korumak çok daha zor
      Büyük belgelerde tutarlı HTML elde etmek hâlâ uzak görünüyor; belge yapısını çıkarmak için LLM’yi birden fazla kez çalıştırıp bunu sayfa bazlı çıkarıma bağlam olarak vermekle Markdown tarafında bir ölçüde iyi sonuçlar alınabiliyor

  • Apple bu problemi yıllar boyunca oldukça başarılı biçimde ele aldı; temel püf noktası her şeyi geometrik yapı olarak görmek ve kümeleme analiziyle kelime aralıklarını harf aralıklarından ayırmaya çalışmaktı
    Birçok PDF’de çok iyi çalışıyor, ama PDF türleri o kadar çeşitli ki sonucun kötü olduğu durumlar her zaman var
    Bugün yeniden yapsam geometrik yapıyı korur, OCR’dan tamamen kaçınır ama makine öğrenimi kullanırdım
    Makine öğreniminin büyük avantajı, bilinen metinden PDF üreten mevcut araçlardan yararlanarak eğitim aşamasını tamamen otomatikleştirebilmek
    Bertrand Serlet’in bu özelliği WWDC 2009’da tanıttığı an: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • Daha iyi bir çözüm, PDF’nin içine düzenlenebilir kaynak belgeyi birlikte gömmektir
    LibreOffice’te bu kolayca yapılabiliyor ve iyi sıkıştırıldığı için genelde neredeyse hiç ek yer kaplamıyor
    Böylece metin ve anlam açısından çok daha iyi bilgi elde edilebilir ve mevcut PDF okuyucularında da sorunsuz çalışır

    • Doğru, ama bunun için PDF üreticisiyle tüketicisinin çıkarlarının örtüşmesi gerekir
      Elektronik delil keşfi alanında, delili sunan tarafın karşı tarafın avukatlarının içeriği tüketmesini zorlaştırmak için kasten PDF dökümü yapması yaygındır
      İki tarafın da çok parası varsa bu engel olmaz, ama örneğin baro tarafından atanan bir avukatın PDF’leri okunması kolay bir biçime dönüştürecek kişiyi tutacak bütçesi olmayabilir; bu da işlem süresini ciddi biçimde uzatır ve sanık üzerinde psikolojik yük oluşturur
      Hatta veriler doğru şekilde işlenemeyebilir bile
      Çözüm, bu tür davranışları yasa dışı hâle getirmektir
      Örneğin telefon dinleme verileri standartlaştırılmış makine tarafından okunabilir biçimde sağlanmalıdır; basit teknik sürtünmelerin ceza yargılamasının sonucunu etkilemesi için etik bir gerekçe yoktur
    • Mevcut PDF’lerden metin çıkarması gereken arama motoru problemi için daha iyi çözümün, PDF’nin nasıl yazılması gerektiğine dair tavsiye olması tuhaf
      Bu çözümün etkisini göstermesinin ne kadar süreceğini merak ediyorum
    • Doğru, ama kaynak belgenin render edilmiş PDF içeriğinden keyfi biçimde farklı olabilmesi gibi bir açık da yaratır
    • Problem alanının %90’ı muhtemelen eski PDF’ler
      Şirkette de bunlardan binlerce var; bazıları çok kötü taramalar, bazılarında Adobe OCR gömülü, ama çoğunda hiçbir şey yok
    • PDF’yi oluşturan kaynak belgeye erişebiliyorsanız bu iyi bir yöntem
      Ama genel olarak böyle bir kontrolünüz olmuyor

  • Aşağıdaki PDF aslında bir .txt dosyasıdır
    .pdf uzantısıyla kaydederseniz PDF görüntüleyicide açılabilir ve bir metin düzenleyiciyle de değiştirilebilir
    Örneğin bu metin dosyasını düzenleyerek PDF açıldığında ekranda gösterilen metni, yazı tipini, yazı boyutunu, satır aralığını, satır başına azami karakter sayısını, sayfa başına satır sayısını, kağıt genişliği ve yüksekliğini, hatta dikey-yatay yönünü bile değiştirebilirsiniz
    Örnek, %PDF-1.4 ile başlayan en minimal PDF yapısıdır ve Catalog, Pages, Font, Page, Contents, xref, trailer gibi bölümlerin doğrudan metin olarak yazıldığı bir biçimdedir

    • PDF içinde gömülü ikili akışlar da bulunabilir
      PDF, metin için değil yerleşim ve grafikler için tasarlanmıştır
      Örnek iyi olsa da, her satır karakter başına bir çağrı ya da kelime başına bir çağrı olacak şekilde parçalanabilir ve sıraları da karışabilir
    • “PDF”, “Portable Document Format” kısaltmasıdır
      PDF 1.0 referans belgesinin “2.3.2 Portability” bölümünde PDF dosyası 7 bitlik bir ASCII dosyası olarak tanımlanır; görüntüler ve özel karakterler içeren belgelerin bile yalnızca ASCII'nin yazdırılabilir alt kümesi kullanılarak ifade edildiği belirtilir
      Bunun sonucunda farklı donanım ve işletim sistemi ortamları arasında son derece taşınabilir olduğu açıklanır
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • Bu, PDF'in Hello World örneğine yakındır
      Günümüzde PDF'lerin çoğunda tüm nesneler deflate ile sıkıştırılmıştır
      Üstelik takip etmeyi daha da zorlaştırmak için birçok PDF, nesnelerin çoğunu nesne akışı türündeki nesnelerin içine toplar ve sonra yeniden sıkıştırır
      Bu yüzden 6 0 R sonunun izini sürmeye çalışsanız bile bir metin düzenleyicide 6 0 Obj diye arama yapamazsınız

  • Bu yazıda anlatılan zorlukları gösteren sevdiğim bir belge var: https://academic.oup.com/auk/article/126/4/717/5148354
    İlk sayfadan itibaren tipik iki sütunlu metin, ortalanmış bir başlık ve iki sütunun arasına girerek satır uzunluğunu ve girintiyi değiştiren bir metin kutusu bulunuyor
    Sonrasında tek ve çift sayfalarda değişen üstbilgiler, ayrıca ciddi ölçüde farklılaşan bölüm başlığı kuralları ortaya çıkıyor
    Daha kötüsü, paragraflar arasında ek boşluk yok ve ilk satır girintisi de her zaman bulunmuyor; yani akla gelebilecek her türlü zorluk var

    • macOS'un CoreGraphics PDF API'si varsayılan olarak sayfa bazında metni sözlükte kodlandığı sırayla veriyordu
      Bunun yaklaşık %95'lik kısmı gayet iyi çalışıyordu ve Mac'teki PDFKit ile Preview için yıllar boyunca bu yeterli oldu
      PDF'i üreten asıl uygulamayı, örneğin bir kelime işlemciyi düşünürseniz, büyük olasılıkla kendi metin tamponundan PDF bağlamına metni oldukça makul bir sırayla işliyordu
      Bu yüzden iki sütunlu belgelerde bile metin çoğu zaman sol sütundan sağ sütuna doğru düzgün akıyor ve PDF'in içine de zaten doğru sırayla yazılmış oluyordu
      Yine de sayfa altbilgisi veya üstbilgisinin PDF üreten uygulama tarafından bağlama hangi sırayla döküldüğünü bilmenin bir yolu yok

  • PDF'ten metin, hatta yapılandırılmış metin çıkarmak hiç kolay değildir
    Bir HTML belgesinden tablo kazımak, site her şeyi div ile yapma anti-pattern'ini kullansa bile çoğu zaman basittir; anlamlı öğeler kullanılıyorsa daha da kolaydır
    PDF böyle değildir
    Biçim uzmanı değilim, dolayısıyla anlam yapısı desteğinin ne kadar olduğunu bilmiyorum; ama render edildiğinde ancak tablo gibi görünen grafik ve metin öğelerinin gevşek bir toplamından oluşan çok sayıda PDF tablosu gördüm
    Pratikte, Poppler PDF araçlarıyla PDF'i HTML'e dönüştürdükten sonra beklenen tablo başlıklarını bulup her değerin x koordinatına göre sütunları hesaplayarak satır bazında değer çıkarmada epey başarılı oldum
    Kirli bir yöntem ama ihtiyaç duyduğum kullanım için güvenilir biçimde çalıştı ve düzensiz aralıklı ya da satır ortasında satır sonu barındıran biçimlendirilmiş düz metinden çok daha iyiydi

    • Tıpkı bir web sayfasında BeautifulSoup kullanır gibi PDF'ten veri çıkaramıyor olmak can sıkıcı olduğundan, buna bir ölçüde benzeyen işler yapan bir kütüphane yazdım
      Çeşitli yan işlevleri var ama temel hedef, page.find('text:bold:contains("Summary").below().extract_text() gibi daha insansı bir şekilde etkileşim kurmak
      Her PDF kendine özgü bir kâbus olduğu için, çıkarması zor örnekleri toplayıp bir yöntem kütüphanesinin temeli haline getirmeye çalışıyorum
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • Resmî devlet belgeleri içinde en sevdiğim örnekler, render edilen metinle yaygın yöntemlerle çıkarıldığında elde edilen metnin tamamen farklı olduğu durumlar
    • Bir gün veri düzenleme yazılımımda PDF'ten tablo verisi çıkarma özelliği olmasını umuyorum
      C++ uygulamasına entegre edilebilen ve ücretsiz olan ya da birkaç yüz doların altında kalan bir PDF tablo çıkarma kütüphanesi bilen varsa duymak isterim
    • PDF özünde bir işaretleme/XML biçimidir ve standardı da açıktır, yani öğrenilebilir
      Aynı PDF'i üretmenin gerçekten çok sayıda yolu vardır
      Bazı araçlar, grafik düzenleyicide metin ve grafik içeren bir yerleşimi dışa aktarmaya daha yakındır; bazılarıysa kelimelerin önce geldiği, kelime işlemci benzeri metin ve grafikleri dışa aktarmaya daha yakındır
      Üreten uygulamanın bilgiyi ele alış biçimi, PDF çıktısının nasıl oluşacağını da sık sık etkiler
      Hazır bir yardımcı araç arıyorsanız, cisdem gibi araçlar yerel kullanıcılar için yapılandırılmış veriyi oldukça iyi çıkarmaya kadar bu sorunu belli ölçüde çözmüş durumda
      Bu tür araç çok ve birçoğu yapılandırılmış veri desteği vadeder, ancak yapmayı düşündüğünüz işle iyi uyuşması gerekir

  • PDF bir gösterim biçimidir
    İnsan gözüne ve yazıcılara göre optimize edilmiştir ve özellikleri zamanla giderek artmıştır
    Makineler arası veri aktarım aracı olarak berbat olsa da, insanların okuması veya bir A4 sayfasını saklamak için son derece iyidir
    .pdf metni saklıyor diye o metni almak istediğiniz varsayımıyla başlarsanız, bu kabaca "gidip kendi gözünüzü büyütün" demek olur
    Ya da son derece karmaşık şeylerle uğraşmanız gerekir
    Öncelikle, o metnin gerçekten metin mi yoksa görüntü mü olduğu bile bir sorundur
    İnsan gözü gözlüğünü yeniden takınca fark etmeksizin okuyabilir, ama bir ayrıştırıcı segmentasyon hataları verip bozulabilir
    PDF insanlar okusun diye vardır; bu yüzden PDF okumak için insanı taklit etmeniz gerekir

  • Eskiden oyuncak bir PDF ayrıştırıcısı yapmayı denemiştim; biçimin nasıl çalıştığını öğrenince epey afalladım
    Bunu düşününce, metin ağırlıklı kullanım alanlarında PDF'nin bu kadar sık kullanılması daha da tuhaf geliyor
    Özellikle fatura gibi örnekleri düşündürüyor
    Dijital sistemler veriyi dosyadan kolayca çıkarabilmeli, ama aynı zamanda insana da iyi görünecek şekilde biçimlendirilmiş olmalıdır
    Teknoloji sektörü daha iyi biçimlere geçse çok daha iyi olur gibi geliyor

    • XML+XSLT neredeyse böyle bir çözümdü, ama ne yazık ki tarayıcılar artık yerel XML dosyalarını değil yalnızca uzak sunuculardaki XML'i destekliyor