2

我正在尝试使用 Harfbuzz 和有符号距离场图集渲染文本。

代码基本上是这样的：

void drawText(const std::wstring &str, Vec2 pos)
{
    // Init harfbuzz
    hb_buffer_t *hbBuf = hb_buffer_create();
    hb_buffer_set_direction(hbBuf, HB_DIRECTION_LTR);
    hb_buffer_set_script(hbBuf, HB_SCRIPT_LATIN);
    hb_buffer_set_language(hbBuf, hb_language_from_string("en", 2));

    // Process string
    hb_buffer_add_utf32(hbBuf, reinterpret_cast<const uint32_t*>(str.c_str()), -1, 0, -1);
    hb_shape(font.hb, hbBuf, nullptr, 0);

    // Display string
    unsigned int nbGlyphs;
    hb_glyph_info_t *glyphInfos = hb_buffer_get_glyph_infos(hbBuf, &nbGlyphs);
    hb_glyph_position_t *glyphPos = hb_buffer_get_glyph_positions(hbBuf, &nbGlyphs);

    for(unsigned int i = 0; i < nbGlyphs; i++)
    {
        Vec2 drawPos = pos + Vec2(glyphPos[i].x_offset, glyphPos[i].y_offset) / 64.f;
        drawGlyph(glyphInfos[i].codepoint, drawPos);
        pos.x += glyphPos[i].x_advance / 64.f;
        pos.y += glyphPos[i].y_advance / 64.f;
    }
}

对于英语短语，文本的形状看起来正确，但是当我用变音符号对其进行测试时，它们看起来放错了位置。我正在用 aâa aâ̈a bb̂b bb̂̈b bb̧b bb͜b bb︠︡b 测试它。Unicode 字符串不包含预组合字符。Harfbuzz使用预先组合的字符â，这使得这个看起来很好。大多数其他变音符号都关闭了。

在它们应该在的位置左侧带有变音符号的文本

当我将 x_offset 乘以 0.5 时，组合字符的位置会更好。重音和 cedilla 位于正确的 x 位置。重音不堆叠并且在 b 上太低。BBB (U+035C) 下的弧线应连接最后两个字母，而不是以第二个 b 为中心。

我还尝试在上一组 b 上使用 U+FE20 和 U+FE21。在我的测试中，U+FE21 在 2 号 b，但看起来它应该在 3 号。

用 glyphPos[i].x_offset * 0.5f 测试，更好但仍然错误

我尝试了几种字体，但在这些字体中，只有 NotoSansDisplay-Regular.ttf 具有组合字符。我没有设法让程序在我的 Debian 系统上按预期显示该字符串（使用 HarfBuzz 2.6.4-1 进行测试）。

使用 Windows，我得到了更好的结果。这就是我所期望的：重音是堆叠的，它下方的组合双短线在正确的位置，变音符号消失了。

文本渲染更接近我的预期

我是在使用 HarfBuzz 做错了什么，还是正在测试 HarfBuzz 支持的小众案例？

编辑：

上面没有描述实际问题。我用 FreeType 加载了一个字体，然后用 hb_ft_font_createFT_New_Face创建了一个字体。hb_font_t对于每个绘制的字符串，我都会调用FT_Set_Pixel_Sizes但保留它hb_font_t。

4

2 回答 2

2

您应该尝试使用 hb-view / hb-shape 塑造相同的文本和字体。这将帮助您缩小问题所在。我在做一个疯狂的猜测，问题在于您如何/是否在您的地图集中考虑字形起源。

于 2019-11-19T06:16:02.417 回答
0

每次更改字体大小时创建一个新hb_font_t的。hb_ft_font_createFT_Set_Pixel_Sizes

于 2019-11-22T01:26:56.153 回答