docsplit преобразование в PDF изменяет не-ASCII символы в docx на Linux

Question

Мое приложение для управления документацией включает в себя преобразование файла.docx, содержащего символы не-ASCII Unicode (японский), в PDF с помощью docsplit (через гем Ruby, если это имеет значение). Он отлично работает на моем Mac. На моем компьютере с Ubuntu полученный PDF имеет квадратные прямоугольники, в которых должны находиться символы, независимо от того, были ли они вызваны через Ruby или непосредственно из командной строки. Странно то, что когда я открываю файл.docx прямо в LibreOffice и выполняю экспорт в PDF, он работает нормально. Таким образом, может показаться, что есть некоторый аспект того, как docsplit вызывает LO, что приводит к неправильной обработке символов Unicode. Я изучил различные части документации и кода для вариантов, которые мне, возможно, понадобится указать, но не повезло. Есть идеи, почему это может происходить?

FWIW, docsplit вызывает LO со следующей строкой опций в pdf_extractor.rb:

options = "--headless --invisible  --norestore --nolockcheck --convert-to pdf --outdir #{escaped_out} #{escaped_doc}"

Я заметил, что выходной формат может опционально сопровождаться выходным фильтром в pdf:output_filter_name- это то, что мне нужно подумать об использовании?

Answer 1

Я отследил это до --headless опция, которую docsplit передает LibreOffice. Это вызывает не-X версию LO, которая, по-видимому, не имеет необходимых японских шрифтов. К сожалению, кажется, что нет способа передать опции в docsplit, чтобы он пропустил --headless вариант для LO, так что я буду в конечном итоге исправления или разветвления кода как-то.