Цей PDF був підготовлений Abbyy Finereader 10:

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

Ви можете скопіювати та вставити перше речення та отримати цей (дуже хороший) текстовий результат:

Der »Bund Deutscher Gymnastik-Schulleiter« wurde am 20. November 1955 anläßlich einer Zusammenkunft der Leiterinnen und Leiter der privaten deutschen Gymnastik-Ausbildungsstätten gegründet.

Після деякої обробки з Ghostscript 9.02 (64-бітна Windows) я отримую цей файл:

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

Зараз перше речення виглядає дивним - перед останнім символом кожного слова є додаткове місце.

Der »Bun d Deutsche r GymnastikSchulleiter« wurd eam 20. Novembe r 195 5 anläßlic h eine r Zusammenkunf t der Leiterinne n un d Leite r de r private n deutsche n GymnastikAusbildungsstätte n gegründet.

Це має головний негативний ефект, що ви не можете шукати цілі слова в програмі Acrobat Reader. Я можу відтворити ефект за допомогою наступного мінімального параметра, встановленого для Ghostscript:

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

Будь-які ідеї?

Я вважав цю цікаву проблему і ближче познайомився ...

По-перше, я використовував qpdfінструмент командного рядка для розтискування потоків даних PDF, щоб я міг краще бачити вихідні коди обох файлів:

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

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

Переглядаючи одне з перших випадків, коли вставляється додатковий простір (це оригінальний рядок "Bund Deutscher Gymnastik-Schulleiter", що перетворюється на "Bun d Deutsche r GymnastikSchulleiter" ), я знаходжу такі фрагменти PDF:

In qdf - from_abbyy.pdf:

