ghostscript pdf / проблема преобразования в ubuntu 18.10 и docker

Question

Я использую Ghostscript для преобразования pdf1.3 в pdf / a-1b с помощью этой команды:

gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -sColorConversionStrategy=sRGB -sDEVICE=pdfwrite -sOutputFile=output.pdf PDFA_def.ps input.pdf

Файл PDFA_def.ps настроен для использования профиля srgb icc.За исключением этого изменения, это стандартный файл def, который поставляется с GS 9.26.

Теперь перейдем к сложной части: 1 - запускать это преобразование локально на ubuntu 18.10, GS 9.26, он отлично работает, и я получаю действительный pdf /2 - выполнение той же команды в Docker-контейнере (Ubuntu 18.10. GS 9.26) также создает файл pdf / a, который считается допустимым

Однако в первом сценарии я могу обработать файл, используяmustang (https://github.com/ZUGFeRD/mustangproject) для создания действительного электронного счета-фактуры. Во втором сценарии (Docker-контейнер) это не удается, так как файл mustang не считается допустимым PDF-файлом.

проверка обоих PDF-файлов Iмог бы ожидать, что они будут идентичны, так как я выполняю ту же самую конверсию на нем. Однако они не являются. Файл PDF, созданный в файле dockerfile, на 10 байтов меньше и показывает некоторую другую метаинформацию в самом файле.

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

Кто-нибудь знает, у более влажного GS есть еще несколько зависимостей, которые могут привести к тому, что одна и та же команда даст разные результаты?

Answer 1

Ответ «возможно».Это зависит от того, как Ghostscript был создан для начинающих.

Я предполагаю, что вы используете пакет, а не собираете его из исходного кода самостоятельно.В этом случае есть ряд зависимостей, в том числе;FreeType, LibJPEG, JBIG2dec, LibTIFF, JPEG-XR, LCMS2, LibPNG, OpenJPEG, Expat, zlib, потенциально IJS, CUPS и X-Windows, в зависимости от того, какие устройства были встроены.

Любое или все из нихэто могут быть системные разделяемые библиотеки, а не созданные с использованием конкретной версии, поставляемой Artifex.Они также могут быть разными версиями в двух системах.

Тем не менее, я думаю, что "маловероятно", что это ваша проблема.Однако, не видя файлов PDF, я не могу сказать вам, почему есть разница.Различия в метаданных ожидаются, поскольку они включают отметку даты / времени.

Мне действительно нужно увидеть примеры оригинала и двух выходных файлов PDF, чтобы иметь возможность комментировать дальше.

[Редактировать]

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

Это сделано, я вижу, по сути, нет никакой разницы между ними.Одна из операционных систем использует часовой пояс на 7 часов позже UTC, другая находится в UTC, поэтому одна из систем имеет временную метку с (например)

2019-04-26T19: 49: 01Z

Другой использует

2019-04-26T12: 51: 35-07: 00

Таким образом, вместо Z (для UTC) вы получите -07: 00, гдедополнительные 10 байтов поступают из.Кроме этого, уникальные идентификаторы (как вы могли бы представить) различны, значения длины для потоков различны для потоков, содержащих даты, и startxref отличается, поскольку потоки имеют разную длину.

Оба файлаутверждают, что совместимы с PDF / A-1b.Короче говоря, я не вижу реальных различий между ними.Поскольку вы используете инструмент для дальнейшей обработки файлов, я бы посоветовал вам попробовать взять файл PDF из вашей рабочей системы и попробовать обработать его в нерабочей системе, и наоборот, мне кажется, что проблема может бытьпоследующая обработка, а не сам файл PDF.Возможно, у вас есть разные версии этого инструмента в двух системах.

Что бы это ни стоило, Ghostscript может быть побужден к созданию файла ZUGFeRD напрямую, см. этот отчет об ошибке и this фиксация в хранилище.