使用 TrueType 字体和 pdfTeX 时,otftotfm 的字距调整不正确

使用 TrueType 字体和 pdfTeX 时,otftotfm 的字距调整不正确

我想使用字体Junicode使用 pdfTeX。不幸的是,没有 Type1 版本,所以我不得不使用实用程序手动转换它otftotfm。不幸的是,虽然我可以让它显示出来,但它显然不能正确转换字距表。虽然我可以使用 LuaTeX,但我希望能够使用 microtype 包,而不受限制。此外,pdfTeX 似乎编译得更快,而我正在处理的项目非常大,因此编译时间可能过长。还有一点需要注意:pdfTeX 显然与网站上提供的 Junicode 版本存在问题,它不喜欢它的“OS/2 表”是版本 4,所以我使用 FontForge 将字体转换为使用版本 3。

首先,这是我使用的过程。我创建了一个目录~/juni

在这个目录中,我下载了一份Cork 编码。然后,我运行了以下命令:

otftotfm -e cork.enc Junicode.ttf > junicode.map

生成以下输出(在junicode.map文件中)

Junicode--cork--base Junicode "AutoEnc_ibcpqz6zekpiklslxaemqnuq2b ReEncodeFont" <[a_ibcpqz.enc <Junicode.ttf

接下来,对于我的自定义编码,我创建了一个文件uenc.def

\ProvidesFile{uenc.def}
\DeclareFontEncoding{U}{}{}

然后,我创建了一个文件UJunicode.fd

\ProvidesFile{UJunicode.fd}
\DeclareFontFamily{U}{Junicode}{}
\DeclareFontShape{U}{Junicode}{m}{n}{ <-> Junicode--cork--base }{}

最后,这是测试文档:

\documentclass{article}
\usepackage{lipsum}
\usepackage[utf8]{inputenc}
\usepackage[U]{fontenc}
\pdfmapfile{+junicode.map}
\renewcommand{\rmdefault}{Junicode}

% Loading the fonts for LuaTeX:
% \usepackage{fontspec}
% \setmainfont{Junicode.ttf}

\begin{document}
\title{Lorem Ipsum Dolor Sit}
\author{John Doe}
\date{January 1, 2016}
\maketitle
\lipsum
\end{document}

现在,这可以正常工作了。或者至少,字符显示在字体中。但是,字距调整不正确(事实上,我不确定是否有任何字距调整。)以下是 LuaTeX(使用注释掉的行加载字体)和 pdfTeX 之间的字距调整比较:

在此处输入图片描述

我不知道如何让它工作。我在网上找到的所有说明似乎都没有提到这个问题。

答案1

otftotfm正在删除字距调整信息:在生成的 TFM 等文件中没有字距调整对。ttf2afm效果相同。

我怀疑这是因为字体按类别指定字距,而不是按单个字符指定字距。我对此完全不确定 - 这只是猜测。

解决此问题的一种方法是在 FontForge(或类似软件)中打开 TTF,并将字体转换为 type1 格式,选中输出 AFM 的选项。此 AFM 应包含字距调整对。

如果您更喜欢使用 TTF,则可以丢弃 type1 PFB,同时使用 AFM 生成 TFM、VF 等。

在生成 type1 字体时,您会收到 FontForge 的一些投诉。它还会告诉您生成的字体有错误。有关 256 个插槽限制的警告可以放心忽略,因为它无论如何都不适用于您。您可以大概忽略其余大部分内容。

或者,您可以生成带有“旧式”字距调整表的 TTF。生成字体时,在选项对话框中设置选项。您会再次收到一些警告。生成的 TTF(Junicode2.ttf例如)将在应用诸如 之类的工具时恢复字距调整对ttf2afm,因此您应该能够使用otftotfm此版本。

但是,我尝试使用这种字体并没有成功,而我尝试使用生成的 PFB 效果更好,但再次省略了字距调整。

降级 OS/2 表可能效果会更好。如果不是这样,并且如果我真的需要使用这种字体 - 而不仅仅是想要 - 那么我会采用 PFB 和 AFM 并尝试使用它fontinst来生成所需的 TFM 和 VF。这将需要非常小心字形名称以确保它们.etx与用于编码的文件匹配。对于 T1,fontinst提供的t1.etx内容还不错,但可能不完全合适。例如,查看source/fonts/cfr-lm如何调整 ETX 文件以及如何为编写适当的输入文件的详细信息fontinst

[免责声明,我编写或改编了中的文件source/fonts/cfr-lm。]

要在 TeX 中使用字体,您需要使用可识别的正确 TeX 编码。T1将是一个很好的起点 - 因此我提出了上述建议。

如果你必须声明本地自定义编码,则必须正确进行。此外,它应该根据适当的约定命名,当然不应该使用用于符号字体(例如 dingbats)的 nencoded 或 raw encoding。

但是,在您考虑这些之前,我建议您尝试使用一些更基本的方法,因为 Junicode 根本不是一种协作字体,您可能需要考虑坚持使用较新的排版引擎是否不是最明智的做法。当然,这可能是阻力最小的路径。

请注意,我怀疑几年前我曾尝试准备此字体以用于 pdfTeX,我想我可能已经放弃了。然而,我对此并不确定,而且毫无疑问,从那时起字体已经进行了修改,因此任何此类失败都不一定预示着现在的失败。不过,这肯定不是一种容易处理的字体,所以我希望这不是你第一次这样的尝试!

[并且我怀疑我是否尝试过像您那样降级 OS/2 表,这可能是关键。]

从好的方面来说,至少许可证允许您自由地编辑和修改它,这确实为您解决问题提供了更多选择。

相关内容