( 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

In qdf - 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

Щоб трохи зрозуміти, що означають використовувані тут графічні оператори PDF, ось короткий список:

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

Як бачите, Ghostscript замінив оригінальний оператор Tm( текстова матриця ) оператором Td( переміщення поточної точки тексту ), і він також додав додатковий 2.16501 0 Td... Я не знаю, чому це. Я надішлю звіт про помилку в bugzilla Ghostscript [*] і побачу, чи зацікавлені вони в його вирішенні.

Зауважте, що ця проблема не виникає, якщо я використовую Linux Acrobat Reader 9.4.2 і використовую дію меню "Файл -> Зберегти як текст ..." . У цьому випадку додаткових пробілів немає (але кілька зайвих рядків). У Linux також текст не є належним чином шукати, а також показує додаткові пробіли під час копіювання пасти ....

^{[*] Я оновлю тут номер номера помилки, коли я це зробив.}

Оновлення:

Поміркувавши трохи більше про заміненому Tmоператорі, я думаю, що це не повинно бути корінь проблеми.

Зрозумівши це, я намагався здійснити перетворення з Ghostscript v8.71 замість v9.02. І що мені сказати? Проблема copy'n'paste не виникає при виведенні v8.71!

Це означає: в Ghostscript 9.02 є проблема, якої не було в 8.71. Швидше за все, це стосується метрики шрифту, вбудованої у вихідний PDF. Тому що наведені вище фрагменти PDF такі самі, як у випуску v8.71, як у виведенні v9.02 ....

Оновлення 2:

URL-адреса помилки в багзіллі Ghostscript:

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

Оновлення 3:

Здається, ця помилка тим часом виправлена. Я не бачу, щоб це сталося з версіями Ghostscript, з якими я знову перевірив: поточний Git (v9.10GIT), ні з Ghostscript v9.06.

Якщо ви скануєте сторінку з текстом у PDF та запустите програму OCR на ній, текст буде доданий на сторінку, але "режим візуалізації тексту" встановлено невидимим. Він є, але він не відображається на екрані (або на папері, якщо він надрукований). Що ви бачите або друкуєте, - це оригінальне відскановане зображення.

Як ми можемо зробити невидимий текст видимим?

Що ж, ми можемо відредагувати PDF ... PDF-код для встановлення візуального перегляду тексту:

3 Tr

Ви не можете знайти цей рядок (поки) в оригіналі from_abbyy.pdf, а також у from_ghostscript.pdf, оскільки частини PDF-файлів стиснуті. Тож ми їх максимально стискаємо за допомогою qpdf:

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

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

Тепер ми можемо легко знайти верхній рядок (і у кожному файлі є лише одне виникнення).

Переключимо це на один із видимих ​​режимів візуалізації тексту. Загалом ми можемо вибрати один з цих 8 режимів візуалізації тексту:

 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

Якщо я використовую режим "заливки", текст з OCR, мабуть, виглядатиме не так добре на нижньому зображенні сканування. Тому я віддаю перевагу "інсультному" варіанту. Тому я просто змінюю вище рядка, щоб прочитати

 1 Tr

Переглядаючи цей модифікований PDF, мені це не подобається, оскільки ширина лінії за замовчуванням занадто товста на мій смак. Також колір контуру контуру - чорний (за замовчуванням); Я вважаю за краще червоний, щоб мати контраст із оригінально відсканованими формами. Тому я додаю деякий код в передній частині цього рядка, який встановлює ширину рядка на чверть пункту:

 .25 w

та деякі інші, щоб встановити колір обведення червоним:

 1 0 0 RG

Тепер повний рядок звучить так:

 .25 w 1 0 0 RG 1 Tr

Це все.

Зауважте, що наша маленька маніпуляція пошкодила файл, оскільки його "TOC" (в технічному відношенні: його xrefтаблиця) тепер більше не буде дійсним. Acrobat Reader або Acrobat Professional все-таки відкриють його (навіть не поскаржившись) і мовчки "відновлять" розділ файлу xref. Інші переглядачі PDF можуть відхилити файл, але поки що нам все одно ...

Ось скріншоти результату: (Перший знімок екрана збільшується до ширини вікна.) (Другий знімок екрана збільшується на 800%.)

Червоні контури - це відсканований текст, який стає видимим зараз, як ми цього хотіли.

Я провів ту ж процедуру, що описана вище для обох файлів from_abbyy.pdf та after_ghostscript.pdf . Я відкрив обидва результати у двох різних екземплярах Acrobat Reader. Якщо ми зробимо обидва масштаби на одне і те ж значення і максимізуємо обидва вікна, тоді легко переключити подання між обома файлами за допомогою [alt]+[tab]. Це хороший спосіб виявити навіть найтонші відмінності візуалізації між двома файлами PDF.

Мій результат такий: між входом Ghostscript (v9.02) та його результатом для цього файлу немає жодного пікселя. Але є велика різниця, якщо ви хочете скопіювати текст 'пасти' ...

Я не бачу описаної проблеми. Я відкрив PDF файл "після" за допомогою Acrobat Professional 9.0, і текст скопійовано та вставлено правильно.

Ghostscript повністю інтерпретує файл PDF та створює новий файл PDF на основі того, що він інтерпретував, він не має відношення до оригінального файлу, окрім того, що він записує положення тексту.

Через багатий набір функцій PDF можна розмістити символи в одному місці за допомогою декількох різних методів. Таким чином, немає нічого поганого або несподіваного, як GS виробляє PDF-файл.

Зважаючи на те, що текст можна зберегти правильно, це питання евристики Acrobat, яка вирішує, чи два сусідні символи поруч чи не мають пробіл, коли вони обробляються послідовно ASCII.

Я не вірю, що проблемою можуть бути вбудовані метрики шрифту з тієї простої причини, що шрифт не вбудований :-) Шрифт, який використовується, - це Helvetica, який не вбудований у документ, і так Acrobat (для мене щонайменше) використовує ArialMT. Зауважте, що "оригінальний" PDF-файл також не містить шрифтів.

Зрештою я перегляну повідомлення про помилку, але це не скоро, і я сумніваюся, що ми можемо (або зробимо) з цим зробити. Мені здається, це неминучий наслідок евристики. Це може допомогти вбудовувати шрифти, щоб принаймні вони були узгодженими.

З повідомлення про помилку Ghostscript за адресою:

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

Зараз мені вдалося відтворити проблему, і це не регресія з 8.71, її прогресування (та зміна Adobe).

8.71 постачається з помилкою, через яку він написав недійсні CMOS ToUnicode. Оманливі та суперечливі документи Adobe призводять до того, що CMap пишеться як CMap, коли насправді ToUnicode CMaps мають свої, несумісні, правила.

CMOS-адреси ToUnicode зазвичай використовуються лише для пошуку та копіювання / вставки. Як випливає з назви, вони використовуються для відображення кодів символів у кодових точках Unicode. ToUnicode CMap у файлі PDF 8,71 не використовується, оскільки він недійсний, вірний у наступних версіях є дійсним, і Acrobat, як відомо, ним користується.

