Взгляните на org.apache.pdfbox.examples.util.PrintTextLocations.Я использовал его довольно часто, и это очень полезно для анализа расположения элементов и ограничительных рамок в документах PDF.Также были обнаружены элементы, напечатанные белыми чернилами или за пределами области печати (предположительно, водяные знаки на документах или «забытые» объекты, скрытые от глаз автора).
Пример использования:
java -cp app/target/pdfbox-app-1.5.0.jar org.apache.pdfbox.examples.util.PrintTextLocations ~/tmp/mydoc.pdf >~/tmp/out-text-locations.txt
Вы получите что-то вроде этого:
Processing page: 0
String[53.9,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=4.6679993]A
String[58.568,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=2.6640015]f
String[61.232002,59.856995 fs=-6.0 xscale=6.0 height=-3.666 space=1.3320001 width=1.6679993]e
...
, которое вы можете легко проанализировать и использовать для построения положения элемента, ограничительной рамки и «потока» (траектории через все элементы) и т. Д. Длякаждая страницаЯ уверен, что вы уже знаете, вы обнаружите, что PDF практически невозможно преобразовать в текст.На самом деле это просто графический формат описания (например, для принтера или экрана), а не язык разметки.Вы можете легко создать PDF-файл, в котором будет напечатано «Hello world», но он будет случайным образом перескакивать через позиции символов (и при этом использовать другие символы, отличные от любой кодировки ISO, если вы того пожелаете), что делает PDF очень трудным для преобразования в текст.Нет понятия «слово» или «абзац».Например, документ из двух столбцов может быть кошмаром для анализа текста.
Во второй части вашего вопроса у меня были хорошие результаты при использовании xpdf версии 3.02, после исправления Xref.cc (make XRef::okToPrint(), XRef::okToChange(), XRef::okToCopy() и XRef::okToAddNotes() все возвращаются gTrue).Это для обработки заблокированных документов, а не зашифрованных (для этого есть другие утилиты).