Bu PDF, Abbyy Finereader 10 tarafından hazırlanmıştır:

http://ebooks.zeitr.org/from_abbyy.pdf

İlk cümleyi kopyalayıp yapıştırabilir ve bu (çok iyi) metin sonucunu alabilirsiniz:

Der »Bund Deutscher Jimnastik-Schulleiter« 20 Mart 1955 tarihinde eklendi.

Ghostscript 9.02 (64 bit Windows) ile bazı işlemlerden sonra bu dosyayı alıyorum:

http://ebooks.zeitr.org/after_ghostscript.pdf

Şimdi ilk cümle garip görünüyor - her kelimenin son karakterinden önce fazladan bir boşluk var.

Der »Bun d Deutsche r JimnastikSchulleiter« 20 ursd. Novembe r 195 5 y e lk ö ze zlikle m e K u lla n ım ı ma le D e n le B e N e N e N e N e N e N e N e N e N e N e N e D e L e N e N e N e N e N e N e N e N e N e N e N e N e N e N şe z e n e l e l e l e j e l e j e l e l e l e l e l e l e l e l e l e l e l L l e l'i L ü u z de ut ut ut ut ut ut ut private private private private private private private private private private private private private ut private private private private private private private private private private private private private private private private private private private embe embe embe embe embe embe embe embe embe embe embe.

Bu, Acrobat Reader'da tüm kelimeleri arayamadığınız ana olumsuz etkiye sahiptir. Efekti Ghostscript için ayarlanan aşağıdaki minimum parametre ile çoğaltabilirim:

-sDEVICE=pdfwrite ^
-dBATCH ^
-dNOPAUSE ^
-sstdout="myStdOut" ^
-sOutputFile="myDestFile.pdf" ^
 mySourceFile.pdf

Herhangi bir fikir?

Bunu ilginç bir sorun buldum ve daha yakından baktım ...

Öncelikle, qpdfher iki dosyanın kaynak kodlarını daha iyi görebilmek için PDF veri akışlarını sıkıştırmak için komut satırı aracını kullandım :

qpdf.exe ^
   --qdf ^
     from_abbyy.pdf ^
     qdf--from_abbyy.pdf

qpdf.exe ^
   --qdf ^
     after_ghostscript.pdf ^
     qdf--after_ghostscript.pdf

Ekstra bir alanın eklendiği ilk olaylardan birine bakıldığında ( "Bunut Deutsche r GymnastikSchulleiter" e dönüşen orijinal dizisi "Bund Deutscher Gymnastik-Schulleiter " ), aşağıdaki PDF parçacıklarını buluyorum:

Qdf - from_abbyy.pdf 'de:

( Deutsche) Tj
0 Tc
(r) Tj
1 0 0 1 143.236 265.140 Tm     %% Tm = 'text matrix' operator
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite) Tj

Qdf olarak - after_ghostscript.pdf:

( Deutsche)Tj
0 Tc
36.235 0 Td                    %% extra Td = 'move text current point' operator
(r)Tj
2.16501 0 Td                   %% Td = 'move text current point' instead of Tm
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite)Tj

Burada kullanılan PDF grafik operatörlerinin ne anlama geldiği hakkında biraz fikir vermek için, işte kısa bir liste:

Tj - show text
Tc - set character spacing
Tm - set text matrix
Tw - set word spacing
Td - move text current point

Gördüğünüz gibi, Ghostscript orjinal Tm( text matrix ) operatörünün yerine Td( şimdiki metni taşı ) bir tane ile değiştirildi ve ayrıca fazladan eklendi 2.16501 0 Td. Bunun neden olduğunu bilmiyorum. Ghostscript'in bugzilla'sına [*] bir hata raporu göndereceğim ve bunu çözmekle ilgilenip ilgilenmediklerini göreceğim.

Ancak, Linux Acrobat Reader 9.4.2 kullanıyor ve "Dosya -> Metin Olarak Kaydet ..." menü eylemini kullanırsam bu sorunun oluşmadığını unutmayın . Bu durumda, ek boşluk yoktur (ancak birkaç ekstra çizgi). Ayrıca Linux'ta, metni doğru aranabilir değildir ve ayrıca yapıyor fazladan boşluklar gösterir copy'n'paste ....

^{[*] Yaptığımda hata numarasıyla burada güncelleme yapacağım.}

Güncelleştirme:

Değiştirilen Tmişleç hakkında biraz daha düşündükten sonra , şimdi bunun sorunun kaynağı olmaması gerektiğini düşünüyorum.

