Bug#956612: libpango-1.0-0: broken kerning since 1.44

Simon McVittie smcv at debian.org
Fri Jun 26 10:53:09 BST 2020


Control: forwarded -1 https://gitlab.gnome.org/GNOME/pango/-/issues/404

On Fri, 26 Jun 2020 at 09:46:10 +0200, Yves-Alexis Perez wrote:
> On Fri, 2020-06-26 at 00:16 +0200, Cyril Brulebois wrote:
> > I thought severity was higher than that. Reasoning for serious is that
> > rendering looks ***bad*** plus this breaking d-i's automated testing.
> > 
> > I'm told desktop users also suffer from that (cc-ing Corsac for a
> > possible confirmation).
> 
> Yes indeed. If it's not possible to investigate this in Debian, at least
> pushing it upstream would be nice.

There are several upstream bugs open about font rendering being different
in 1.44.x. It probably doesn't help that many of them can be summarized
as "fonts look bad now" rather than something more specific, leading to
it being difficult to tell what the problem is or when/whether it has
been fixed.

The extent to which font rendering differs between pango 1.42 and
1.44 depends on the font, hinting settings and probably other factors,
leading to the impact of this bug varying between "not noticeable" and
"difficult to read" depending on those various factors. I haven't noticed
this being a problem in GNOME, which might mean that fonts-cantarell is
one of the unaffected fonts, or might be to do with my font settings.

https://gitlab.gnome.org/GNOME/pango/-/issues/404 is probably the closest
match among upstream issues. Comments from an upstream developer indicate
that there is a behaviour change in pango involving harfbuzz and cairo:

> The underlying change here is that we are now getting glyph extents
> via harfbuzz, instead of via cairo.
>
> For glyph 78 in that output above, cairo returns 3072 and harfbuzz 3652,
> which we then round to 4096, so we end up wiht a one-pixel difference.

This is presumably measuring in some internal unit that is a small
fraction of a pixel, with actual sizes having to be rounded to the
nearest whole pixel if subpixel positioning is not used.

https://github.com/harfbuzz/harfbuzz/issues/1892 appears to be related. A
comment on that issue suggests that the way forward for pango involves
getting an upstream cairo release out, possibly so that pango and
cairo agree on the way they use harfbuzz (same hinting settings, etc.),
or so that text can be rendered with subpixel positioning so the rounding
becomes unnecessary? (This is really not my area of expertise, so I might
be entirely wrong about this, and I am not the right person to be
developing a patch.)

    smcv



More information about the pkg-gnome-maintainers mailing list