Если определить структуру текста в PDF-документах так сложно, как читатели PDF делают это так хорошо?
Я пытался написать простое консольное приложение или скрипт PowerShell для извлечения текста из большого количества PDF-документов. Есть несколько библиотек и инструментов CLI, которые предлагают сделать это, но оказывается, что ни одна из них не может надежно идентифицировать структуру документа. В частности, я обеспокоен распознаванием текстовых столбцов. Даже очень дорогой инструмент PDFLib TET часто смешивает содержимое двух смежных столбцов текста.
Часто отмечается, что в формате PDF нет понятия колонок или даже слов. Несколько ответов на подобные вопросы на SO упоминают об этом. Проблема настолько велика, что даже требует академических исследований. Эта статья журнала отмечает:
Все объекты данных в файле PDF представлены визуально-ориентированным способом, как последовательность операторов, которые... обычно не передают информацию о текстовых единицах более высокого уровня, таких как токены, строки или столбцы - информацию о границах между такими единицами доступен только неявно через пробелы
Следовательно, все инструменты извлечения, которые я пробовал (iTextSharp, PDFLib TET и Python PDFMiner) не смогли распознать границы текстовых столбцов. Из этих инструментов PDFLib TET работает лучше всего.
Тем не менее, SumatraPDF, очень лёгкий PDF Reader с открытым исходным кодом и многие другие, подобные ему, могут идеально идентифицировать столбцы и текстовые области. Если я открою документ в одном из этих приложений, выделю весь текст на странице (или даже весь документ с помощью сочетания клавиш CTRL+A) и скопирую его в текстовый файл, текст будет отображен в правильном порядке почти безупречно. Иногда он смешивает нижний колонтитул и текст заголовка в одном из столбцов.
Итак, мой вопрос: как эти приложения могут делать то, что на первый взгляд так сложно (даже для таких дорогих инструментов, как PDFLib)?
РЕДАКТИРОВАТЬ 31 марта 2014 года. Я обнаружил, что PDFBox гораздо лучше справляется с извлечением текста, чем iTextSharp (несмотря на реализацию стратегии на заказ), а PDFLib TET немного лучше, чем PDFBox, но он довольно дорогой. Python PDFMiner безнадежен. Лучшие результаты, которые я видел, получены от Google. Можно загрузить PDF-файлы (2 ГБ за раз) на Google Drive, а затем загрузить их в виде текста. Это то, что я делаю. Я написал небольшую утилиту, которая разбивает мои PDF-файлы на 10-страничные файлы (Google преобразует только первые 10 страниц), а затем склеивает их обратно после загрузки.
РЕДАКТИРОВАТЬ 7 апреля 2014 года. Отменить мой последний. Лучшее извлечение достигается с помощью MS Word. И это может быть автоматизировано в Acrobat Pro (Инструменты> Мастер действий> Создать новое действие). Word to text можно автоматизировать с помощью библиотеки.NET OpenXml. Вот класс, который будет делать извлечение (docx в txt) очень аккуратно. Мое первоначальное тестирование показало, что преобразование MS Word значительно точнее в отношении структуры документа, но это не так важно после преобразования в простой текст.
2 ответа
Однажды я написал алгоритм, который сделал именно то, что вы упомянули для продукта PDF-редактора, который до сих пор является лучшим редактором PDF, используемым сегодня. Есть несколько причин, по которым вы упоминаете (я думаю), но важная - это фокус.
Вы правы, что PDF (обычно) не содержит никакой информации о структуре. PDF заинтересован в визуальном представлении страницы, а не в том, что эта страница "означает". Это означает, что в чистом виде ему не нужна информация о строках, абзацах, столбцах или о чем-либо подобном. На самом деле, он даже не нуждается в информации о самом тексте, и существует множество файлов PDF, в которые вы даже не можете скопировать и вставить текст, не заканчивая бредом.
Поэтому, если вы хотите иметь возможность извлекать отформатированный текст, вам действительно нужно посмотреть на все фрагменты текста на странице, возможно, также принимая во внимание некоторую информацию о линейном искусстве, и вы должны собрать их воедино., Обычно это происходит путем написания движка, который просматривает пробелы, а затем сначала решает, что такое строки, что такое абзацы и так далее. Таблицы, как известно, сложны, например, потому что они очень разнообразны.
Альтернативные стратегии могут быть следующими:
- Посмотрите на некоторую информацию о структуре, которая доступна в некоторых файлах PDF. Некоторые файлы PDF/A и все файлы PDF/UA (PDF для архивирования и PDF для универсального доступа) должны иметь информацию о структуре, которая может быть очень хорошо использована для извлечения структуры. Другие PDF-файлы также могут содержать эту информацию.
- Посмотрите на создателя PDF-документа и разработайте специальные алгоритмы для правильной работы с PDF-файлами. Если вы знаете, что интересуетесь только Word, или если вы знаете, что 99% PDF-файлов, которые вы когда-либо обрабатываете, будут выходить из Word 2011, возможно, стоит использовать эти знания.
Так почему одни продукты лучше, чем другие? Фокус, я думаю. Спецификация PDF очень широка, и некоторые инструменты больше фокусируются на задачах PDF более низкого уровня, а некоторые - на задачах PDF более высокого уровня. Некоторые ориентированы на "офисное" использование, а некоторые на "графику". В зависимости от вашего фокуса вы можете решить, что определенная функция заслуживает большого внимания или нет.
Кроме того, и это может показаться паршивым ответом, но я считаю, что это действительно так, это алгоритмически сложная проблема, и для реализации алгоритма, который намного лучше, чем средний продукт на рынке, требуется всего один гениальный разработчик. Это одна из тех областей, где - если вы сообразительны и у вас достаточно внимания, чтобы уделить этому немного внимания, особенно если у вас есть четкое представление о том, для какого целевого рынка вы пишете, - вы поймете это правильно в то время как все остальные получат это посредственно.
(И нет, я не понял это тогда, когда писал этот код - у нас никогда не было достаточно внимания, чтобы выполнить и сделать что-то действительно хорошее)
Для правильного извлечения форматированного текста библиотека / утилита должна:
- Получить правильную информацию о свойствах шрифтов, используемых в PDF (размеры глифов, информацию о хинтах и т. Д.)
- Поддерживать состояние графики (то есть параметры без шрифта, такие как масштабирование текста и страниц и т. Д.)
- Реализуйте некоторый алгоритм, чтобы решить, какие символы на странице следует рассматривать как слова, строки или столбцы.
Я на самом деле не эксперт в продуктах, которые вы упомянули в своем вопросе, поэтому следующие выводы должны быть сделаны с недоверием.
Инструменты, которые не рисуют PDF-файлы, как правило, имеют меньший опыт в первых двух требованиях. Им не нужно иметь дело с деталями шрифта на более глубоком уровне, и они могут быть не так хорошо протестированы в поддержании графического состояния.
Любой достойный инструмент, который переводит PDF-файлы в изображения, вероятно, рано или поздно узнает о его недостатках в позиционировании текста. И исправление этих ошибок поможет добиться успеха в извлечении текста.