Bunu fark ederken, dönüştürme işlemini v9.02 yerine Ghostscript v8.71 ile yapmaya çalıştım. Ve ne demeliyim? Copy'n'paste sorunu v8.71 çıktısıyla oluşmuyor!

Bunun anlamı: Ghostscript 9.02'de 8.71'de olmayan bir sorun var. Büyük olasılıkla, çıktı PDF'ye gömülü font metrikleri ile ilgili olmalı. Çünkü yukarıda belirtilen PDF parçacıkları v8.71 çıktısında v9.02 çıktısında olduğu gibi aynıdır ...

Güncelleme 2:

Ghostscript'in bugzilla'sındaki hata girişinin URL'si:

• http://bugs.ghostscript.com/show_bug.cgi?id=692206

Güncelleme 3:

Bu hata bu arada giderilmiş gibi görünüyor. Şu an tekrar denediğim Ghostscript sürümlerinde olduğunu görmüyorum: current Git (v9.10GIT) ya da Ghostscript v9.06.

Metin içeren bir sayfayı bir PDF'ye tarar ve üzerinde bir OCR uygulaması çalıştırırsanız, metin sayfaya eklenir, ancak "metin oluşturma modu" görünmez olarak ayarlanır. Orada, ancak ekranda gösterilmiyor (veya yazdırılırsa kağıda). Gördüğünüz veya yazdırdığınız orijinal taranmış resimdir.

Görünmez metni nasıl görünür hale getirebiliriz?

Pekala, PDF'i düzenleyebiliriz ... Metin oluşturmayı görünmez hale getirmek için PDF kodu şudur:

3 Tr

Bu dizeyi (henüz) orijinal from_abbyy.pdf'te veya from_ghostscript.pdf'de bulamazsınız çünkü PDF'lerin parçaları sıkıştırılmıştır. Bu yüzden onları mümkün olduğu kadar açıyoruz qpdf:

qpdf \
 --qdf \
   from_abbyy.pdf \
   qdf--from_abbyy.pdf

qpdf \
 --qdf \
   after_ghostscript.pdf \
   qdf--after_ghostscript.pdf

Şimdi yukarıdaki dizgiyi kolayca bulabiliriz (ve her dosyada sadece bir tane var).

Bunu, görünen metin oluşturma modlarından birine geçirelim. Genel olarak, bu 8 metin oluşturma modundan birini seçebiliriz:

 0 -  fill glyph shapes
 1 -  stroke glyph shapes
 2 -  fill, then stroke glyph shapes
 3 -  neither fill nor stroke glyph shapes (invisible)
 4 -  fill and add to path for clipping glyph shapes
 5 -  stroke glyph shapes and add to path for clipping
 6 -  fill, then stroke glyph shapes and add path for clipping
 7 -  add glyph shapes to path for clipping

"Doldur" modunu kullanırsam, OCR'dan gelen metin muhtemelen alttaki tarama görüntüsünün üstünde çok iyi görünmeyecektir. Bu nedenle "inme" varyantını tercih ederim. Bu yüzden sadece okumak için satırın üstündeki değiştiririm

 1 Tr

Bu değiştirilmiş PDF'ye bakarken beğenmedim, çünkü varsayılan çizgi genişliği zevkime göre çok kalın. Ayrıca, anahattı konturunun rengi siyahtır (varsayılan); Başlangıçta taranan şekillerle bir kontrast olması için kırmızıyı tercih ederim. Bu yüzden, çizgiyi çeyrek noktaya ayarlayan çizginin önüne bazı kodlar ekliyorum:

 .25 w

ve kontur rengini kırmızıya ayarlamak için bazıları:

 1 0 0 RG

Şimdi tam satır okur:

 .25 w 1 0 0 RG 1 Tr

Bu kadar.

Not : onun "TOK" (teknik açıdan çünkü bizim küçük manipülasyon, dosya hasarlı olduğu xrefartık geçerli olacak tablo). Acrobat Reader veya Acrobat Professional, yine de açacak (hatta şikayet etmeden) ve dosyanın xref bölümünü sessizce "onaracak". Diğer PDF görüntüleyiciler dosyayı reddedebilir, ancak şimdilik umrumda değil ...

İşte sonucun ekran görüntüleri: (İlk ekran görüntüsü pencere genişliğine yakınlaştırılmış.) (İkinci ekran görüntüsü% 800 oranında yakınlaştırılmıştır.)

Kırmızı anahatlar, tıpkı istediğimiz gibi taranan metnin şimdi görünmesini sağlar.

