rounding differences between harfbuzz and cairo

[matthiasclasen]

In pango 1.44, we've replaced cairo by harfbuzz for getting glyph extents. Some people complain that fonts are 'stretched' now (https://gitlab.gnome.org/GNOME/pango/issues/404).

Comparing 1.43 and 1.44, I find that i get this returned from cairo (note that the values here are rounded to multiples of 1024:

glyph 78 width 3072 
glyph 83 width 8192 
glyph 74 width 8192

And this is what i get from harfbuzz:

glyph 78 width 3652
glyph 83 width 8294
glyph 74 width 7964

the harfbuzz values are not rounded, that is ok. The issue here is that 3652 rounds to 4096, giving us an extra pixel of width for that glyph.

I haven't gotten to the bottom of why these values are different. I did notice that the scales of the font are similar enough to not be the reason: 15024 (with 1.43) vs 15019 (with 1.44).

[behdad]

What kind of hinting setting is that with?

[matthiasclasen]

everything is default:

font options: antialias 0 subpixel_order 0 hint-style 0 hint-metrics 0

i can turn hint-metrics off if you think it matters for what cairo returns

Look at that, it does:

glyph 78 advance 3652
glyph 83 advance 8294
glyph 74 advance 7964

This is cairo with hint-metrics off

[matthiasclasen]

Where does this leave us ? harfbuzz is giving me the same values are cairo with hint-metrics off.
But rounding those values on the pango side does not reproduce the same values as cairo with hint-metrics on.

[jfkthame]

On 07/08/2019 01:38, Matthias Clasen wrote: Where does this leave us ? harfbuzz is giving me the same values are cairo with hint-metrics off. But rounding those values on the pango side does not reproduce the same values as cairo with hint-metrics on.

Simply rounding metrics to integer pixel values is not the same as hinting them. The instructions in the font may decide to modify the nominal metrics (e.g. to maintain consistent stem widths or counters or sidebearings across a glyph like "m") more extensively than just rounding to pixels.

[mxmilkiib]

This issue was mentioned in #sway in regard to a font clipping/shrinking issue in sway-bar, but I'd like to confirm if this issue is actually related?

[bungeman]

Having read through the chain of issues (arch, two pango issues, and here) it looks like pango has dropped support for metric hinting? Looking through the changes I see where pango_fc_hb_font_get_glyph_advance was no longer set on the hb_font_funcs_t but I don't see where the hinting was restored. It appears the the raw font data is being passed to HarfBuzz, but HarfBuzz doesn't do hinting itself, and don't see a place where pango is creating an FT_Face to pass to HarfBuzz set up to return hinted metrics (I'm pretty sure it isn't doing this, otherwise BDF fonts would still work).

[khaledhosny]

Yes, Pango uses HarfBuzz OT font function and thus intentionally not using hinted metrics. I don’t think there is any issue to fix here, everything is working as intended.

[bungeman]

I suppose my point was that pango appears to now be incapable of doing layout with hinted metrics, but users are still drawing with hinted glyphs... leading to less than desirable spacing (Chromium had this issue for a while, I think it's mostly fixed now). HarfBuzz is working as intended, but I'm not sure that pango realized that it was dropping support for hinting here. At the very least the FT_Face returned from pango_fc_font_lock_face may have hinting set (which the user may use to render) which the shaper never used when computing metrics.

I suppose this explanation is getting to the point where it would be better to comment on the upstream issue. I just wanted to explicitly point out here the HarfBuzz behavior around not hinting since the effect of that hadn't yet been explicitly called out (this probably isn't just a rounding issue).

[khaledhosny]

It is my understanding that the switch to unhinted metrics was intentional , see the last paragraph in https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/. But I agree that Pango should then render unhinted glyphs, by setting suitable cairo font options.

[behdad]

Where does this leave us ? harfbuzz is giving me the same values are cairo with hint-metrics off.
But rounding those values on the pango side does not reproduce the same values as cairo with hint-metrics on.

Right. Also need to turn hinting off, or to 'slight' which disable horizontal hinting.

[matthiasclasen]

Right. Also need to turn hinting off, or to 'slight' which disable horizontal hinting.

Always, you mean ? Or only when we are not rounding glyph positions ?

This
https://gitlab.gnome.org/GNOME/pango/commits/hinting does it only when we are doing subpixel positioning. But I am not sure how it can address the complaints we get now, since subpixel positioning is not turned on currently.

[khaledhosny]

You don’t want hinting to change the advance width, regardless of whether the positions are rounded or not.

[behdad]

Right. Also need to turn hinting off, or to 'slight' which disable horizontal hinting.

Always, you mean ? Or only when we are not rounding glyph positions ?

When you and I agreed on a plan, it was to enable subpixel positioning, which lets us disable horizontal hinting, which would enable us using HarfBuzz font funcs.

[matthiasclasen]

Yes, we just need to get on with it, by getting a cairo release out