Представленный PDF выглядит по-разному в производстве - Rails, PDFKit, wkhtmltopdf

Я использую Rails pdfkit gem для рендеринга многостраничных PDF файлов. Полученный pdf файл подбирает стиль CSS (SCSS) и разрывы страниц, как и ожидалось. Однако, когда я пытаюсь сделать один и тот же документ pdf в процессе производства, кажется, что стиль только загружает некоторые правила CSS и игнорирует другие объявления, такие как родительские контейнеры width и height. Вот мой CSS (SCSS) для элемента родительского контейнера:

.policy_pdf{
  font-family: Arial, sans-serif;
  .pdf-page{
    width:98%;
    height:17.1in;
    margin:auto;
    page-break-after:always;        
    ...
    @media screen{
      border: 1px dotted red;
    }
    page-break-after:always;
  }
...
}

и инициализатор PDFKit:

PDFKit.configure do |config|
  config.default_options = {
    :page_size => 'Legal',
  }
end

Вот пример pdf, представленного в разработке: введите описание изображения здесь

и вот как выглядит тот же самый pdf файл в production: введите описание изображения здесь

Красная линия вокруг документа - это правило CSS, которое я представил для отображения того, как ребра страниц отображаются в процессе производства.

Среды

Оба, разработка и производство (Digital Ocean Droplet) используют ту же версию Ubutnu (16.04).

Что вы пробовали?

  • Сначала мне показалось, что некоторые из классов CSS, которые я использую для pdf-kit, таких как .page, перезаписываются некоторыми противоречивыми правилами при компиляции, поэтому я попытался использовать уникальные имена классов, например .pdf-page .page.

  • Затем я попытался выяснить, может ли быть связано с компиляцией SCSS. Но вложенные объявления границ и фонового цвета в одной таблице стилей становятся "поднятыми" и отображаются отлично. Блок policy-pdf внутри скомпилированного application.css также выглядит корректно.

  • Отключение smart-shrinking сделало просмотр PDF еще более "рухнувшим".

  • Применение правил CSS/CSS (в строке и через внешнюю таблицу стилей) к тегу html, как предлагается в this сообщение:

Подсказка:

Оба, производство и разработка работают с той же версией wkhtmltopdf (~> 0.12.2). Однако, запустив wkhtmltopdf -V, верните wkhtmltopdf 0.12.2.1 (with patched qt)

Ответ 1

Выход продукции, по-видимому, имеет большую прибыль, чем выход dev.

Из приведенного вами примера соответствующего CSS, показывающего вашу "конфигурацию страницы", это можно просто исправить, указав эти поля. Это делается не для элемента виртуальной страницы .pdf-page, а внутри селектора @page.

@page { margin:10mm 15mm 10mm 15mm; }

В зависимости от того, как этот дизайн разрабатывался и просматривался (диалоговое окно печати, эмуляция мультимедиа инструментов разработки), вам может потребоваться настроить эти поля в соответствии с полями, используемыми для предварительного просмотра работы. Это можно сделать в диалоговом окне печати Chrome, установив для параметра "Назначение" значение "Сохранить как PDF", развернув "Дополнительные параметры", выбрав "Настраиваемые" в полях и, наконец, введя значения или непосредственно перетащив поля, которые теперь отображаются над предварительным просмотром печати.

Хотя я не знаком с PDFKit, я разработал шаблоны для AthenaPDF, но я предполагаю, что все они в значительной степени являются стандартными конвертерами PDF, использующими Headless Chrome. Мы обнаружили, что проще и более гибко определять свойства @page с помощью css, а не пытаться настроить его с помощью докерской службы AthenaPDF. В качестве значений маржи использовались только стандартные, минимальные и ни один.

Ответ 3

У меня тоже была такая проблема. Я не уверен, но если я правильно помню, в итоге это были разные версии ghost- script.

Вы можете проверить версию, запустив gs -v