wicked_pdf показывает неизвестный символ при преобразовании юникода в pdf (ruby)

Я пытаюсь создать PDF-файл из html-страницы, используя wicked_pdf (версия 1.1) и wkhtmltopdf-binary драгоценные камни. Моя html-страница содержит смайлик календаря, который хорошо отображается в браузере, независимо от того, какой шрифт я использую.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta http-equiv='content-type' content='text/html; charset=utf-8' />
  <style>
  unicode {
     font-family: 'OpenSansEmoji', sans-serif;
  }
  @font-face {
     font-family: 'OpenSansEmoji';
     src: url(data:font/truetype;charset=utf-8;base64,<-- encoded_font_base64_string-->) format('truetype');
  }
 </style>
 </head>
 <body>
 <div><unicode>&#128197;</unicode></div>
 </body>
 </html>

Однако, когда я пытаюсь создать PDF-файл, используя метод WickedPdf.new.pdf_from_html_file драгоценного камня в консоли рельсов,

 File.open(File.expand_path('~/<--pdf_filename-->.pdf'), 'wb+') {|f| f.write  WickedPdf.new.pdf_from_html_file('<--absolute_path_of_html_file-->')}  

Я получаю следующий результат:

Результат PDF с неизвестным символом

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

Я исследовал кодировку в UTF-8 и UTF-16 и суррогатную пару, как это было предложено в этом связанном сообщении stackoverflow_emoji_wkhtmltopdf и рассмотрел эту проблему wkhtmltopdf_git_issue, но по-прежнему не могу заставить этот символ исчезнуть!

Если у вас есть какие-либо подсказки, это более чем приветствуется.

Заранее спасибо за вашу помощь!

ИЗМЕНИТЬ

Следуя комментариям Эрика Дюминила и petkov.np, я могу подтвердить - приведенный выше код у меня правильно работает в Linux. Похоже, это проблема Linux и MacOS. Кто-нибудь может подсказать, в чем суть проблемы в привязке MacOS и можно ли это исправить?


person rico1892    schedule 10.01.2017    source источник
comment
Он отлично работает с вашим html и рубиновым кодом. список драгоценных камней | grep pdf : pdf-core (0.6.1) pdf-инспектор (1.2.1) pdf-reader (1.4.0) wicked_pdf (1.1.0) wkhtmltopdf-binary (0.12.3.1) ruby ​​-v: ruby ​​2.3.1p112 ( 26 апреля 2016 г., редакция 54768) [x86_64-linux] В Linux Mint 17   -  person Eric Duminil    schedule 15.01.2017
comment
@EricDuminil Я тестировал в среде Linux, и это работает. Только что отредактировал мой вопрос   -  person rico1892    schedule 16.01.2017


Ответы (1)


Я редактировал этот ответ несколько раз, см. примечания в конце, а также комментарии.

Я использую macOs 10.12.2 и у меня такая же проблема. Я перечисляю все версии браузера и т. д., хотя я подозреваю, что самым важным фактором является сборка OS/wkhtmltopdf.

  • Chrome: версия 55.0.2883.95 (64-разрядная версия)
  • Safari: версия 10.0.2 (12602.3.12.0.1)
  • wkhtmltopdf: 0.12.3 (с исправленным qt)

Я использую следующий пример фрагмента:

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html" charset="utf-8">
    <style type="text/css">
      p {
        font-family: 'EmojiSymbols', sans-serif;
      }
      @font-face {
        font-family: 'EmojiSymbols';
        src: local('EmojiSymbols-Regular.woff'), url('EmojiSymbols-Regular.woff') format('woff');
      }

      span:before {
        content: '\01F60B';
      }
    </style>
  </head>
  <body>
    <p>
      ????
      <span></span>
      &#x1F60B;
      &#128523;
      &#xf0;&#x9f;&#x98;&#x8b;
    </p>
  </body>
</html>

Я звоню wkhtmltopdf с опцией --encoding 'UTF-8'.

