PDF'ten Yapı Çıkarma Nasıl Çalışır? Etiketli PDF ve Başlık Tespiti

Bir PDF'ten Markdown üretmek, aslında oldukça zor bir çıkarım problemidir. Çünkü PDF'in içinde "bu bir başlıktır" veya "bu paragraf şuradan sonra okunur" bilgisi çoğu zaman bulunmaz. Bu yazıda dönüştürücülerin ne yaptığını, hangi ipuçlarını kullandığını ve neden bazı belgelerde başarılı bazılarında başarısız olduğunu anlatıyoruz.

PDF ne saklar, ne saklamaz

Bir PDF sayfasının içeriği, çizim komutlarından oluşur:

BT
/F2 18 Tf              % 18 punto yazı tipi seç
72 720 Td              % konuma git
(Giris) Tj             % "Giris" yaz
ET
BT
/F1 11 Tf              % 11 punto yazı tipi seç
72 690 Td
(Bu calismada ele alinan konu...) Tj
ET

Bu komutlarda ne var: hangi harflerin, hangi yazı tipiyle, hangi boyutta, hangi koordinata çizileceği.

Ne yok: "Giris" kelimesinin bir başlık olduğu. Onu takip eden metnin o başlığın altındaki paragraf olduğu. Paragrafın nerede bitip yenisinin başladığı.

Bir insan sayfaya baktığında bunları anında anlar — çünkü 18 punto kalın bir kelimeyi tek başına bir satırda görmek "başlık" demektir. Dönüştürücünün de aynı çıkarımı yapması gerekir.

Etiketli PDF: çıkarım gerektirmeyen durum

Etiketli (tagged) PDF, sayfa içeriğinin yanı sıra belgenin anlamsal yapısını da taşır. Dosyada bir yapı ağacı bulunur:

Document
├── H1 "Giriş"
│   └── P "Bu çalışmada ele alınan konu..."
├── H2 "Yöntem"
│   ├── P "Araştırma şu adımlarla..."
│   └── L (liste)
│       ├── LI "Birinci adım"
│       └── LI "İkinci adım"
└── Table
    ├── TR
    │   ├── TH "Yıl"
    │   └── TH "Değer"
    └── TR ...

Bu ağaç, tam olarak Markdown'ın ihtiyaç duyduğu bilgidir. Etiketli bir PDF'ten Markdown üretmek, çıkarım değil doğrudan eşleme işidir:

| PDF etiketi | Markdown | |---|---| | H1, H2, H3 | #, ##, ### | | P | Paragraf | | L / LI | - liste | | Table / TR / TD | Markdown tablosu | | Link | [metin](url) | | Figure | ![alt](görsel) |

Sonuç, etiketsiz PDF'lerden dramatik biçimde daha iyi olur.

Etiketli PDF nereden gelir?

• Word'den "Belge yapısı etiketleri" seçeneği açıkken üretilen PDF'ler
• Erişilebilirlik gereksinimlerine göre hazırlanmış kurumsal belgeler
• PDF/UA (Universal Accessibility) standardına uygun belgeler

Nereden gelmez?

• "PDF olarak yazdır" yoluyla üretilen dosyalar
• Çoğu tasarım programı çıktısı (özel ayar yapılmadıysa)
• Taranmış belgeler
• Eski PDF'ler

Belgenizin etiketli olup olmadığını PDF görüntüleyicinin belge özellikleri penceresinden görebilirsiniz.

Etiketsiz PDF'te çıkarım süreci

Etiket yoksa dönüştürücü sırayla şunları yapar.

1. Metin parçalarını toplama

PDF, metni küçük parçalar hâlinde saklar. Bazen bir kelime, bazen birkaç harf, bazen tek bir karakter ayrı bir çizim komutu olabilir — özellikle karakter aralığı ayarlanmış metinlerde.

Dönüştürücü, aynı satırda ve birbirine yakın olan parçaları birleştirerek kelimeler ve satırlar oluşturur.

Zorluk: kelime sınırlarını bulmak. PDF'te boşluk karakteri her zaman yazılmaz; bazen sadece imleç ileri kaydırılır. Dönüştürücü, parçalar arasındaki mesafeye bakarak "burada boşluk var" kararı vermek zorundadır. Eşik yanlış seçilirse ya kelimeler birleşir ya da kelime ortasında boşluk oluşur.

2. Satırları paragraflara gruplandırma

Ardışık satırlar aynı paragrafa mı ait? İpuçları:

• Dikey mesafe: Satırlar arası normal boşluk mu, daha fazlası mı?
• İlk satır girintisi: Yeni paragraf girintiyle başlıyor olabilir.
• Önceki satırın bitişi: Satır sayfa genişliğinin sonuna kadar gidiyorsa devam ediyordur; erken bitiyorsa paragraf sonu olabilir.
• Noktalama: Nokta ile biten kısa bir satır, paragraf sonu işaretidir.

3. Okuma sırasını belirleme

Bu, en zor adımdır.

Etiketsiz bir PDF'te metin parçaları çizim sırasıyla saklanır ve bu sıra görsel okuma sırasıyla aynı olmak zorunda değildir. Bir tasarım programı önce tüm başlıkları, sonra gövde metnini çizmiş olabilir.

Dönüştürücü, parçaların koordinatlarına bakarak mantıklı bir sıra kurmaya çalışır. Tek sütunlu bir sayfada bu kolaydır: yukarıdan aşağıya, soldan sağa.

Çok sütunlu düzende sorun başlar. İki sütunlu bir sayfada satırları basitçe yukarıdan aşağıya sıralarsanız, sol sütunun ilk satırı ile sağ sütunun ilk satırı yan yana geldiği için metinler iç içe geçer:

