marikk пишет:

Но проблему непоследовательности страниц таким подходом не побороть.

Брр.. Опять не понял... Я в этих PDFах не бум-бум. Попробуйте более широко описать задачу.

Все вы правильно сделали. Ошибся немного с переводом документации. Спасибо

Но проблему непоследовательности страниц таким подходом не побороть.

Брр.. Опять не понял... Я в этих PDFах не бум-бум. Попробуйте более широко описать задачу.

Оно ?

так то оно да. Большое спасибо за старания.
В большинстве случаев такой парсинг будет уместен (если добавить пару условий), на первое время он будет взят за основу.
Но проблему непоследовательности страниц таким подходом не побороть. Наглядный пример:

1531 0 obj
<</Count 86/Type/Pages/Kids[1532 0 R 1533 0 R 1534 0 R 1535 0 R 1536 0 R 1537 0 R 1538 0 R 1539 0 R 1540 0 R]>>
endobj
1532 0 obj
<</Parent 1531 0 R/Count 10/Type/Pages/Kids[1545 0 R 1 0 R 3 0 R 11 0 R 13 0 R 190 0 R 339 0 R 510 0 R 597 0 R 602 0 R]>>
endobj
1533 0 obj
<</Parent 1531 0 R/Count 10/Type/Pages/Kids[604 0 R 616 0 R 623 0 R 629 0 R 665 0 R 678 0 R 689 0 R 702 0 R 710 0 R 723 0 R]>>
endobj

1532 0 obj -- 1 страница
604 0 obj -- 21 страница.
Такое будет встречаться редко, но все равно хотелось бы иметь возможность работать со всем, а иначе теряется смысл "проекта".

#!/usr/bin/env python
#_*_coding: utf-8_*_
import sys, re
def Find(patt, text):
    match = re.findall(patt, text)
    if match:
        for block in match:
            if '/Type /Page\n' in block:
                print (block + '-----------------')
    else : print ('Не найдено...')

f = open(sys.argv[1], 'r')
data = f.read()
patt = re.compile(r'\sobj([\s\S]+?)endobj') 

Find(patt, data)

Оно ?

  obj
.......
/Parent X X obj
/Type /Page
.......
endobj

если точнее так

  obj
.......
/Type /Page
.......
endobj

?

Сразу возникают такие проблемы:
1. Существуют много блоков помошников(определяющие тип шрифта, содержимое), но их отследить не проблема.
2. Также могут существовать блоки которые не входят в структуру. Он является конечным, он имеет родителя, но он невидим в файле, поэтому его брать не следует

1. Ну так проблема или нет
2. Я так понимаю информация об их видимости так же присутствует. Если это может идти от родителя - придется хранить массив скрытых блоков. (А точнее, полагаю, массив идентификаторов таких блоков). И если родитель очередного блока присутствует в этом списке, то и этот блок записываем в "черный" список.

Ну т.е. глядя на блок мы можем точно сказать имеет он детей или нет. Если не имеет - то он конечный, если имеет - нет..... Соответственно если пробежать по всем блокам и анализировать конечный он или нет.
Критерий наличие детей Да/Нет   (если такой параметр есть в описании блока)

Если параметра нет. А есть указатель на родителя. То бежим по файлу записываем в массив блоки (или их смещения в файле). Как только встречаем блок имеющий указатель на родителя. Выкидываем этого родителя из нашего массива.

И в том и в другом случае один проход.

Или я туплю в понимании задачи?
С PDF сам не работал, только бегло взглянул..... Но вроде как-то так

Сразу возникают такие проблемы:
1. Существуют много блоков помошников(определяющие тип шрифта, содержимое), но их отследить не проблема.
2. Также могут существовать блоки которые не входят в структуру. Он является конечным, он имеет родителя, но он невидим в файле, поэтому его брать не следует

А можно пример файла?

marikk пишет:

Конечный

/Type /Page

Т.е. конечный объект однозначно определяется?

Откройте в текстовом редакторе любой pdf файл, вот вам пример. Да глядя на блок мы можем точно сказать нужен он или нет.

угу. См. выше, расход памяти и прочее (время и т.д.) уже подробно рассмотрено боле 50и лет назад. Всё уже украдено до нас.

PDF вроде как ТС сказал.
Список нужен конечных элементов.  В зависимости от задачи можно хранить смещения в файле. Я глянул пару pdfин нету там инфы о детях - только о родителях.... (хотя может pdf был "не тот" - надо доку читать) А если так, то полного обхода файла не избежать.

Но вообще да.... Задачу бы поподробнее узнать.....

 

Полезно покурить предварительно Кнута

Можно об этом поподробней ?

Искусство Программирования
Том 1
2.3 Деревья. Страница 352 русского издания.

угу. См. выше, расход памяти и прочее (время и т.д.) уже подробно рассмотрено боле 50и лет назад. Всё уже украдено до нас.

marikk
1. если это какая-то VCS - используйте например ртуть, и не * голову себе, нам, и вашим коллегам.
2. если это не VCS, но СУБД, используйте например MySQL, SQLite  и не * голову себе, нам, и вашим коллегам. (вы выше рассмотрели классический случай реляционной БД, отношение "один ко многим", если я правильно понял)
3. Если это не п1 и не п2, то конкретизируйте задачу, расскажите, почему это не п1 и п2.

я рад за вас, товарищи телепаты =), но поясните для простых смертных, задача то в чём? мне. так... из спортивного интереса узнать...

Вроде, необходимо вычислять подозрительные объекты в Матрице...