通过 pdfjam 运行包含 Libertinus Serif 字体的 unicode（非拉丁）字符的简单 pdf 文件会产生损坏的文件，其中 unicode 字符未正确编码。生成的 pdf 文件显示 Encoding:Custom，而不是源 pdf 文件中预期的 Encoding:Builtin。
可以使用 LibreOffice 7.5.2.2 生成源 pdf 文件，然后将其传递给当前 texlive 发行版中的 pdfjam 3.03，从而重现此问题。如果使用 LibreOffice 7.4，则 pdfjammed 文件不会损坏。此版本的 LO 为其生成的 pdf 中嵌入的字体提供了一个非标准名称；LO 7.5.5.2 更正了此问题，不知何故，这种标准字体名称的使用似乎导致 pdfjam 将 texlive Type 1 字体插入 pdf 文件中并扰乱编码。
我不知道错误出在哪里。
更多详细信息：源文档例如是 LibreOffice Writer 文档中的文本：Question 123，其字体指定为“Libertinus Serif:onum=1&pnum=1”。此文档导出为 pdf。生成的 pdf 文件显示文本“Question 123”，带有长尾“Q”和小写数字“123”。当 LO 7.5 pdf 文件用作 pdfjam 的输入文件时，这些字符在输出文件中被破坏。
我想添加更多信息：具体来说，附加 2 个 pdf 文件，一个由 libreoffice 7.5 生成，另一个由 libreoffice 7.4 生成。然后在命令中将这些文件用作“input.pdf”：pdfjam -o out.pdf input.pdf。由 LO 7.4 生成的文件给出了正确的 out.pdf（即文件大小大致相同，并且 unicode 字符显示正确），但处理来自 LO 7.5 的 input.pdf 的 out.pdf 要大得多（从 < 6kB 变为 > 600kB），并且 unicode 字符是乱码。此外，out.pdf 属性从 Encoding:Builtin 更改为 Encoding:Custom。如果可能的话，我会附加 pdf 文件。