Встроенное изображение и временные файлы (генерация Java XHTML->PDF)

У меня есть проект, в котором мне нужно создать файл PDF. В этот PDF-файл мне нужно вставить основной текст, а также четыре или пять больших изображений (примерно 800 пикселей * 1000 пикселей). Чтобы сделать это гибким, я решил использовать FreeMarker в сочетании с XHTMLRenderer (летающая тарелка).

Теперь я столкнулся с несколькими вариантами:

  1. Создайте изображения и сохраните их как временные файлы на диск. Затем обработайте шаблон .xhtml с помощью FreeMarker (сохранив его на диск) и передайте обработанный URL-адрес файла .xhtml в XHTMLRenderer для создания PDF-файла. Все эти созданные файлы (за исключением PDF) будут созданы с помощью File.createTempFile. Это позволит FreeMarker брать изображения с диска (как если бы они были изображениями, связанными в XHTML).
  2. Обработайте шаблон .xhtml и сохраните его в памяти. Передайте изображения в шаблон как URL-адреса данных в кодировке base64. Это избавило бы от необходимости сохранять какие-либо временные файлы, поскольку выходные данные FreeMarker можно было бы передавать непосредственно в XHTMLRenderer.

Пример URL-адреса изображения в кодировке Base64 (маленький значок папки):

<img src="data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub/
/ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExK
cppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7" />

Мой главный вопрос: какая техника лучше? Является ли создание большого количества временных файлов плохим (это влечет за собой много накладных расходов)? Могу ли я потенциально исчерпать память, создавая такие большие строки в кодировке base64?


java pdf-generation xhtml freemarker flying-saucer
person BeRecursive    schedule 12.01.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Недавно я обнаружил, что задаюсь тем же вопросом. После некоторого сравнительного анализа оказалось, что подход с URI данных был лучшим выбором.

Хранение множества изображений в кодировке Base64 может быть дорогостоящим. Но накладные расходы на создание временных файлов, потоковую передачу данных изображения, а затем ожидание того, что XHTMLRenderer 4 раза попадет в этот временный файл, прежде чем очистить его, также облагаются налогом.

В моих экспериментах образы Base64 оказались лучшим подходом. При этом я не уверен, в какой степени это останется верным для больших изображений. В моем случае я тестировал значки 32x32, логотипы 80x80, гистограммы 400x240 и одну графику 600x400. Разница в накладных расходах была существенной для всего, кроме графики 600x400, где она была совсем незначительной.

(Примечание для Юпа Эггена. В моем случае создание PDF-файла критично по времени. Пользователь нажимает кнопку PDF-файла и ожидает, что загрузка начнется немедленно.)

person Chris Cashwell    schedule 13.01.2012
comment
Я вижу вашу точку зрения, ценю ее. Однако, если PDF достигает диапазона МБ, я более спокойно отношусь к отзывчивости. Изображения в формате EPS также можно вставлять. - person Joop Eggen; 16.01.2012

arrow_upward
1
arrow_downward

Генерация PDF-файла не критична по времени — можно даже рассмотреть возможность ограничения связи. Встраивание изображений в Base64 требует немного больше ресурсов ЦП и памяти при и без того дорогостоящем преобразовании шаблонов: данные сборки Base64 перетаскиваются через конвейер шаблонов, а затем, вероятно, декодируются из Base64 в двоичный файл для сжатия. Я даже не знал, что возможны встроенные изображения. Таким образом, накладные расходы на временные файлы являются более надежным решением. Конечно для начала. Конечно, можно сравнить оба случая.

person Joop Eggen    schedule 13.01.2012
comment
Насколько я понимаю, изображения в любом случае не сжимаются в HTMLRenderer, но я понимаю вашу точку зрения о возможном распределении памяти во время обработки шаблона. - person BeRecursive; 13.01.2012