struct.error: для распаковки требуется строковый аргумент длиной 16

TL; DR

Спасибо @mkl и @hynecker за дополнительную информацию... Тем самым я могу подтвердить, что это ошибка в pdfminer и вашем PDF. Всякий раз, когда pdfminer пытается получить встроенные файловые потоки (например, определения шрифтов), он выбирает последний в файле перед endobj. К сожалению, не все PDF-файлы строго добавляют конечный тег, поэтому pdfminer должен быть устойчив к этому.

Быстрое решение этой проблемы

Я создал патч, который был отправлен в виде запроса на включение на github. См. https://github.com/euske/pdfminer/pull/159.

Подробная диагностика

Как упоминалось в других ответах, причина, по которой вы видите это, заключается в том, что вы не получаете ожидаемое количество байтов из потока, поскольку pdfminer распаковывает данные. Но почему?

Как вы можете видеть в трассировке стека, pdfminer (правильно) определяет, что у него есть шрифт CID для обработки. Затем он обрабатывает встроенный файл шрифта как шрифт TrueType (в pdffont.py). Он пытается проанализировать связанный поток (идентификатор потока 18), считывая набор двоичных таблиц.

Это не работает для 2.pdf, потому что у него есть текстовый поток. Вы можете увидеть это, запустив dumppdf -b -i 18 2.pdf. Я положил начало здесь:

/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo << /Registry (Adobe) /Ordering (UCS) /Supplement 0
>> def /CMapName /Adobe-Identity-UCS def
...

Итак, мусор на входе, мусор на выходе... Это ошибка в вашем файле или в pdfminer? Что ж, тот факт, что другие читатели могут с этим справиться, вызвал у меня подозрения.

Покопавшись еще немного, я вижу, что этот поток идентичен потоку с идентификатором 17, который является cmap для поля ToUnicode. Беглый взгляд на спецификацию PDF показывает, что они не могут быть одинаковыми.

Углубившись в код, я вижу, что все потоки получают одни и те же данные. Ой! Это ошибка. Причина, по-видимому, связана с тем, что в этом PDF-файле отсутствуют некоторые конечные теги, как отметил @hynecker.

Исправление состоит в том, чтобы возвращать правильные данные для каждого потока. Любое другое исправление, просто проглатывающее ошибку, приведет к использованию неверных данных для всех потоков и, таким образом, к неправильным определениям шрифтов.

Я считаю, что прилагаемый патч решит вашу проблему и должен быть безопасным для использования в целом.

Я исправил вашу проблему в исходном коде и попробую ваш файл 2.pdf, чтобы убедиться, что он работает.

В файле pdffont.py я заменил:

class TrueTypeFont(object):

    class CMapNotFound(Exception):
        pass

    def __init__(self, name, fp):
        self.name = name
        self.fp = fp
        self.tables = {}
        self.fonttype = fp.read(4)
        (ntables, _1, _2, _3) = struct.unpack('>HHHH', fp.read(8))
        for _ in xrange(ntables):
            (name, tsum, offset, length) = struct.unpack('>4sLLL', fp.read(16))
            self.tables[name] = (offset, length)
        return

этим:

class TrueTypeFont(object):

    class CMapNotFound(Exception):
        pass

    def __init__(self, name, fp):
        self.name = name
        self.fp = fp
        self.tables = {}
        self.fonttype = fp.read(4)
        (ntables, _1, _2, _3) = struct.unpack('>HHHH', fp.read(8))
        for _ in xrange(ntables):
            fp_bytes = fp.read(16)
            if len(fp_bytes) < 16:
                break
            (name, tsum, offset, length) = struct.unpack('>4sLLL', fp_bytes)
            self.tables[name] = (offset, length)
        return

Пояснения

@Набил Ахмед был прав

Для строки foramt ›4sLLL требуется размер буфера 16 байт, который правильно указан в fp.read для чтения 16 байт за раз.

Таким образом, проблема может быть только с буферным потоком, который он читает, то есть с содержимым вашего конкретного файла PDF.

В коде мы видим, что fp.read(16) выполняются в цикле без какой-либо проверки. Таким образом, мы не знаем наверняка, успешно ли он все это прочитал. Например, он может достичь EOF.

Чтобы избежать этой проблемы, я просто break выхожу из цикла for, когда возникает такая проблема.

    for _ in xrange(ntables):
        fp_bytes = fp.read(16)
        if len(fp_bytes) < 16:
            break

В любых обычных случаях это все равно ничего не должно менять.

Я попытаюсь сделать запрос на вытягивание на github, но я даже не уверен, что он будет принят, поэтому я предлагаю вам сделать обезьяний патч и изменить свой файл /home/danil/projects/python/pdfminer-source/env/local/lib/python2.7/site-packages/pdfminer/pdffont.py прямо сейчас.

Это действительно недействительный PDF-файл, поскольку отсутствуют некоторые ключевые слова endobj после трех косвенных объектов. (объект 5, 18 и 22)

Определение косвенного объекта в файле PDF должно состоять из номера его объекта и номера поколения (разделенных пробелом), за которыми следует значение объекта, заключенное в скобки между ключевыми словами obj и endobj. (глава 7.3.10 в справочнике в формате PDF)

$ grep --binary-files=text -B1 -A2 -E " obj|endobj" 2.pdf
...
18 0 obj
<< /Length 451967/Length1 451967/Filter [/FlateDecode] >> 
stream
...
endstream                 % # see the missing "endobj" here
17 0 obj
<< /Length 12743 /Filter [/FlateDecode] >> 
stream
...
endstream
endobj
...