Пример забытого «наивного» алгоритма

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

Вот с TIFF возникла проблемка когда тестеры подсунули (или клиент, ко мне уже приехала просьба решить проблему) большое изображение примерно на 300 мегапикселей... Хоть он и был в однобитном цвете (факс), но Java ImageIO разворачивает в RGBA модель, где каждый цвет это int, а int в java это 32 бита, те 4 байта... Все очень грустно оказалось с памятью.

Пришлось вспомнить старый добрый С и портировать декодер TIFF на Java, пытался вначале предлагать гетерогенные сервисы для конвертации (Polyglot кажется сейчас называется такой подход?), но клиенту обещали монолит на Java. Пришлось доставать напильник и делать из паровоза самолет, согласно чертежу...

TIFF в большинстве случаев (кроме Jpeg, a у клиента в основном были факсы, CCITT 4 формат) развертывается построчно, PNG тоже построчный - это хорошо ложится в потоковую обработку без необходимости разворачивать картинку в памяти.

Добавил масштабирование, с разными вариантами экстраполяции, и вуаля - конвертация TIFF 1 мегапиксель занимает 12 МБ heap memory, а 300 мегапикселей 16 МБ (с масштабированием в разрешение на клиенте)! Зависимость обратно квадратичная. С Jpeg так не получится, придется разворачивать в памяти чтобы создать PNG.

нет, там пара патчей висела в тикете уже, похоже интерес потерян у владельца проекта к этой проблеме.

Второе, в комменте ниже раскопки продолжил, похоже что это не текст в форме а аннотация которая скорее всего описывает геометрическую фигуру (карту, схему дома и тд) и по ошибке парсится как текстовая аннотация.

На досуге возможно еще покопаюсь. Проблема в том что не могу поделиться исходным pdf в тикет а воспроизвести похоже нужно постараться (не знаю как сделали оригинальный документ).

Спецификацию бы тагов pdf посмотреть, возможно парсер pdfbox неправильно разобрал документ. Версия 1.4:

%PDF-1.4

Часть аннотаций выглядит так:

/Type /Annot
/V (y \265w\312\274\277\345\341\

или так

/Type /Annot
>>
endobj

a pdf box создал что то непонятное (текст длиной в 100к) из аннотации начинающейся как

/Type /Annot
/V (y \265w\312\274\277\345\341\3 и далее что то похоже на unicode текст

получилось

/T (gendate)
/Type /Annot
/V (FNCNETklimqf1i54Swl и далее около 100К символов с окончанием TnEAB2NFXwjY9rhk=)

Похоже что изменен энкодинг.

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

Не я засунул а клиент такое дал.

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

Стыдно признаться, сделал патч даже не разобравшись а что за текст. Механически. Pdf проверил - выглядит нормально, как исходный, а подумать а где и куда делись 100К символов, не догадался... Потогонка.

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

Посмотрел в отладчике еще раз, глянул пдф структуру, это оказалась аннотация:

/Subtype /Widget
/T (gendate)
/Type /Annot
/V и далее текст длиной > 100К символов похожий на base64

Больше всего это похоже на то что pdfbox неправильно обрабатывает или не понимает формат аннотации. Обычно 100К символов это не текстовая аннотация а кодирование массива байт для полигона, карты и тд.

Скорее всего нужно покопаться дольше, причина не только в парсинге.

Но в любом случае, парсинг не валидировал длину строки и использует слишком простой алгоритм.

Хотя бы среднюю ширину символа можно было использовать чтобы получить ожидаемое количество символов (ширина стобца / средняя ширина символа) вместо перебора всех строчек.

и удивились, что сломалось?

Конечно, я бы тоже удивился. Даже отказ с адекватным сообщением об ошибке тут уместнее, чем потенциальная уязвимость для DOS-атаки.

Лада не поехала — это нормально. Лада выехала на трассу со скоростью «1» при удавленном акселераторе — нет.