Japonca Dikey Metin OCR: Sütun Sırasını Koru ve Furigana'yı Yönet

Japonca dikey metin OCR işlemi için görüntü filtrelerini değiştirmeden önce yazma yönünü kontrol edin. Dikey metinleri işleyebilen bir Japonca model ve bölütleme ayarı kullanın, sütunların amaçlanan sırasını doğrulayın ve yalnızca ana metne mi yoksa furigana'ya da ihtiyacınız olduğuna karar verin. Tanınabilir karakterlerle dolu bir sayfa, dizilişleri yanlışsa hâlâ kullanılamaz bir döküm olabilir.

Bu kararları somutlaştırmak için küçük, tekrarlanabilir yerel bir deney yürüttük. Yatay yapılandırma üç dikey sütunumuzu karıştırdı. Dikey yapılandırma düz ana metni geri kazandırdı, ancak furigana eklemek iki noktalama işaretini değiştirdi ve ruby metnini kırpıp çıkarmak noktalama hatalarını ortadan kaldırmadı.

Bunlar, tüm Japonca kitaplar hakkındaki bir doğruluk iddiası değil, bilerek küçük tutulmuş sentetik bir örneğin sonuçlarıdır. Çıkarılması gereken faydalı ders daha dardır: karakter tanıma, okuma sırası ve açıklama yönetimini ayrı ayrı değerlendirin. Sonucu yalnızca Japonca görünüyor diye çeviriye göndermeyin.

Öncelikle gerçekten istediğiniz metni belirleyin

Geleneksel Japonca dikey kompozisyonda karakterler bir satır boyunca aşağı doğru ilerler ve satırlar sağdan sola doğru ilerler. Ruby, temel karakterlerle ilişkilendirilen daha küçük metindir; furigana genellikle bunların okunuşunu sağlar. W3C'nin Japonca Metin Düzeni Gereksinimleri belgesi bu yazma yönlerini ve ruby ilişkilerini açıklar.

OCR'den önce sayfanın anlamlı bölgelerini etiketleyin:

• ana dikey sütunlar;
• gövde metninin yanındaki küçük ruby;
• yatay başlıklar, resim yazıları veya tablolar;
• sayfa numaraları ve sayfa üstü bilgileri;
• kenar notları veya ilgili olmayan bitişik sayfalar.

Her dikey şeridi bağımsız bir paragraf olarak ele almayın. 図書館 yanındaki küçük kana şeridi onun okunuşu olabilir, としょかん sonraki cümle değil.

OCR'yi değerlendirmeden önce çıktı politikasını seçin:

Aynı çıktı bir görevden geçip diğerinde başarısız olabilir. Deneyimiz yalnızca gövde transkripsiyonunu karşılaştırma hedefi olarak kullanır. Telaffuz çalışması baskısı için eksik furiganayı kabul edilebilir görmez.

Gerçek üç cümlelik bir OCR deneyi

Örnek, şu kendi yazdığımız cümleleri kullanır:

朝の図書館で本を読む。
古い地図には川が見える。
明日は友人と駅で会う。

Bunlar bir kütüphanede kitap okumayı, eski bir haritada bir nehir görmeyi ve bir istasyonda bir arkadaşla buluşmayı anlatır. Satır sonları kaldırıldığında, üç Japonca nokta dahil 34 gövde metni Unicode kod noktası vardır.

Aynı gövdeyi üç biçimde oluşturduk:

1. Yatay metin.
2. Üç dikey sütun, sağdan sola okunur.
3. Furigonalı aynı dikey sütunlar yanında 図書館, 地図, 友人, ve 駅.

Bunlar kitaptan taranmış sayfalar değil, temiz eğitim görselleridir. Oluşturucu, Noto Sans CJK JP, 64 piksel gövde karakterleri, 24 piksel ruby ve basitleştirilmiş karakter bazında dikey yerleşim kullanır. Dikey noktaları, fontun uygun dikey karakter konumlandırmasını kullanmak yerine manuel olarak seçilen konumlarda küçük ana hatlı daireler olarak çizer; bu nedenle noktalama sonuçları, OCR'nin uygun şekilde dizilmiş bir kitapta nasıl performans gösterdiğini ortaya koymaz. Her Japonca dizgi kuralını yeniden üretmez. Testte bulanıklık, eğrilik, kağıt dokusu, el yazısı, tarihi tip veya karışık yönlü sayfa yoktur.

Motor, modeller ve ayarlar

Deney, 7 Eylül 2026 tarihinde yerel olarak macOS ARM64 üzerinde Tesseract.js 7.0.0 ve Tesseract.js-core 7.0.0 kullanılarak gerçekleştirildi. Tüm başarılı çağrılar resmi tessdata_fast modellerini şu commit'te kullandı: 87416418657359cb625c412a48b6e1d6d41c29bd, OEM 1 (yalnızca LSTM motor modu) ile.

