【问题标题】:utf8 in libharu: is embedding fonts really necessary?libharu 中的 utf8:嵌入字体真的有必要吗?
【发布时间】:2019-06-03 08:44:51
【问题描述】:

我正在尝试在我正在编写的 PDF 文件中支持尽可能多的 Unicode。我希望能够输出 utf8 字符串并让它们在 PDF 中正确显示。

我在 libharu 编码文档 (https://github.com/libharu/libharu/wiki/Encodings) 中看到,我可以访问许多单字节代码页,如果我想要中文、日文和韩文,还有用于访问多字节代码页的特殊功能。但我的理解是,如果我想使用所有这些页面和函数来编写任意 utf8 字符串,我将不得不编写一堆代码来将我的 utf8 字符串分成每个使用特定代码页的段,然后执行任何代码页交换都是必要的,在输出之前将我的每个段从 utf8 反向映射到给定的代码页。与仅仅能够说“写这个 utf8 字符串”相比,这似乎是很多容易出错的工作。

为了能够编写 utf8 字符串,我正在使用此代码:

myPdf = HPDF_New( PdfErrorHandler, NULL );
HPDF_UseUTFEncodings( myPdf );
HPDF_SetCurrentEncoder( myPdf, "UTF-8" );
const char *f = HPDF_LoadTTFontFromFile( myPdf, "path/to/verdana.ttf", HPDF_TRUE );
HPDF_Font myFont = HPDF_GetFont( myPdf, f, "UTF-8" );
... go on to use myFont to write various text strings

这行得通,我可以编写带有重音拉丁字符、西里尔字母和希腊字符的 utf8 字符串,并且它们可以在 PDF 中正确显示。

但是,因为我使用 HPDF_TRUE 将字体嵌入到我的文件中,它显着增加了我的文件大小。实际上,我使用了四种字体(verdana.ttf、verdanab.ttf、verdanai.ttf 和 verdanaz.ttf),与我使用“内置”libharu 时相比,它们使我的文件大小增加了 600k 以上字体(使文件很小,只有几 k)。

(我确实尝试使用HPDF_FALSE 不嵌入字体,但随后我的文件以随机拉丁字符打开。)

我试图从概念上理解为什么有必要在我的 PDF 中嵌入字体,如果我使用的是像 verdana 这样的字体,无论如何都会在最终用户的系统上。 (我什至不在乎它是否是 verdana——任何标准的无衬线字体都可以。)我当然已经通过其他方式(例如,从 Word 导出)创建了许多包含希腊语、西里尔文、中文和其他字符的 PDF 文件,但它们很小。那么这个embedding-to-use-utf8 要求只是libharu 的一个怪癖吗?

另外,即使我使用 libharu 制作的文件有 600k 大容量,我的文件也将中文字符显示为块。我在 libharu 文档页面上读到 libharu 仅支持一个和两个字节的 utf8 序列,其中包括除中文、日文和韩文之外的大部分内容。那么这是否意味着我正在嵌入 verdana.ttf,其中大部分是中文、日文和韩文字形,我什至无法访问它们?

无论如何,中文、日文和韩文对我当前的应用程序并不重要,但对于两字节 utf8 序列,我试图了解是否有办法让我在 libharu 中使用它们而不必在我的文件中嵌入大字体。

【问题讨论】:

    标签: c++ utf-8 libharu


    【解决方案1】:

    对于 PDF 规范,如果您不嵌入字体,那么符合标准的阅读器将尝试从用户系统加载相同的字体。

    如果未找到,则回退并尝试使用另一种字体显示字符。如果替换字体在编码位置没有对应的字符,则在该位置会出现不可预知的字符。

    始终建议嵌入一个子集,除非您希望允许用户编辑您的文档,这对于 PDF 文档来说很少见。

    【讨论】:

      猜你喜欢
      • 2018-04-05
      • 2021-01-25
      • 1970-01-01
      • 2020-04-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-05-01
      • 1970-01-01
      相关资源
      最近更新 更多