FT_Get_Glyph_Name 返回的 "uniE0A1" 是什么意思？

Question

这个问题可能是我不理解一些基本知识的产物，但我真的可以在一些帮助下解决问题，所以就这样吧。

当我试图思考文本渲染、freetype 等问题时，我遇到了那些奇怪的字形，据我所知，它们报告自己与 unicode 代码点相关联，但是当我从 unicode 方面检查时，代码点无效。

例如，使用字体 "Hack" 索引 1437 处的字形就是这些神秘字形的一个示例，请参阅下面的外观。

这是一些使用 freetypepython 包装器的演示代码。

首先，作为一个看起来合理且适用于 >99% 字形的示例，让我们看一下字母 "A":

import numpy as np
import freetype as FT
import unicodedata

ff = FT.Face('/usr/share/fonts/truetype/Hack-Regular.ttf')
ff.set_char_size(12<<6)

ff.load_glyph(1425)
ff.get_glyph_name(1425)
# b'uni0041'

hex 41 是十进制的 65，即 ascii/unicode for 'A'，渲染的位图也看起来 'A'.

np.array(ff.glyph.bitmap.buffer).reshape(-1,8)
# array([[  0,   0,  67, 255, 121,   0,   0,   0],
#        [  0,   0, 143, 213, 198,   0,   0,   0],
#        [  0,   0, 218,  85, 250,  21,   0,   0],
#        [  0,  38, 248,   9, 203,  95,   0,   0],
#        [  0, 115, 191,   0, 136, 171,   0,   0],
#        [  0, 191, 125,   0,  69, 242,   5,   0],
#        [ 15, 250, 252, 252, 252, 255,  68,   0],
#        [ 87, 231,   2,   0,   0, 178, 145,   0],
#        [162, 152,   0,   0,   0,  97, 221,   0]])
unicodedata.name(chr(0x0041))
# 'LATIN CAPITAL LETTER A'

现在让我们对字形索引 1437 执行相同的操作：

ff.load_glyph(1437)
ff.get_glyph_name(1437)
# b'uniE0A1'
np.array(ff.glyph.bitmap.buffer).reshape(-1,5)
# array([[ 56,  70,   0,   0,   0],
#        [112, 140,   0,   0,   0],
#        [112, 140,   0,   0,   0],
#        [112, 140,   0,   0,   0],
#        [112, 140,   0,   0,   0],
#        [112, 140,   0,   0,   0],
#        [105, 232, 224, 178,   0],
#        [  0, 168, 150,  40, 216],
#        [  0, 168, 241,  46, 216],
#        [  0, 168, 223, 124, 216],
#        [  0, 168, 131, 215, 216],
#        [  0, 168,  81, 212, 216],
#        [  0, 168,  84, 108, 216]])
unicodedata.name(chr(0xE0A1))
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
# ValueError: no such name

所以，字形自称 "uniE0A1" 但正如我所说，unicode 那里没有代码点（我仔细检查了一下，它不在 UnicodeData.txt（我认为是版本 12）中）并且我不识别位图。

这个问题与 Why does num_glyphs not match the number of glyphs enumerated by FT_Get_First_Char / FT_Get_Next_Char 松散相关，这是另一个不相符的例子。

Answer 1

代码点 U+E0A1 位于私人使用区。字体可以将其用于自定义字符。

https://www.unicode.org/charts/PDF/UE000.pdf

Answer 2

我刚刚安装了 hack-fonts-3.003 并检查了由代码点 U+E0A1 生成的字符生成的字形:

此字符在 powerline enabled applications 中用作行号指示符。由于该角色目前居住在私人区域，因此其意义与其外观是分离的。换句话说，只有从字的样子知道是什么，才能推断出字的意思。我知道它是什么（因为我对主题很熟悉），你（OP）不知道。

因此，为了解决这个问题，存在proposal to include powerline characters into Unicode proper。一旦提案被采纳，希望字体和应用程序从无名无意义的U+E0A1 ‹›切换到U+2FE1 ‹⿡› \N{LINE NUMBER INDICATOR}。

uniE0A1 是字体中错误命名的标识符，字体作者是懒惰或粗心。它应该被称为 line_number_indicator 或具有类似的有意义的名称。

FT_Get_Glyph_Name 返回的 "uniE0A1" 是什么意思？

What is the meaning of "uniE0A1" as returned by FT_Get_Glyph_Name?

python

unicode

freetype

freetype2

freetype-py