Склейка росыпи pdf в одно pdf-блобище

Смотря под какой лицухой. Есть бодрый mupdf, но там дуал, если это не «для себя» то платить. Если pdfium и биндинги к пистону. Если podofo, биндинги сделать легко но весь файл в память высасывает и медленный на больших файлах шопесец

Попробуй первые два, они вроде могут потоком читать/писать

Предвкушаю амбивалентно ныряние в формат структуры pdf - всякие флатены укуренные

вопрос упирается по факту как флашить смерженное в процессе докидывания очередных кусочков

что pymupdf что pypdf2 отжирают память(озу) в размере 70%-130% исходного набора (конечного файла)

блин как по басурмански поточная склейка? пока не выгугливается :(

incremental merge?

что pymupdf что pypdf2 отжирают память(озу) в размере 70%-130% исходного набора

Второе да, а первое - странно. Он точно умел с потоком работать. На англ ищи streaming. Pdfium тоже точно умел, вернее там смотря как напишешь write, если в пистоне то ctypes и буфер.

Но вообще pdf поточно хреново обрабатывается если в нем есть хоть один апдейт и если он не линеаризован. Тебе надо в любом случае пройти по всему файлу, найти там все таблицы ссылок (которые для не-линеаризованных в конце каждого апдейта) и разрешить все объекты наложив на них все изменения всех апдейтов. В общем случае это довольно геморройно.

Incremental там update, а тут скорее streaming merge

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

фроде циклится по грязному doc.inser_pdf(next);doc.saveIncr();doc.close();doc.«reopen» оно - память «ровно» размер очередного кусочка - но :( из за закрытия открытия и прочего получается медленней когда памяти на весь блоб достаточно - выгрыш тока когда итоговый приближается к размеру оперативы

smallpdf.com

эээ оно список файлов эдак 100к спортфелит?

пока вроде как зогдачка на две части - как не гоняя сами файлы сшить их словари(т.е построить переводы из старых словарей в итоговый) и финальным проходом с новым словарём всё «заинкрементить»

пока хватает быстрой памяти узкое место чтение запись при билде мегаpdf

когда же память заведомо недостаточно

saveIncr - но оно каждый раз при сохраниние по факту добилдивет словарь и когда ид>т следующий чанк то по ходу проходит линейно во размазанному словарю что да>т линейное замедление вроде как

забавно насколько тонок слой цивилизации если достаточно обычная задача на чуть больших величинах деградирует на отличненько

как ты представляешь мердж 1 Тб ?

ждем тему «чем открыть терабайтный pdf»

Никак. А зачем?

эээ оно список файлов эдак 100к спортфелит?

Хз, в стандарте ограничений на этот счёт емнип нету. Но конечно можно нарваться на переполнение где-нибудь

пока вроде как зогдачка на две части - как не гоняя сами файлы сшить их словари(т.е построить переводы из старых словарей в итоговый) и финальным проходом с новым словарём всё «заинкрементить»

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

В общем (ключевое слово - общем) случае склейка пдф страница за страницей, по опыту, это путь в никуда, это реально очень сложно даже без оптимизации по памяти. И библиотеки как ты понимаешь пытаются реализовать именно общий случай.

Портфолио придумали именно для этого, потому что скажем эцп тупо запрещает тебе сшивать файлы. Плюс в этом случае у тебя вместо одного плоского xtef table на 100500 позиций будет 100500 вложенных файлов со сравнительно небольшими таблицами. Реально, попробуй этот вариант, может взлетит

Кстати

PDF itself has one architectural limit. Because ten digits are allocated to byte offsets, the size of a file is limited to 10 10 bytes (approximately 10GB)."

это если и было то в до PDF 1.5

ща спокойно merge - одно повторюсь не удобно так как «файловая структура» по факту размазывается по итоговому файлу - по происходит квадратичное замедление ибо при обьединение словарей происходит его линейное сканирование - не охота нырять в си-реализации что-бы получить ускорение чисто на задачах слияния при подобных файлах

охото чисто подёргать либы = пока лучшим вариантов (из 3ех) оказалась mupdf

вдруг есть ч> для слияния более быстрое и заточенное на большие многотысячестроничные файлы?

зы/ портфолио не подходит :(

1Тб это чисто в идеале по факту итоговый файл будет врядли больше 64G - получается при текущих реализациях при синтезе такого файлы жетально от 128G рамы для минимизации свапа

Более быстрого нет, чисто из-за сложности открытия pdf «в общем виде». Там есть тонны optional и by-default вещей которые даже в стандарте особо не фигурируют, их можно найти только закидыванием файла в акробат, сохранением и изучением в каком-нибудь itext

Не питон но qpdf довольно бодро из баша работает с pdf (вытащить диапазон страниц в файл, склеить несколько pdf)