Здається, що в програмі Acrobat Reader до 9.2 включаючи наявність даних ToUnicode не має ніякої різниці. В якийсь момент після 9.2 механізм пошуку змінився, і, як видається, Acrobat використовує два різні механізми, залежно від того, чи присутній ToUnicode CMap. Я не маю доступу до Acrobat Pro після 9.2 і лише нещодавно встановлений Reader X, у мене немає нічого середнього.

Метод "без Unicode" працює на всіх версіях Acrobat, метод "Unicode" не працює в нових версіях.

Я показав це, пробіливши між собою посилання на ToUnicode CMap від FontDescriptor. Якщо потрібно, я можу зробити різні файли доступними, але вони великі, оскільки вони декомпресуються.

Оскільки пошук є евристичним зусиллям у форматі PDF, гарантувати результат не вдасться. Зміна поведінки пов'язана з Acrobat, а не Ghostscript, і зміна Ghostscript полягала в тому, щоб виправити справжню помилку, тож прогресія, а не регресія.

Для того, щоб перевірити, чи ця проблема пов’язана з «вбудованістю» шрифту чи ні, я здійснив чергове перетворення в Linux. Я використовував цей командний рядок для того, щоб Ghostscript вбудовував використовувані шрифти:

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

Ghostscript покаже цей вихід:

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 . Таким чином, більше не ArialMT , як він використовувався для візуалізації на екрані Acrobat Reader як заміну відсутньої Helvetica (див. Також коментарі користувача701996 вище). Зауважте, що Ghostscript перейменує цей шрифт у Helvetica, як тільки він буде вбудований. Але це не проблема, тому що NimbusSanL був створений як клон Helvetica ...

Однак навіть для цього вихідного PDF-файлу copy'n'paste з Acrobat Reader не буде добре працювати. Незважаючи на те, що Reader більше не потребує використання ArialMT для заміни Helvetica. Тепер Reader використовує вбудований NimbusSanL / Helvetica-клон.

Поки ми встановили ці факти щодо копіювання тексту з програми Acrobat Reader або Acrobat Professional:

• Вихід Ghostscript v9.02 працює недостатньо добре для цього файлу.
• Це справа в тому, що шрифт вбудований GS або він не є.

• Це стосується GS для Windows XP, а також GS для Linux.

• Вихід Ghostscript v8.71 працює досить добре для цього файлу.

• Це справа в тому, що шрифт вбудований GS або він не є.

• Це стосується GS для Windows XP, а також GS для Linux.

• Навіть для виведення , де copy'n'paste зламаний, Зберегти як текст ... робить.

Я досі не розумію, чому так має бути. Але це чітко виглядає як якась (може бути незначна) регресія Ghostscript на шляху від v8.71 до 9.02.

Тепер спробуємо інше програмне забезпечення для перегляду PDF-файлів із «критичними» PDF-файлами:

• Adobe Reader X всередині Wine в Linux: copy'n'paste b0rken так само, як і в версії 9.4.4.
• Evince v2.32.2 в Linux: працює copy'n'paste.
• PDFXChange Viewer 2.5 (збірка 191) на Windows XP Prof: copy'n'paste працює.
• MuPDF зчитувач 0.8 в Linux: не знаю, як скопіювати пасту - але "пошук" працює бездоганно.
• Знайдений с.т. називається "PDF Viewer 0.1.7" в Linux: copy'n'paste працює.
• SumatraPDF v1.5 всередині Wine на Linux: копіює пасти працює.
• SumatraPDF v1.5.1 у Windows XP: копіює пасти працює.
• FoxitReader 4.3.1.0113 в Windows XP: копіює пасти працює.
• Nitro PDF Reader у програмі Wine на Linux: копіює пасти.

Зауважте, є ще інші, але дуже незначні відмінності між усіма "працюючими" читачами PDF, де мій вердикт був " copy'n'paste" . Такі, як пропущений тире, або кілька подвоєних пробілів між словами там, та інші подібні речі ... Я зараз не пояснюю, чому це може бути, але, мабуть, це та сама першопричина, чому існує великий розрив між продуктами Adobe (які не мають робочої copy'n'paste для цього файлу) - одна гама, а інша - інша.