LINUX.ORG.RU

pdf - усушка унд утруска

 , ,


1

1

есть pdf -

зогдачка минимизировать размер pdf ибо программа генерирующая потоки создания страниц - настолько мусорна что даст 100 очков в перёд легендарной способности ворда экспортировать в html

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

вот какие есть инструменты?

на данный момент есть костыльное:

cpdf -decompress in.out -o m.pdf
myUkur.py m.pdf m_ukur.pdf
cpdf -squeeze m_ukur.pdf -o out.pdf

где в myUrkur попытка викинут эвристиками из текстовых потоков управления выводом команды которые дублирируются -например повтор одного и тогоже действия которое ничего не меняет;

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

слияние в одну команду печать идующих подряд с одинаковыми параметрами текстовых строк например TJ идущих подряд выводящих массивы отдельных символов с выставлением идентичных свойств и этих строк - сворачивание в одну команду с одной строкой

удаление промежуточных пар ET … BT - если команды … не влияют на тексты по соседних блоках



Последнее исправление: qulinxao3 (всего исправлений: 4)

Ответ на: комментарий от mrjaggers

cpdf - не оптимизирует программу построения образа страницы(то что есть по факту урезанная postscript программа без циклов и условий)

cpdf - может делать различные преобразования объектов и их сборку мусора и прочие вещи которые по факту и отличают pdf от postscipt

у меня же ща проблема уменьшение объёма кода строящего страницу

умей я замещать содержимое потока объекта напрямую то cpdf можно было бы и не использовать

но ща так как я не меняю length в словаре обьекта у которого стрим уменьшаю cpdf ещё и лечит файл

qulinxao3
() автор топика
Ответ на: комментарий от mrjaggers

это всё по ссылке меняет качество графических объектов и играется с фильтрами потоков ну и сборка мусора и отказ от линеаризации что даёт уменьшение

у мя же уменьшение кодовой части строящая страницы из команд операторов pdf типо q Q Td Tj TJ ri f cm и прочая

qulinxao3
() автор топика
Ответ на: комментарий от mrjaggers

