qr-code усушка унд утряска

Вы пытаетесь запихнуть пдф и куаркод на него в ключ от домофона?

ах еслиб.

есть проприентарная весч

которая генерит сотни pdf - они ващет изначально для одноразовой печати и последующего спама по реципиентам :)

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

а собирать спам идущий в один адрес в одно «письмо»

если делать совсем в лоб там терабайтные обь>мы и время существования вселенной вылазят

сделали так что на входе 1гиг 200к страниц от одного спамера и 8 гиг с похожими 200к страниц от другого спамера - сборка проходит за 20 мин в 8-9 потоков на наколеночном питонце

теперь оказалось узким местом по времени не генерация результата а переход этих 8 затем 9 гигов туда сюда по всяким защищ>ным линиям

и возникла задачка почему у одного спамера вс> занимает 1 гиг а у другого 8

полезли в нуть страниц pdf и изумились

насколько реально не нужно заморачиваться если это не входит в тех зад

поэтому ща какбы сгенирить док из 100 скажем страниц на основе пухлого который по размеру в 2-8 раз меньше исходного и предьявить успешным прогерам на предмет что бы они в своей пропреинтарщине правильно флаги выставили для продуцирования более компактной пачки спама

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

это продолжение успешно запиленной Склейка росыпи pdf в одно pdf-блобище

ЯННП.

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

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

То что Вы предлагаете немного странно выглядит…

1. алгоритм этот придется велосипедить самому

2. степень сжатия будет не факт что выше чем у готового графического формата

3. время отрисовки точно будет хуже

ибо сейчас например qr-code c полукилобайтом текста крапит 7.5к чёрных квадратиков - если просто нарисовать сразу чёрный квадрат и на нём тупо белые пиксили вывести будет явно меньше 2к

Нет

https://www.qrcode.com/en/codes/microqr.html

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

имхо даже слипание идущих подрят в строке битиков в один прямоугольник даст имхо 4ёх кратное сокращение ибо в основном место уходит под 4 координаты x y w h которые ещё и флоаты (да даже если двухбайтные инты) - даже слипание двух подряд в строке чёрных битов ща даст экономию не меньше 1/3 можно конечно заинлайнить битмап в поток построения страницы что вероятней всего и будет

всё таки забавно что на рынке выигрывают наиболее лобовые решения

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

есть например quadtree

али ваще k-d-tree

как структуры данных которые вообщем можно использовать как основу для генерации последовательности команд не перекрывающихся прямоугольников

имхо если прямоугольники могут перекрыватся - должно явно не больше потребоваться для описания того же битмапа

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

скажем так число белых пикселей меньше числа чёрных больше чем не 1

поэтому выставление белых на чёрном - будет короче чем сейчас

даже слипание идущих подрят в строке битиков в один прямоугольник даст имхо 4ёх кратное сокращение

Ну дык архиватор ровно это и делает, только лучше;-)

есть например quadtree али ваще k-d-tree

Деревьев есть много разных, тут это хороший вариант ИМНО.

Но - Вы уверены что изображение не в градациях серого? Не в градациях серого (байт на пиксель) текст как правило выглядит довольно вырвиглазно… а вот архиватор умеет и в градациях серого тоже жать.

всё таки забавно что на рынке выигрывают наиболее лобовые решения

Увы и ах. Но иногда (к счастью) возникают задачи где в лоб не работает и возникает простор для творчества

ну технически будет обычный битмап двухцветный

а вот чисто сравнить с имеющимся потоком квадратиков до скольки можно уменьшить число команд

можно ваще конечно угореть и рисовать полигон чисто рёбрами и заливать - в целом имхо да это общая задача архивирования маски

зыю и да у qr защита от ошибок можно и с потерями но не интресно

реально интересно -

на входе маска на выходе колмогоровской длины программа её выдающая

там ща не градации и вообще не изображение - программа использует плагин который может и img давать - но у них не срослось с маштабированием поэтому в pdf ща например 7.5к строк вида

x y w h ri f\n

при том что w и h например 1.27 и имхо даже команда f не нужна в каждой строке ибо насколько я понял ri добавляет область и не будь в драйвере дисплея оптимизации оно многократно перекрашивает уже зачернёные квадратики

