Svg 为什么Apache Batik光栅化器不正确地渲染TrueType字体？

我正在使用（Java，Ubuntu上的OracleJRE7）将SVG转换成PDF。SVG包含文本并引用ttf字体，这种字体效果很好，但字体没有按预期呈现：

预期：

不正确：

正如您可以看到的，“R”流入“A”，因此字距没有正确解释，因为字体本身包含此信息（参见@Jongware的注释）：

ra->-660

，

te->-61

可能的解决办法：

1） 我认为，如果我们可以将batik的字体渲染引擎替换为使用freetype，它可以在我的Libre Office Writer（使用freetype）中正确渲染

2） 我可以将ttf字体转换为SVG字体，在这种SVG到PDF光栅化的情况下效果更好。但到目前为止我还没有成功

3） 我可以将SVG中的字体转换为路径，如果有任何工具支持的话

---

欢迎提出任何意见或其他解决方案！谢谢

找到了一个值得分享的解决方案：

Batik光栅化器使用AWT GlyphVector（Java）进行字体渲染，这似乎无法正确渲染字距-至少对于这种字体是如此

我通过batik将ttf字体转换为svg字体，从而使其正常工作。其他工具不起作用-至少与蜡染光栅器结合使用

我使用以下命令转换字体：

java -jar /path/to/batik/batik-1.8/batik-ttf2svg-1.8.jar diehl_deco.ttf -o diehl_deco.svg -id DiehlDeco -l 32 -h 20000`

在用于转换为pdf的输入svg中，我通过@font faces引用了字体。上述命令中的id与字体url末尾的id相同：

#DiehlDeco

<defs><style type="text/css"><![CDATA[
    @font-face { 
        font-family: 'diehl_deco';
        src: url('https://path/to/diehl_deco.svg#DiehlDeco') format('svg');
        font-weight: normal;
        font-style: normal;
    }
]]></style></defs>

---

选项

-l 32

非常重要-至少对于这种字体-因为前32个unicode字符与batik光栅化器不兼容。如果您的字体根本不呈现svg字体中的单个字符，则可能会出现问题。

很可能是因为Ubuntu的字体呈现程序不支持字体的某些功能。我不完全确定这些功能的正式名称，但你看到的是类似于条件紧排的东西，其中一些字母组合允许以不同的方式进行紧排。看起来它的紧排是完全错误的，可能是因为您所依赖的任何文本呈现引擎都不完全了解如何解析和显示OpenType字体。找出你正在使用的文本引擎，并将其更改为更好的。Thx伙计们，Ubuntu14确实使用freetype 2，这与osx使用afaik是一样的。。如果字体是免费提供的，我会去看看这是否是问题所在。请稍等，我查一下。好的，问题不在字体上。它确实包含常规紧排：

ra->-660

，

te->-61

。您使用字体的软件（“在Ubuntu上”根本没有告诉我们任何有用的东西）只是选择在显示文本时不使用字距。有没有办法支持给定字体中的所有Unicode？