这是个问题,可能是我不理解一些基本的东西的结果,但我真的可以在一些帮助下做,所以这里就说。
当我试图用文字渲染、freetype等来包装我的头时,我遇到了一些奇怪的标志符号,当我不相信它会报告自己与一个unicode代码点相关联时,但是当我从unicode端检查时,该代码点是无效的。
例如,使用字体“hack”索引1437处的标志符号就是这些神秘标志符号的一个例子,请参阅下面的内容了解它是什么样子的。
下面是一些使用
freetype-py
的python包装
freetype
.
首先,作为一个看似合理并适用于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)
十六进制41是十进制65,表示“a”的ASCII/Unicode,呈现的位图也显示为“a”。
np.array(ff.glyph.bitmap.buffer).reshape(-1,8)
unicodedata.name(chr(0x0041))
现在,让我们对glyph index 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
所以,glyph称自己为“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
这是另一个没有加起来的例子。