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

[Ede123]

So, do I understand correctly that on back-ends that do not support subpixel positioning (notably win32 according to https://gitlab.gnome.org/GNOME/pango/issues/385) we still won't use horizontal hinting anymore and - consequently - will end up with bad font rendering (at least on "normal" displays that not have high DPI)?

Even subpixel positioning is usually a lot less readable compared to a font that's properly hinted for screen display.

I can understand that the general direction outlined in https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ is desirable in the long-term, but it sounds a bit premature, considering high-DPI displays are far from being standard today.

[madig]

Side-note:

will end up with bad font rendering [...] Even subpixel positioning is usually a lot less readable compared to a font that's properly hinted for screen display.

All browsers on Windows use DirectWrite, which doesn't do much horizontal grid fitting and uses subpixel positioning, even on today's screens. Most fonts out there don't even have horizontal hinting. It's fine.

[ubitux]

This is a followup on the initial pango issue reported (apparently the discussion continues here). The issue was mentioning Roboto, and I can also reproduce it with ProFont (https://tobiasjung.name/profont/ - OTB version, the one released in order to address the PCF/BDF issue):

Using pango-view -q --background=black --foreground=white --font="ProFont 8" /tmp/test.txt between pango-1.43 and pango-1.44.7 leads to the following horizontal spacing issue:

1.43:

1.44:

The 2nd output is definitely not desired.

[tritonas00]

Yep, another example with the spacing issue (lxpanel)

Before

After

[epico]

Just checked the original ProFont bitmap fonts and converted ProFont OpenType fonts with ftdump.

Maybe the ppem value is relevant to this issue.

PCF font:
fixed size
     0: height 12, width 8
        size 11.953, x_ppem 11.953, y_ppem 11.953

OTB font:
fixed size
     2: height 12, width 3
        size 12.000, x_ppem 12.000, y_ppem 12.000

[last-partizan]

Hey, any news on this?

[khaledhosny]

There is nothing to fix here in HarfBuzz, it is a Pango issue.

[Ede123]

@khaledhosny Which is/are the relevant Pango issue(s) then?

It seems there are multiple downstream issues that depend on this one so we can't just close it without properly tracking it somewhere else:

• https://gitlab.gnome.org/GNOME/pango/issues/404#note_575986 suggests the downstream issue should be discussed here (it's still open).
• https://gitlab.gnome.org/GNOME/pango/issues/385#note_583927 also refers to this issue and the downstream issue was even closed in favor of the issue here.

So apparently at least @matthiasclasen intended to continue the discussion here...

I don't really have enough insight into harfbuzz/pango/cairo to know where the issues need to be tracked (I hope people with more insight can figure out this part and make sure it's tracked properly). There seem to be at least two blocking issues made visible with pango 1.44 which still have no fix:

• Different subpixel positioning between pango/harfbuzz (for backends that actually support subpixel positioning) which results in different rendering in pango 1.44.
• Complete loss of hinting in pango 1.44, which is particularly bad for backends that do not support subpixel positioning at all.

[tritonas00]

Nothing is going to happen until I have time to get back to it or somebody else starts working on this.

¯\_(ツ)_/¯

and i cant even keep pango downgraded on Arch because programs need 1.44 😟

[Ede123]

It's still held back on MSYS2 because of https://gitlab.gnome.org/GNOME/pango/issues/385.

[khaledhosny]

@khaledhosny Which is/are the relevant Pango issue(s) then?

It seems there are multiple downstream issues that depend on this one so we can't just close it without properly tracking it somewhere else:

* https://gitlab.gnome.org/GNOME/pango/issues/404#note_575986 suggests the downstream issue should be discussed here (it's still open).

* https://gitlab.gnome.org/GNOME/pango/issues/385#note_583927 also refers to this issue and the downstream issue was even closed in favor of the issue here.

So apparently at least @matthiasclasen intended to continue the discussion here...

The discussion here is already resolved, HarfBuzz is working as intended and there is nothing broken in it to fix.

[madig]

I believe the current blocker for forward progress is

#1892 (comment)
[...] getting a cairo release out

? I see some commits by @matthiasclasen about subpixel positioning in https://gitlab.freedesktop.org/cairo/cairo/commits/master that are unreleased. Behdad asked for a new release on the mailing list back in August: https://lists.cairographics.org/archives/cairo/2019-August/028910.html. No one responded.