Her iki dosya için da yukarıda belirtilen aynı prosedürü uygulamam_abbyy.pdf ve after_ghostscript.pdf . Her iki sonucu da 2 farklı Acrobat Reader örneğinde açtım. Her ikisini de aynı değere yakınlaştırırsak ve her iki pencereyi de büyütürsek, görünümden her iki dosya arasında geçiş yapmak kolaydır [alt]+[tab]. Bu, iki PDF dosyası arasındaki en ince görüntü oluşturma farklılıklarını bile ortaya çıkarmanın iyi bir yoludur.

Sonuç olarak: Ghostscript'in (v9.02) girişi ve bu dosya için çıktısı arasında farklı bir tek piksel bile yok. Ama metni kopyalayıp kopyalamak istiyorsanız, oldukça fark var ...

Tanımlanan sorunu görmüyorum. Acrobat Professional 9.0 ile 'after' PDF dosyasını açtım ve metin doğru kopyalandı ve yapıştırıldı.

Ghostscript PDF dosyasını tam olarak yorumlar ve yorumladığı şeye bağlı olarak yeni bir PDF dosyası oluşturur, orijinal dosya ile metnin konumunu kaydetmesinden başka hiçbir ilişkisi yoktur.

PDF'nin zengin özelliklerinden dolayı, birden çok farklı yöntem kullanarak karakterleri aynı yerde konumlandırmak mümkündür. Yani GS'nin PDF dosyasını ürettiği şekilde kendi başına yanlış veya beklenmeyen bir şey yok.

Metnin doğru şekilde kaydedilebildiği göz önüne alındığında, bu, iki 'yakın' karakterin bitişik olup olmadığına veya ardışık ASCII olarak ele alındığında aralarında boşluk olup olmadığına karar veren Acrobat sezgisel tarama meselesidir.

Sorunun gömülü font metrikleri olabileceğine inanmıyorum. Fontun gömülü olmaması nedeniyle basit font metrikleri olabilir :-) Kullanılan font, belgeye gömülü olmayan Helvetica ve Acrobat (benim için en azından) ArialMT'yi kullanır. 'Orijinal' PDF dosyasının fontları da içermediğini unutmayın.

Sonunda bildirilen hataya bakacağım, ancak yakında olmayacak ve bu konuda yapabileceğimiz (ya da yapacakları) bir şey olduğundan şüpheliyim. Bana öyle geliyor ki bu sezgiselliğin kaçınılmaz bir sonucu. Ancak fontların gömülmesine yardımcı olabilir , böylece en azından tutarlı olurlar.

Ghostscript hata raporunda:

http://bugs.ghostscript.com/show_bug.cgi?id=692206

Şimdi sorunu yeniden üretebildim ve 8.71'deki bir gerileme değil, bir ilerleme (ve bir Adobe değişikliği).

8.71, geçersiz ToUnicode CMaps yazmasına neden olan bir hatayla sevk edildi. Yanıltıcı ve çelişkili Adobe belgeleri, aslında ToUnicode CMaps'in kendi kurallarına uymayan kuralları olduğunda CMap'ın bir CMap olarak yazılmasına neden oldu.

ToUnicode CMaps normalde yalnızca arama ve kopyalama / yapıştırma için kullanılır. Adından da anlaşılacağı gibi karakter kodlarını Unicode kod noktalarına eşlemek için kullanılır. 8.71 PDF dosyasındaki ToUnicode CMap kullanılmaz, çünkü geçersizdir, sonraki sürümlerde geçerli olandır ve Acrobat'ın kullandığı bilinmektedir.

Görünüşe göre Acrobat Reader'da 9.2'ye kadar ve ToUnicode verilerinin varlığı hiçbir fark yaratmıyor. 9.2'den sonra bir noktada, arama mekanizması değişti ve Acrobat, ToUnicode CMap'ın mevcut olup olmadığına bağlı olarak iki farklı mekanizma kullanıyor gibi görünüyor. 9.2'den sonra Acrobat Pro'ya erişemiyorum ve yalnızca son zamanlarda yüklü olan Reader X arasında hiçbir şeyim yok.

'Unicode yok' yöntemi Acrobat'ın tüm sürümlerinde çalışır, 'Unicode' yöntemi daha yeni sürümlerde başarısız olur.

Bunu, başvuruyu FontDescriptor'dan ToUnicode CMap öğesine beyaz aralıklarla yerleştirerek gösterdim. Gerekirse çeşitli dosyaları kullanılabilir hale getirebilirim, ancak sıkıştırılmış dosyaları büyüktür.

Arama, PDF’de bir sezgisel çaba olduğundan, bir sonuç garanti edilemez. Davranıştaki değişiklik, Ghostscript'ten değil Acrobat'tan kaynaklanıyor ve Ghostscript'teki değişiklik gerçek bir hatayı düzeltmekti, yani bir gerileme, bir gerileme değil.