Результат рендеринга можно увидеть здесь (извините за неубедительный снимок экрана). Несколько кратких выводов:

  1. Safari неправильно отображает «сырые» байты UTF-8. Кажется, что они обрабатываются как необработанная последовательность байтов (последняя строка в html-абзаце). Safari все отображает нормально.
  2. Хром все нормально отрисовывает.
  3. С приведенной выше опцией wkhtmltopdf нормально отображает необработанные байты (вроде), но неправильно отображает атрибут CSS content. За каждым «правильным» появлением символа Юникода следует этот странный фантомный символ.

Я пробовал буквально все, но результаты те же. Для меня тот факт, что даже Safari не отображает необработанные байты должным образом, указывает на некоторую проблему системного уровня, специфичную для macOS. Мне неясно, следует ли сообщать об этом как о проблеме wkhtmltopdf или какая-то неправильная зависимость в сборке macOs.

РЕДАКТИРОВАНИЕ: Safari работает нормально, моя разметка не работает.

EDIT: Обходной путь CSS может помочь, пожалуйста, ознакомьтесь с комментариями ниже.

ПОСЛЕДНИЕ РЕДАКТИРОВАНИЯ: Как показано в комментариях, «хак» CSS, решающий проблемы, использует text-rendering: optimizeLegibility;. Кажется, это необходимо только в macOS/OS X.

Из моего коммента ниже:

Я только что нашел эту проблему. На первый взгляд это кажется неуместным, но добавление text-rendering: optimizeLegibility; в моих стилях удалены повторяющиеся символы (на macOS). Почему это происходит, мне не понятно. Поскольку автор проблемы также использует osx, очевидно, что есть некоторые проблемы со сборками wkhtmltopdf для этой ОС.

person petkov.np    schedule 16.01.2017
comment
petkov.np, вы можете попробовать встроить Base64, как это делает OP? Например: <%= Base64.strict_encode64(Rails.application.assets['EmojiSymbols-Regular.woff'].source) %> - person AmitA; 16.01.2017
comment
Я также пробовал кодировать шрифт base64, это не имеет значения в отображаемом pdf. - person petkov.np; 16.01.2017
comment
Только что попробовал рендеринг с wkhtmltopdf 0.12.2.4 на Ubuntu 16.04, и результат такой, как и ожидалось. - person petkov.np; 16.01.2017
comment
@petkov.np Я только что протестировал свой код в среде Linux, и он действительно работает. Это может быть проблема с привязкой MacOS. Просто добавил это замечание к моему вопросу - person rico1892; 16.01.2017
comment
Я только что нашел эту проблему. На первый взгляд это кажется неуместным, но добавление text-rendering: optimizeLegibility; к моим стилям удалило повторяющиеся символы (в macOS). Почему это происходит, я не понимаю. Поскольку автор проблемы также использует osx, очевидно, что есть некоторые проблемы с wkhtmltopdf сборками для этой ОС. - person petkov.np; 16.01.2017
comment
Это решило это! Неизвестный персонаж исчез. Я постараюсь выяснить, почему, но все равно спасибо. - person rico1892; 16.01.2017
comment
@petkov.np У нас сработало!! Можете ли вы отредактировать свой ответ, чтобы я мог дать вам награду? Я верю, что это поможет многим людям в том же случае. Кроме того, если у вас есть больше информации о том, что это за исправление, как вы его нашли, это было бы здорово! Спасибо ! - person Erowlin; 16.01.2017
comment
Рад, что смог помочь. wkhtmltopdf проблемы, как правило, очень расстраивают. - person petkov.np; 16.01.2017
comment
Кроме того, если у вас есть больше информации о том, что это за исправление, как вы его нашли и как оно работает, было бы здорово! Спасибо ! - person Erowlin; 16.01.2017
comment
На самом деле у меня нет дополнительной информации, я просто просмотрел все вопросы, связанные с Unicode и OS X, в репозитории проекта. Я собрал здесь все актуальное. - person petkov.np; 16.01.2017
comment
исходная проблема в github, по-прежнему не может найти реального решения для нее. - person Gokul; 22.05.2018