Tesseract'ın resmi model deposu ayrı jpn ve jpn_vert dosyaları sağlar. Belgeleri PSM 5'i tek tip dikey hizalanmış bir blok, PSM 6'yı ise tek tip bir metin bloğu olarak tanımlar; tanınan bölgeye uyan bir segmentasyon varsayımı seçin. Şuraya bakın: sayfa segmentasyonu belgeleri.

Kaydettiğimiz vakalarda yatay metin için PSM 6 ile jpn, dikey metin için PSM 5 ile jpn_vert ve kasıtlı olarak uyumsuz bir jpn/PSM 6 dikey kontrolü kullanıldı. İki dikey yapılandırma arasında hem model hem de segmentasyon değiştiğinden, bu tek başına herhangi bir ayarın etkisini izole eden bir deney değil, bir iş akışı karşılaştırmasıdır.

ile yapılan ilk deneme, tessdata_best OCR metni üretmeden önce mevcut WebAssembly çekirdeğinde durduruldu. Uyumluluk için resmi tamsayı tessdata_fast modellerine geçtik ve bu hatayı kaydettik. Bu geçişten bir model ailesinin doğruluğu hakkında herhangi bir sonuca varılamaz.

Aslında ne döndü

Karşılaştırma, boşlukları kaldırır ve Unicode NFC normalleştirmesi uygular. Noktalama işaretlerini değiştirmez, kanjileri düzeltmez veya metni yeniden düzenlemez; bunu yapmaz. Eksiksiz ham çıktılar ve sürüm/model hash'leri, gövde karşılaştırma CSV'si, ve hata açıklamaları indirilebilir.

Örneğin, furigana durumu şu ilk satırı döndürdü:

Expected: 朝の図書館で本を読む。
Observed: 朝 の 図書 館 で 本 を 読む .

Boşluklar belirtilen karşılaştırma kuralımız tarafından yoksayılır. Son noktalama işareti yoksayılmaz. Yalnızca arama yapılan bir iş akışı bu farkı hoş görebilir, ancak sadık bir transkripsiyonun bunu kaydetmesi ve düzeltmesi gerekir.

Uyumsuz dikey kontrol şu ifadeyle başladı: 明 古 昌, amaçlanan ilk cümleyi takip etmek yerine sütunların en üstteki karakterleri üzerinden atladı. Çıktısı, bireysel sembolleri tanımanın neden bir okuma sırasını yeniden oluşturmakla aynı anlama gelmediğini göstermektedir.

Yedi tamamlanmış OCR çağrısı vardı: dört tüm görsel vakası ve üç kırpma. Her çıktıyı sakladık. Bir aracı sonuçları oluşturulan temel gerçeklikle karşılaştırdı ve görselleri görsel olarak inceledi; kör insan incelemesi veya geniş bir kıyaslama derlemi yoktu. Deney, evrensel olarak en iyi motoru, kitap düzeyinde bir doğruluk oranını veya taramanızdaki performansı kanıtlamaz.

Kendi sayfanızda bölge odaklı bir iş akışı kullanın

1. Kaynağı koruyun ve zor bir sayfa seçin

Orijinal görseli veya PDF'i değiştirmeden bırakın. Bir kopya üzerinde çalışın ve sayfa numarasını kaydedin. Çözmeye çalıştığınız sorunu içeren bir sayfa seçin: yoğun rubi, dar bir sütun boşluğu, dikey metnin üzerindeki yatay bir başlık veya olağandışı küçük yazı tipi.

Temiz bir kapak sayfası, ana metin sayfaları farklı bir düzene sahip bir kitap için yararlı bir kabul testi değildir. Kaynak bir PDF ise, görüntü tabanlı bir OCR iş akışı çalıştırmadan önce seçilen sayfayı güvendiğiniz bir araç kullanarak dışarı aktarın veya işleyin. Bu makalenin betikleri PNG dosyalarını kabul eder; PDF'leri işlemez veya aranabilir PDF katmanları oluşturmaz.

Taranmış belge hazırlama ve çeviri sürecinin tamamı için daha kapsamlı olan taranmış PDF iş akışını kullanın. Bu kılavuz Japonca yönü, bölümlendirmeyi, rubiyi ve transkripsiyon kararlarını ele almaktadır.

2. Küçük metni bozmadan yakalama kusurlarını düzeltin