"Bu çalışmanın amacı elde edilen bulgular göstermektedir ki incelenen örneklerde..."

Anlamsız bir karışım. İyi dönüştürücüler sütun tespiti yapar: metin bloklarının yatay dağılımına bakıp boşluk koridorlarını bulur ve sütunları ayırır. Ama bu da bir tahmindir ve karmaşık düzenlerde yanılır.

4. Başlık tespiti

Dönüştürücü şu ipuçlarını değerlendirir:

| İpucu | Ağırlık | |---|---| | Yazı tipi boyutu (gövdeden büyük) | Yüksek | | Kalın yazı tipi | Orta | | Yazı tipi ailesi değişimi | Orta | | Satırın kısalığı | Orta | | Üstünde/altında fazla boşluk | Orta | | Numaralandırma deseni (1., 1.1.) | Yüksek | | Büyük harflerle yazılmış olma | Düşük | | Sayfa başında olma | Düşük |

Sonra bu adaylar seviyelere ayrılır: belgede beş farklı başlık boyutu varsa en büyüğü H1, sonraki H2 ve böyle devam eder.

Tipik hatalar:

• Kalın yazılmış bir vurgu cümlesi başlık sanılır.
• Küçük puntolu bir alt başlık gövde metni sanılır.
• Aynı belgede farklı bölümlerde farklı başlık stilleri kullanılmışsa seviyeler karışır.
• Şekil ve tablo açıklamaları başlık sanılır.

5. Liste tespiti

Madde işaretleri (•, -, ▪) ve numaralar (1., a), i.) tespit edilir. Girinti seviyesi iç içe listeleri belirler.

Sorun: PDF'te madde işareti bazen ayrı bir çizim nesnesidir (metin değil), bazen özel bir karakterdir, bazen de sadece boşlukla oluşturulmuş görsel bir hizalamadır. Üçüncü durumda tespit imkânsızlaşır.

6. Tablo tespiti

En zor yapılardan biri. İki yaklaşım kullanılır:

Çizgi tabanlı: Sayfadaki yatay ve dikey çizgileri bulup ızgara oluşturmak. Çizgili tablolarda iyi çalışır.

Hizalama tabanlı: Metin parçalarının dikey hizalanmasına bakıp sütun tahmin etmek. Çizgisiz tablolarda tek yoldur ama kırılgandır — sıradan bir paragraf da bazen tablo sanılabilir.

Tespit edilse bile Markdown'ın tablo sözdizimi sınırlıdır: birleştirilmiş hücreler, iç içe tablolar ve hücre içi çok satırlı biçimlendirme ifade edilemez.

Üstbilgi, altbilgi ve gürültü

Her sayfanın üstünde ve altında tekrarlayan öğeler bulunur: belge başlığı, bölüm adı, sayfa numarası, telif notu, tarih.

Bunlar sayfa içeriğinin parçasıdır ve dönüştürücü onları içerik sanabilir. Sonuç, her birkaç paragrafta bir tekrarlayan gürültü satırlarıdır.

İyi dönüştürücüler bir sezgi kullanır: birden çok sayfada aynı konumda tekrarlayan metin, üstbilgi/altbilgidir. Bu tespit genellikle işe yarar ama sayfa numaralarında yanılır (her sayfada farklı olduğu için).

Yazı tipi kodlaması sorunu

Bazı PDF'lerde metin çıkarma tuhaf sonuçlar verir: anlamsız karakterler, eksik harfler, karışık diller.

Sebep, PDF'in yazı tipi kodlama mekanizmasıdır. Bir PDF'te harfler, yazı tipi içindeki glif numaralarıyla saklanabilir ve bu numaraların Unicode karşılıklarını veren bir eşleme tablosu (ToUnicode CMap) bulunmalıdır.

Bu tablo eksik veya bozuksa, dönüştürücü glif numaralarını doğru harflere çeviremez. Sayfa ekranda doğru görünür (çünkü çizim doğrudur) ama metin çıkarma anlamsız çıktı verir.

Türkçe belgelerde bu sorun özellikle ş, ğ, ı, İ gibi harflerde ortaya çıkabilir.

Neden bazı PDF'ler iyi, bazıları kötü dönüşüyor

Belirleyici faktör, PDF'in nasıl üretildiğidir:

| Kaynak | Dönüşüm kalitesi | Sebep | |---|---|---| | Word (etiketli) | Mükemmel | Yapı bilgisi dosyada | | Word (etiketsiz) | İyi | Düzenli stiller, tek sütun | | LaTeX | İyi-orta | Düzenli ama etiketsiz | | Tasarım programı (rapor) | Orta | Etiketsiz, düzen karmaşık | | Tasarım programı (broşür) | Kötü | Çok sütun, kutular, serbest düzen | | Taranmış + OCR | Zayıf | Yapay metin katmanı | | Taranmış (OCR'sız) | İmkânsız | Metin yok |

Özetle

PDF'ten Markdown üretmek, çizim komutlarından anlamsal yapı çıkarma işidir. Etiketli PDF'lerde bu yapı zaten dosyada bulunur ve dönüşüm doğrudan bir eşlemeye indirgenir — sonuç neredeyse hatasız olur. Etiketsiz PDF'lerde ise dönüştürücü her şeyi görsel ipuçlarından tahmin etmek zorundadır: metin parçalarını gruplandırma, okuma sırasını belirleme, yazı tipi boyutundan başlık seviyesi çıkarma, hizalamadan tablo tespit etme. Bu tahminler tek sütunlu düzenli belgelerde başarılı, çok sütunlu ve tasarım ağırlıklı belgelerde zayıftır. Bu yüzden dönüşümü bir bitiş değil, elle temizlik gerektiren bir başlangıç noktası olarak görmek doğru olur.