Надежный и быстрый способ конвертировать zillion ODT файлы в PDF?

Question

Мне нужно предварительно подготовить миллион или два файла PDF из простого шаблона (несколько страниц и таблиц) со встроенными шрифтами. Обычно я бы оставался на низком уровне в таком случае, как это, и составлял бы все с помощью библиотеки, такой как ReportLab, но я присоединился к проекту поздно.

В настоящее время у меня есть template.odt и я использую маркеры в файлах content.xml для заполнения данными из БД. Я могу плавно создавать файлы ODT, они всегда выглядят точно.

Для преобразования ODT в PDF я использую openoffice в режиме сервера (и PyODConverter с именованным каналом), но это не очень надежно: в пакете документов в конечном итоге есть точка после чего все обработанные файлы преобразуются в мусор (неправильные шрифты и буквы растянулись по всей странице).

Проблема не предсказуемо воспроизводима (не зависит от данных), случается в OOo 2.3 и 3.2, в Ubuntu, XP, Server 2003 и Windows 7. Мой детектор Heisenbug работает.

Я пытался уменьшить размер пакетов и перезапускать OOo после каждого; Тем не менее, небольшой процент документов перепутались.

Конечно, я напишу об этом в списках рассылки Ooo, но пока у меня есть доставка и я уже потерял слишком много времени.

Куда мне идти?

1. Полностью избегайте формата ODT и переходите на другую систему шаблонов.

   • Предложения? Все, что занимает несколько секунд, работает слишком медленно. OOo занимает около секунды, и это составляет до 15 дней времени обработки. Мне пришлось написать программу для кластеризации заданий по нескольким клиентам.

2. Сохраните формат, но перейдите к другому инструменту / программе для преобразования.

   • Какой? В условно-бесплатных или коммерческих репозиториях для Windows есть много приложений, но попробовать каждое из них - непростая задача. Некоторые слишком медленные, некоторые не могут быть запущены в пакетном режиме без предварительной покупки, некоторые не могут работать из командной строки и т. Д.
   • Инструменты с открытым исходным кодом, как правило, не изобретают велосипед и часто зависят от openoffice.

3. Преобразование в промежуточный формат .DOC может помочь избежать ошибки OOo, но это удвоит время обработки и усложнит задачу, которая уже слишком сложна.

4. Попробуйте дважды создать PDF-файлы и сравнить их, отбросив весь пакет, если что-то не так.

   • Хотя документы выглядят одинаково, я не знаю, как сравнить двоичное содержимое.

5. Перезапустите OOo после обработки каждого документа.

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

6. Перейти на ReportLab и заново создать страницы программным способом. Это подход, который я собираюсь попробовать через несколько минут.

7. Научитесь правильно форматировать маркированные списки

Большое спасибо.

Редактировать: кажется, что я вообще не могу использовать ReportLab, он не позволит мне встроить шрифт. Мой шрифт поставляется в версиях TrueType и OpenType.

TrueType говорит: «TTFError: Шрифт не разрешает поднабор / встраивание (0100)».

Версия OpenType гласит: «[...] контуры TTFrror [...] postscript не поддерживаются»)

Очень, очень смешно.

Answer 1

Для создания такого большого количества PDF-файлов OpenOffice кажется мне неправильным продуктом. Вы должны использовать реальное решение для создания отчетов, которое оптимизировано для создания большого количества файлов PDF. Там много разных инструментов. Я бы рекомендовал Отчеты i-net Clear (раньше назывались i-net Crystal-Clear).

• Я ожидаю, что один файл PDF будет создан быстрее, чем с OpenOfice.
• Создание 2 PDF-файлов и их сравнение потребует больших затрат.
• В него могут быть встроены шрифты True Type.
• С API вы можете работать в цикле.
• С пробной лицензией вы можете работать в течение 90 дней в вашей партии

Недостатки в том, что вы должны перезапустить разработку.

Answer 2

Я, вероятно, в конечном итоге нашел бы способ определить, когда пакетная обработка становится бесполезной, а затем обработать все незадолго до сбоя. Как определить, когда он выходит из строя? Это потребует анализа некоторых правильных PDF-файлов и некоторых неудачных, чтобы найти сходство между ними:

• сгенерированные файлы имеют неправильный размер по сравнению с их источником
• файлы не содержат какой-либо строки (например, название вашего шрифта)
• некоторый бит данных находится не в ожидаемом месте
• при преобразовании обратно в текст они не содержат ожидаемых данных из шаблона
• при преобразовании в растровое изображение текст не в нужном месте

Я подозреваю, что преобразование их обратно в текст и поиск ожидаемых строк будет самым точным решением, но также медленным. Если он работает слишком медленно для каждого файла, запускайте его каждые 1/100 или около того, и просто повторно конвертируйте каждый файл после последнего известного удачного.

Answer 3

Для сравнения 2 pdf файлов я бы порекомендовал i-net для сравнения содержимого PDF . Он может сравнить 2 каталога файлов PDF очень хорошо. Мы используем его в нашей системе регрессионного тестирования.

Answer 4

Очень интересная проблема. Поскольку вы уже записали его для кластеризации на нескольких машинах, почему бы не использовать двойной производственный подход и не распределить его по узлам EC2. Это будет стоить немного больше, но вы можете сравнить вещи, используя md5 или sha хэши, и если 2 версии одинаковы, вы можете двигаться дальше.

Answer 5

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