Gerçek karakterleri faydalı bir yakınlaştırma düzeyinde inceleyin. İstenmeyen eğrilikleri düzeltin, ilgili olmayan sayfa kenarlıklarını kaldırın ve küçük kana ile noktalama işaretlerini ayırt etmek için yeterli kontrastı koruyun. Agresif eşiklemeyi veya keskinleştirmeyi otomatik bir iyileştirme olarak ele almaktan kaçının: OCR'a güvenmeden önce ortaya çıkan görseli orijinaliyle karşılaştırın.

Tesseract'ın görsel kalitesi rehberi; çözünürlüğü, gürültüyü, eğriliği ve kenarlıkları kapsar. Bunlar yazma yönünden ayrıdır. Bir açıyla fotoğraflanmış bir sayfayı düzeltmek, dik duran dikey Japonca metni yana doğru döndürmekle aynı işlem değildir.

Örnek dosyalar 300 dpi meta verisi taşır, ancak bu sayı eksik detay oluşturmaz. Gerçek ana metin glif boyutları 64 pikseldir. “300 dpi” olarak yeniden etiketlenmiş düşük çözünürlüklü bir fotoğraf yine aynı düşük çözünürlüklü fotoğraftır.

3. Sayfa bir düzen varsayımını ihlal ettiğinde bölgeleri ayırın

Yatay bir başlığı, dikey düz yazıyı, bir illüstrasyonu ve bir sayfa numarasını tek bir OCR çağrısının idare etmesini istemeden önce ana dikey bloğu kendi başına deneyin. “Sayfa 12, metin, sağdan 1. sütun” gibi basit bir bölge kaydı tutun. Bu kayıt, sonraki birleştirmeyi denetlenebilir kılar.

Karışık yönlü materyaller için yatay bölgeyi uygun yatay ayarla ve dikey bölgeyi dikey ayarla tanıyın, ardından bunları belgenin amaçladığınız sırasına göre birleştirin. Bu, üç örnek görselimiz tarafından ölçülen karışık düzen yeteneği değil.

, dosyanızda test etmeniz önerilen bir iş akışıdır. Kırpma deneyimiz, gövde metnini ve beyaz kenar boşluğunu korurken her sentetik sütunun yanındaki rubi şeridini hariç tutmak için kesin bilinen koordinatları kullandı. Bu otomatik bir furigana silme algoritması değil, manuel bir bölge seçimi göstergesiydi. Koordinatlarını gerçek bir kitap sayfasına uygulamayın.

4. Bireysel karakterleri son okumadan önce sütunları kontrol edin

Amaçlanan yönde çalışarak her sütunun ilk ve son gövde karakterlerini karşılaştırın. Hiçbir sütunun eksik olmadığını, yinelenmediğini, ters çevrilmediğini veya komşusuyla karışmadığını onaylayın. Ardından sütun sınırlarındaki cümleleri inceleyin.

Yalnızca bundan sonra bireysel kanjileri, kana karakterlerini, noktalama işaretlerini, sayıları ve isimleri düzeltmelisiniz. Aksi takdirde, yanlış paragrafa yerleştirilmiş parçaları cilalamakla vakit kaybedebilirsiniz.

Faydalı bir üç geçişli inceleme şöyledir:

1. Bölgeler ve sıra: amaçlanan her gövde bölgesi bir kez ve sırayla mevcuttur.
2. Karakterler: küçük noktalama işaretleri ve kana markaları dahil olmak üzere gerçek resmi metinle karşılaştırın.
3. Notlar: her bir ruby öğesinin, notun veya kenar etiketinin korunup korunmayacağına, ayrılacağına veya kasıtlı olarak hariç tutulacağına karar verin.

Bir motorun güven değeri bu kontrollerin yerini tutamaz. Karıştırılmış kontrolümüz yine de motor tarafından bildirilen bir güven numarası döndürdü; bu durum okuma sırasını kabul edilebilir kılmadı.

Nedenini bilene kadar furigana'yı kaldırmayın

Yalnızca gövde çıkarma için, ruby yanlışlıkla ikinci bir düz yazı katmanı haline gelmemelidir. Ancak her küçük kana dizesini silmek güvenli bir genel kural değildir. Bir okuma, bir ismi netleştirmeye, yazarın seçtiği telaffuzu korumaya veya okuyucunun çalışma görevini desteklemeye yardımcı olabilir.

Furigana görselimizde, OCR çıktısı ana kanjiyi içeriyordu ancak dört okumayı ayrı bir açıklama seti olarak döndürmedi. Bu, yalnızca gövdeye yönelik bir arama görevi için noktalama düzeltmesinden sonra yeterli olabilir. Teslim edilebilir sonuç telaffuz bilgisi vaat ediyorsa yetersizdir.

Önemli okumaları ayrı olarak saklayın ve bunları doğru olayla ilişkilendirin. Örneğin:

Page: sample 1
Column: 1 from the right
Base text: 図書館
Reading shown: としょかん
Decision: retain body text; save reading in the annotation record

Örneğin:ayrı ruby transkripsiyonu bu politikayı açık hale getirir. Bu, bir OCR başarı iddiası değil, görselle birlikte üretilmiş kesin gerçektir.

OCR bir kelimenin içine kana karıştırırsa veya ilişkisini kaybederse, görselle karşılaştırın ve transkripsiyonu onarın. Bir dil modelinden kaynağı tahmin etmesini ve tahmini kurtarılan metin olarak sunmasını istemeyin. Bunun yerine belirsiz bir okumayı inceleme için işaretleyin.

Kırpma sonuçları aynı zamanda basitçi bir "ruby'yi kaldır ve her şey iyileşir" kuralına da karşı çıkmaktadır: iki noktalama işareti farkı kalmış ve etkilenen cümle sonları değişmiştir. Bu gözlem, bu belirli temiz fikstüre aittir. Bize segmentasyondan sonra sonucu doğrulamamız gerektiğini söyler, genel olarak kırpmanın OCR'ye yardımcı olduğunu veya zarar verdiğini değil.

Testi yeniden üretin veya bir inceleme günlüğü tutun

Şurayı indirin:deney README dosyası sabitlenmiş model ve yazı tipi kaynakları, bağımlılık sürümleri, dosya açıklamaları ve komutlar için. Şurayı indirin: örnek üreteci, OCR çalıştırıcısı, ve karşılaştırma betiği ayrı görüntü oluşturma, tanıma ve değerlendirme adımlarını ayırır.

Çalıştırıcı, belgelenmiş Tesseract.js işçi API'sini kullanır. Dikey bir bölge için temel ayarları şunlardır:

const worker = await createWorker("jpn_vert", 1, {
  langPath: modelDirectory,
  gzip: false,
  cacheMethod: "none",
});
await worker.setParameters({
  tessedit_pageseg_mode: "5",
  user_defined_dpi: "300",
});

modelDirectory, indirilmiş ve sıkıştırılmamış jpn_vert.traineddata dosyasını içermelidir. Bu eksiksiz program değil, bir alıntıdır; sağlanan çalıştırıcı ayrıca ham sonuçları kaydeder ve işçileri sonlandırır.

Başka bir OCR uygulaması kullanıyorsanız, ayar adımları farklı olsa bile aynı kanıtları koruyun: kaynak bölge, orijinal dosya, model veya araç sürümü, yön, bölütleme seçeneği, gerçek çıktı, düzeltilmiş metin ve çözülmemiş karakterler. inceleme günlüğü şablonu, sayfalarınızın zaten onaylandığı anlamına gelmemesi için boştur.

Küçük ve tam eşleşen sonucumuzu tüm roman için vaat edilen bir yüzdeye dönüştürmeyin. Farklı yazı tipleri, sıkışık sütunlar, tarihi biçimler, düşük kaliteli taramalar ve manga konuşma balonları kendi temsilci testlerini gerektirir. Manga düzeni ve el yazısı tanıma bu deneyin kapsamı dışındadır.

Yalnızca kurtarılan kaynak güvenilir olduğunda çevirin

Amacınız arama yapmak, alıntı kopyalamak veya sözlükten bakmaksa, doğrulanmış Japonca metin nihai sonuç olabilir. Sadece OCR işin içinde yer aldı diye tüm belgesini çevirmeniz gerekmez.

Hâlâ dil engeli okumayı engelliyorsa ve yükleyebileceğiniz kullanışlı bir dosyanız varsa, PDF çeviri iş akışı ile devam edin. Tanıma hatalarını çeviri hatalarından ayırt edebilmeniz için orijinal taramayı ve denetlenmiş transkripsiyonu koruyun. Örnek çalıştırıcı, otomatik yüklemeye hazır bir PDF değil, metin ve TSV dosyaları üretir; bir sonraki aracınızın gerektirdiği gerçek giriş biçimini hazırlayın.

BookTranslator'ın OCR modu, orijinal dikey düzeni garanti etmek yerine çevrilmiş içeriği yeniden oluşturur. Her ruby (furigana) ilişkisini koruyacağını veya doğrulanmamış tanıma hatalarını düzelteceğini varsaymayın. PDF biçim koruma kılavuzu ve nihai PDF kalite kontrol kontrol listesi.

kullanarak son belgenin okuma sırasını ve biçimlendirmesini inceleyin. Güvenilir devir teslim “OCR tamamlandı” değildir. “İstenen Japonca metin mevcut, dizisi kontrol edildi ve ek açıklamaların işlenişi belgelendi” demektir.