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

У меня есть проект, в котором мне нужно создать файл PDF. В этом PDF я должен вставить текст, а также четыре или пять больших изображений (примерно 800xx1000px). Чтобы сделать это гибким, я решил использовать 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?

Ответы [ 2 ]

1 голос
/ 13 января 2012

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

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

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

(Примечание для Joop Eggen. В моем случае генерация PDF критична ко времени . Пользователь нажимает кнопку PDF и ожидает, что загрузка начнется немедленно.)

1 голос
/ 13 января 2012

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

...