Bu sorunun fontun 'yerleşikliğine' bağlı olup olmadığını kontrol etmek için Linux'ta başka bir dönüşüm yaptım. Ghostscript'in kullanılan fontları gömmesi için bu komut satırını kullandım:

gs \
 -o after_ghostscriptonlinux.pdf \
 -sDEVICE=pdfwrite \
 -dPDFSETTINGS=/prepress \
 -sEmbedAllFonts=true \
  from_abbyy.pdf

Ghostscript bu çıktıyı gösterecek:

GPL Ghostscript SVN PRE-RELEASE 9.02 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 2776276 1420923 2081124 778943 3 done.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2853416 1529123 2137980 831640 3 done.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970748 1643508 2194836 886454 3 done.

Ghostscript, NimbusSanL adlı bir font ailesinden font gömmüştür . Bu yüzden , Acrobat Reader'ın eksik Helvetica'nın yerine geçmesi için ekranda görüntülenmesi için kullanılan ArialMT artık yok (yukarıdaki kullanıcı 701996'nın yorumlarına da bakın). Ghostscript'in gömülü olduğu anda bu fontu Helvetica olarak değiştireceğini unutmayın. Ama bu bir sorun değil, çünkü NimbusSanL bir Helvetica klonu olarak yaratılmış ...

Ancak, bu çıktı PDF için bile, Acrobat Reader’dan copy'n'paste düzgün çalışmaz. Reader'ın artık Helvetica'nın yerine ArialMT kullanmasına gerek kalmamasına rağmen. Reader şimdi gömülü olan NimbusSanL / Helvetica-klonunu kullanıyor.

Şimdiye kadar Acrobat Reader veya Acrobat Professional'dan copy'n'pasting metni hakkındaki şu gerçekleri tespit ettik:

• Ghostscript v9.02 çıktısı bu dosya için yeterince iyi çalışmıyor .
• Yazı tipinin GS tarafından gömülü olup olmadığı veya olmadığı durumda olan durum budur.

• Bu, Windows XP'deki GS ve Linux'daki GS için geçerlidir.

• Ghostscript v8.71 çıktısı bu dosya için yeterince iyi çalışıyor .

• Yazı tipinin GS tarafından gömülü olup olmadığı veya olmadığı durumda olan durum budur.

• Bu, Windows XP'deki GS ve Linux'daki GS için geçerlidir.

• Copy'n'paste'nin kırıldığı çıktılar için bile, Metin Olarak Kaydet ... yapar.

Hala bunun neden böyle olması gerektiğini anlamıyorum. Fakat açıkça Ghostscript'in v8.71'den 9.02'ye doğru bir çeşit (belki de küçük) gerilemesi olarak görünüyor.

Şimdi 'kritik' PDF'lerle diğer PDF görüntüleme yazılımlarını deneyelim:

• Linux'taki Wine içindeki Adobe Reader X: copy'n'paste, v9.4.4 ile aynı şekilde tasarlanmıştır.
• Evince v2.32.2'de Linux: copy'n'paste çalışıyor.
• PDFXChange Viewer 2.5 (derleme 191), Windows XP'de Prof: copy'n'paste çalışır.
• MuPDF okuyucu 0.8 Linux'ta: nasıl kopyalayacağınızı bilemezsiniz - ancak 'arama' kusursuz çalışır.
• Bulundu. Linux'ta "PDF Viewer 0.1.7" olarak adlandırılan: copy'n'paste çalışır.
• SumatraPDF v1.5 Linux'taki Wine'da: copy'n'paste çalışır.
• SumatraPDF v1.5.1, Windows XP'de: copy'n'paste çalışır.
• FoxitReader 4.3.1.0113, Windows XP'de: copy'n'paste çalışıyor.
• Linux'taki Wine içindeki Nitro PDF Reader: copy'n'paste çalışır.

Not, hala kararımın copy'n'paste'in çalıştığı tüm 'çalışan' PDF okuyucuları arasında çok küçük farklılıklar var . Buradaki eksik bir çizgi veya kelimelerle aralarındaki iki kat boşluklar ve diğer şeyler gibi ... Şu an bunun neden olabileceğine dair bir açıklama yapmamıştım, ama neden muhtemelen aynı ürünler, neden Adobe ürünleri arasında büyük boşluk olduğunu gösteriyor. (ki bu dosya için çalışan kopya ve yapıştırma yok) bir tanesinde biri, diğerinde ise "dünyanın geri kalanı" vardı.