Bad y_offset from hb_buffer_get_glyph_positions (1.1.0 regression)

[tasn]

Hey,

There seems to be a regression with Harfbuzz 1.1.0. After updating to 1.1.0 users of Terminology (an EFL based terminal emulator) have been experiencing weird character offsets. We've narrowed down the problem to the y_offset returned by hb_buffer_get_glyph_positions.
For example, for one glyph in the 6x13 bitmap font shipped with my system, I used to get 0 as the y_offset, and now I get -1056 (16px in my case).
There's more info in the original terminology ticket ( https://phab.enlightenment.org/T2865 ), but according to one account, the cause is 44f8275. I personally don't see how that one might be related, but it is.

This break leads to a completely unusable application.

Let me know if you need any other information.

Thanks,
Tom.

[dairt]

Please check get_glyph_origin_for_direction in hb-font-private.hh

if (!get_glyph_h_origin (glyph, x, y) &&
    get_glyph_v_origin (glyph, x, y))
      {
        hb_position_t dx, dy;
        guess_v_origin_minus_h_origin (glyph, &dx, &dy);
        *x -= dx; *y -= dy;
      }

After 44f8275 the path goes through get_glyph_v_origin instead of the removed get_glyph_h_origin. For some reason the y (y_offset) value comes out wrong here.

Danny.

[behdad]

Oops. My bad. Will fix.

[tasn]

@behdad, thanks!
Please also do a bug fixing release. We have a lot of sad terminology users at the moment. :)

[dairt]

Thanks =)

[behdad]

On it. I created a slight mess. Will have a fix by the time my flight lands on the other side.

[behdad]

I'm curious. In hb_shape, I have these lines:

    if (c->font->has_glyph_h_origin_func ())
      for (unsigned int i = 0; i < count; i++)
    c->font->add_glyph_h_origin (info[i].codepoint,
                     &pos[i].x_offset,
                     &pos[i].y_offset);

ie. if glyph_h_origin_func is NOT set, it doesn't do anything. I'm curious why you see a different behavior.

[behdad]

ie. if glyph_h_origin_func is NOT set, it doesn't do anything. I'm curious why you see a different behavior.

The downstream bug has the answer:

Still not sure, but textgrid differs from textblock in shaping. It passes EVAS_TEXT_PROPS_MODE_NONE, while textblock passes EVAS_TEXT_PROPS_MODE_SHAPE. One uses the "fallback" shaper, while the other uses the "ot" shaper.

[behdad]

Release coming.

[behdad]

Released 1.1.2.

[tasn]

Thanks man.
On 27 Nov 2015 00:39, "Behdad Esfahbod" notifications@github.com wrote:

Released 1.1.2.

—
Reply to this email directly or view it on GitHub
#187 (comment).

[gregkh]

Fixes the issue for me, many thanks for the quick response.