в сквизенном pdf оно по ходу хранится как набор 6 целых и так для каждого пикселя - flatdeflate фильтр потока конечно сжимает это на отлично но всё равно

у аналога на странице 4к текста и две картинке лого в 5кило и изображение qr-кода и порядка 1к команд построения страницы всё это весит около 13 кб при этом cpdf ещё и сквизит файл из 1000 таких страниц ровно в два раза

у «нас же» на странице 8к текста лого 2 кб и порядка 20к команд построения страницы - вес страницы около 50к

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

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

в pdf ща например 7.5к строк вида

рукалицо…

Переписать все через latex;-)

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

Нету ручек - нет конфетки!

Попробуй использовать «жадный алгоритм».

Если тебе сжать двуцветный битмап, то просто перегони его в png. Степень сжатия получится компромиссная (там под капотом слабый по нынешним меркам deflate), но за то это готовое решение с кучей готовых инструментов. Оптимизаторы размера png готовые, oxipng, optipng, и тд https://en.wikipedia.org/wiki/PNG#Optimizing_tools

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

однако как в pdf(соседнем) треде отметил - даже генерация qr-code как последовательности квадратиков re c финальным f - может буквально на порядок быть компактней когда вместо набора флоат перед построением делать sz 0 0 sz 0 0 cm - тогда все числа для re становятся целыми - ну и простейшее запещение подряд идущих квадратиков на один прямоугольник даёт уменьшение в 2 раза команд re

по итогу в сжатом ввиде скрипт вроде оказывается меньше чем битмар png сжатый

Может, лучше генерировать qr коды в виде картинки, а не векторных прямоугольников? А картинку можно сохранить в формате 1 бит на пиксель, а ещё для картинок уже давно придумали алгоритмы сжатия без потерь, которые отлично объединяют идущие подряд пиксели одного цвета.

В pdf точно можно внедрять картинки.

по итогу в сжатом ввиде скрипт вроде оказывается меньше чем битмар png сжатый

А картинка в png имеет 1 бит на пиксель или больше (grayscale или даже rgba)?

c нашей стороны нужен был пруф оф концепт - что бы обычне продакты почесались и причесали - по ходу прикрутят пнг - цель просто в раза 3 уменьшить гоняемые битики в целом.

хз там используется вырвиглазная библиотека построения отчётов - и я смог прикрутить к qr-code компоненту обьект картинки - но там настолько кривая событийная модель что ща в картинке показывает qr-code не текущий у компонента а походу на момент инициализации всего reportа - крч продакты всяко обкурены в той либе так что сделают -

по поводу png - хм возможно я несколько приувеличил ибо синица в руках а журавль пока в небе -

у коллег png 5 килобайтные при том что у мя построение сопоставимого размера qr-кода - текстом меньше 4 кб

жаль что в pdf нельзя в Content stream прикрутить подмену констант типо вместо:

x y 45 45 re
a b 45 45 re

можно было б:

/a 45 def
x y/a/a re
a b/a/a re

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 17%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно. Чтобы векторное представление выигрывало растровое, белых квадратов должно быть в ДЕСЯТКИ раз больше, чем чёрных (и это без сжатия, со сжатием там будет речь о сотнях и тысячах раз уже). Покажите мне такой QR-код.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками (в смысле без высокоуровневых либ) отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

слава dotPeek - покурил реализацию экспорта отчётов в pdf

• лютый энтерпрайз

по картинке - всё норм будет png 1 битовое флатдефлейт

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

спасибо за помощь бай зе вей

библиотека напрямую qr-code сохраняет как 0 0 0 rg\n x y w h re f\n и так количество чёрных пикселей

в библе очень много вшито констант оно вроде как изначально из расчёта 100dpi поэтому при экспорте в pdf везде втыкает 72 0 0 72 0 0 cm

png можно походу получить сначала отрисовав qr-code в отчёте затем поверх него поместив изображение которое в качестве источника будет использовать импорт png из qr-code компонента - тогда в pdf попадёт картинка

крч ща софтописатели этим будут

прст стало интересно насколько ща можно не заморачиваться в битики - пипл хавает и просит ещё