по сути перекомпиляция pdf operators (из https://ghostscript.com/~robin/pdf_reference17.pdf страницы 985-988)

APPENDIX A
AOperator Summary

TABLE A.1 PDF content stream operators 

b B b* B* BI BMC BT BX c cm CS cs d d0 d1 Do DP 
EI EMC ET EX f F f* G g gsh i ID j J K k l m M 
MP n q Q re RG rg ri s S SC sc SCN scn sh T* Tc
Td TD Tf Tj TJ TL Tm Tr Ts Tw Tz v w W W* y ' " 

задача по факту написать оптимизирующий компилятор у которого на входе вот такой вот вариант postscript’а а на выходе эквивалентная программа в смысле получаемого оттиска но с меньшим количеством команд - вот так вот просто

qulinxao3
() автор топика
Ответ на: комментарий от Anoxemian

пилить

там итак текст - просто например вместо вывода строки стразу с выставленым с

оно выдаёт массив символов с растоянием между каждым символом и прочие сны разума

ocr возможно имеет смысл таблицы и прочий графоний

ибо текст итак очевидно где и какой

qulinxao3
() автор топика
Ответ на: комментарий от DumLemming

пилит

ну отчего у вас нет 24 пары хромосом а?

то что вы предлагаете меняет представление граф обьектов что не есть проблема

проблема излишний код в описании «чертежа» страницы который есть по сути поток постскрипт команд тока в виде уместном в pdf т.е одно(двух) буквенные мнемоники но на тех же структурах данных

вот что из вышеуказанного в стартовом посте натолкнуло ВАС на такие глубокоинформативные о ваших когнитивных способностях советы воспользоваться базовыми опциями гхостскрипта - которые ну ваще никак не влияют на потоки операторов в пдф?

qulinxao3
() автор топика
Ответ на: комментарий от DumLemming

вам как эксперту по :

спаривания женщины низкой социальной ответственности и транссексуала,

стоит пройти курсы повышения своей экспертности - а то ч>т в калашный ряд вам удалось попасть

qulinxao3
() автор топика
Ответ на: комментарий от ya-betmen

чисто в сравнении

у соседей на 4к символах 13 кб на страницу

у нас на 8к символах дай бог если не больше 50к на страницу

это при усреднении когда размер фонтов и графония на страницу стремится к нулю ибо пачти по 1000 страниц и более

т/е на 200к страницах у соседей 800мб которые ещё и жмутся cpdf -squeeze до ~400 у нас на тех же ~200к страницах но наших сpdf отжимает максимум 5% от выдаваемых 8.5гигов

qulinxao3
() автор топика
Ответ на: комментарий от qulinxao3

у соседей на 4к символах 13 кб на страницу

А разметка и число символов (печатных) на странице одинаковое?

Если зиповать ваши пдф и соседские разница в размере заметная?

Я бы смотрел в сторону правки исходного генератора, если она невозможна, то в сторону выдирания текста и перегенерации страницы (если разметка простая).

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

апропос: спасибо за дайджест по треду - собственно цель ныряния в pdf и наколеночный конвертер уменьшивший на 40% для того и - что бы показать что меньший технически возможен чтоб не отнекались

у соседей текста на странице 4к у нас 8к

и да у них верстка по правому краю и равный интервал через cm и Tj

у нас по ширине да и ещё вывод через TJ и смещения указаны разные между каждым символом а сами символы как 4 hexchar в <> - у них же непосредственно бинарные строка

просто примечательно как одно и тоже может быть по разному сделано - у соседей соседи делали для себя

у нас - коробочный продукт

вот и понимай про NIH

зипование не приносит ничего ни у нас ни у соседей

при том что cdf -squeeze у соседей уменьшает в двое, у нас на 5%

qulinxao3
() автор топика
Ответ на: комментарий от mrjaggers

прст оказалось не сама сшивка timuconsuming а чисто пересылка данных

до типографии линия видимо не очень качественная поэтому чем больше файло туда тем дольше откачка - рост больше чем линейный

поэтому ща узкое место гоняние данных

поэтому будь файлы с нашей стороны раза в 2 меньше время отдачи было бы меньше раза в 4

ну и сшивка на 10% быстрее (вместо 20 минут в 9 потоков на 8 ядрах было бы 18 - чисто за сч>т уменьшения файлов и потребной памяти и уменьшение трешенга из этого)

ну да соц ревнование ага

qulinxao3
() автор топика
Ответ на: комментарий от qulinxao3

ocr чего и зачем?

Я понял как взять готовый ваш pdf и перегнать через OCR, чтобы выкинуть все последовательности кривые и оставить только текст. Ну как бы начитать pdf заново, но генератором от OCR-софта. Сработает только с простым форматированием.

Loki13 ★★★★★
()
Ответ на: комментарий от qulinxao3

у нас по ширине да и ещё вывод через TJ и смещения указаны разные между каждым символом

Тут вряд ли что-то можно придумать в атоматическом режиме

а сами символы как 4 hexchar в <>

С этим разве qpdf in.pdf out.pdf не может помочь?

ya-betmen ★★★★★
()
Ответ на: комментарий от Loki13

OCR

Удаление глад через зад? Текст из пдфа без проблем вынимается, но я так понял, что у ТС там не только голимый текст.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

вся оказалось не так мрачно:

технически есть возможность в софтине генерирующий pdfки - вместо набора прямоугольников для qrcode выдавать изображение в png - чехарду со шрифтами походу можно убрать отказавшись от richText полей и использовать чисто Label

но вот чё забавно - так как прога генерирующая qrcode как набор квадратиков в pdf Content stream - криво трансформации делает поэтому вместо выставления метрики такой что квадратик становится единичного размера - оно генерит для всех 4 полей re десятичные с 3 знаками после запятой - врезультате между соседними чёрными пикселями могут быть зазоры :)

если же предварительно сделать sz 0 0 sz 0 0 cm то размеры станут единичными и всё слитно :) ну и простое слияние идущих подряд чёрных пикселей уменьшает число прямоугольников в 2 раза в целом

т.е. при правильном алго вывод qr-code как набора re команд с финальным f - Content stream при его flateDeflate сжатии оказывается меньше места занимает чем встраивание картинки походу

вообщем

есть ещё более дубовый вариант сохраняющий красивости - загнать в шаблон странице те части которые общие не только в части картинок - но и информационой части которая общая - технически это должно дать уменьшение на 1/3 - т.е типо обратного osr - тот кусок красивого текста тоже перегнать в картинку и хранить её в одном экземляре на весь документ делая ссылку на каждой странице на эту «картинку»

т.е если правильно

qulinxao3
() автор топика