февраль 2016
Исправление поиска/извлечения текста в некорректно созданном pdf файле с внедренными шрифтами TrueType.
Симптомы: в файле не работает поиск, при попытке скопировать части текста получаем набор кракозябров.
На базе утилиты pdf-recode от пользователя 1998. Оригинальный pdf-recode - упакованный exe для Windows. Моя распакованная версия консольная - выкинул зависимости от GUI и от Windows.
pdf-recode корректирует файлы с шрифтами Type1. А у меня в книге "Perl: Специальный справочник" - TrueType шрифты.
Для правильной перекодировки TrueType шрифтов достаточно, чтобы в шрифте был объект /ToUnicode с правильной таблицей соответствий номеров глифов кодам Unicode. Особенность в том, что при внедрении остаются только те глифы, которые используются в файле и глифы идут в порядке использования их в файле, т.е. вперемешку. Нельзя сделать универсальную таблицу перекодировки, более того для каждого шрифта в файле нужна своя таблица.
Не нашел достаточно хорошей библиотеки для обработки готового pdf.
PDF::API2 - заточена на создание новых файлов, внедренные шрифты нужно обрабатывать вручную.
CAM::PDF - не очень хорошо поддерживается, скорее прототип, многое не реализовано.
В результате сделал две утилиты на базе CAM::PDF, взяв за основу код из pdf-recode.
В процессе разработки активно исследовал структуру COS в PDF файлах при помощи itext-rups-5.5.8-jar-with-dependencies.jar.
- pdf-recode.pl - распакованная версия оригинальной утилиты для работы не только на Windows
- listfonts.pl - утилита из дистрибутива CAM::PDF - устанавливается в систему в /usr/local/bin
- pdf_fonts_tounicode.pl - формирование таблиц глифов для внедренных шрифтов и заготовки для таблиц перекодировки
- pdf_write_tounicode.pl - запись данных в поля ToUnicode для внедренных шрифтов из подготовленной таблицы перекодировки
pdf_fonts_tounicode.pl [-h] [-V] infile.pdf [lutfile.pl] [outfile.pdf]
pdf_write_tounicode.pl [-h] [-V] infile.pdf [lutfile.pl] [outfile.pdf]
# install dependencies
cpan CAM:PDF
Попробовать pdf_recode.pl - если результаты не устраивают, тогда пробуем дальше.
- Обрабатываем исходный файл pdf_fonts_tounicode.pl - получаем файл с вставленными в конце дополнительные листы на которых напечатаны таблицы глифов для каждого внедренного шрифта, по одному шрифту на страницу, с действующими символами unicode cопоставленнными глифам, если в шрифтах есть /ToUnicode (может не быть вообще).
- Одновременно создается lut1.pl с заготовками хышей для использованных в файле шрифтов, остается только заполнить пустые места символами, соответствующими глифам из таблиц шрифтов. Можно вставлять символ или шестнадцатиричный код unicode <0000> (сейчас жестко прописана длина в 4 символа).
- По таблицам символов на дополнительных листах редактируем созданный файл lut1.pl, я его переименовал в lut2.pl, чтобы случайно не затереть результаты работы в процессе экспериментов
- Запускаем второй скрипт pdf_write_tounicode.pl с исходным pdf и lut2.pl - если вылезают ошибки исправляем их в lut2.pl были ошибки связанные с символами, которые нужно было экранировать.
Получаем файл - можно проверять работу поиска.
При подготовке служебного файла не всегда можно идентифицировать русские и английские буквы, особенно к концу таблицы, где символы идут вперемешку.
Для идентификации нужно определить каким шрифтом написан нужный нам текст. В Acrobat получить эту информацию напрямую сложно. Хорошо себя зарекомендовала утилита PDF-XChange Viewer. Показывает свойства выделенного текста. Показываемое в программе имя шрифта - это часть имени шрифта после + в свойстве /BaseFont. Оно выведено в коментарии перед началом хэша.
Example:
/TT20 /BaseFont: XPROGH+F9 PDF-XChange Viewer покажет как F9.
Те же имена внедренных шрифтов показывает и Acrobat, но в нем значительно сложнее, если вообще возможно, определить шрифт для выделенного текста.