Font rendering issue (synthetic font styles)

[clason]

I have a persistent issue with font rendering under gnvim (on Linux, OpenSUSE Tumbleweed, built from master) where some monospace fonts do not render correctly if the color scheme uses (synthetic) bold: e.g., with the Inconsolata font and the colorscheme https://github.com/mhartington/oceanic-next, I get the following behavior:

1. set ft=tex
2. type \foobarbaz{quux} (doesn't matter as long as it starts with \ and ends with { -- the longer, the more obvious the error)

Result in gnvim: (note the incorrect widths of the text in red)

Result in TUI (gnome-terminal 3.32.2 using VTE 0.56.3): (note that the text in red is not fake-bolded).

The same font and scheme also renders correctly in neovim-qt and konsole. I have the same issue in neovim-gtk, so it's probably an issue with the Cairo or Pango font rendering. I've searched around and found no real solution on the net; if anyone can point me in the right direction, that'd be appreciated. (Let me know what information you need: versions of which software etc.)

[vhakulinen]

Can you show how it looks in the TUI and paste the code here in the github issue tracker?

[clason]

@vhakulinen Sorry, took some time to get back to the same machine. I updated (and simplified) the original issue.

[smolck]

@clason What version of GNvim and GTK are you using? Can't seem to reproduce with Inconsolata and OceanicNext on latest master. Here's how it looks in GNvim when I do what you said, with GTK version 3.24.10:

[clason]

@smolck It's GNvim HEAD (but the issue has been around since I started looking at GNvim), and GTK 3.32.2 -- same as gnome-terminal, which doesn't show the issue. I don't believe it's a GTK issue, but rather Pango (similarly to #85) -- what's your Pango version?

[smolck]

@clason Just updated pango recently, and I get the same problem with Fantasque Sans Mono Bold and Iceberg.vim colors. I'm almost certain this issue and #85 are resulting from pango's update, since I didn't see the problem before updating (and neovim-gtk/208 seems to point towards it being a pango issue as well).

@vhakulinen #85 is (I believe) caused by the pango update too, so it and this issue are only different results of the pango update. It seems that a refactor will need to take place to fix these issues, and I'm happy to help where I can. Note that I also am having a problem where the statusline is not showing on the bottom of GNvim, which I think is caused by the update too. We may want to open an issue on how we want to do the refactor, but I don't know if that's necessary.

@badosu Would you be able to update pango and test this?

See neovim-gtk/208.

[smolck]

After some debugging, the calculations from this function (CellMetrics::update in context.rs) are different with the new pango version (here is the output of dbg!(&self) at the end of the function):

After the pango update (~v1.44):

[src/ui/grid/context.rs:235] &self = CellMetrics {
    height: 18.3193359375,
    width: 7.0,
    ascent: 14.330078125,
    decent: 3.9892578125,
    underline_thickness: 2.0,
    underline_position: -1.0,
    line_space: 0,
    font_desc: FontDescription(
        Boxed {
            inner: ForeignOwned(
                0x0000556f53c936d0,
            ),
        },
    ),
}

Before the pango update (~v1.43):

[src/ui/grid/context.rs:235] &self = CellMetrics {
    height: 19.0,
    width: 8.0,
    ascent: 15.0,
    decent: 4.0,
    underline_thickness: 2.0,
    underline_position: -1.0,
    line_space: 0,
    font_desc: FontDescription(
        Boxed {
            inner: ForeignOwned(
                0x0000561f5b7c5d30,
            ),
        },
    ),
}

It's like the new update made things more precise or something? Not sure of the cause of this difference, or if this is what causes the issue with font rendering. Any ideas?

CC: @badosu @vhakulinen

[clason]

@smolck Yes, see https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/ (under "Subpixel positions"). From my own concurrent tries to get at the bottom of this, subpixel hinting is my main suspect as well (since Inconsolata, but not other fonts, got unbroken by reverting the hinting to vendor default -- this was under 1.43, though).

My current theory is that my distribution -- having KDE as main desktop -- has a mismatched (i.e., non-optimal) pairing of Pango and Cairo libraries.

It's also worth browsing the Pango issue tracker -- unfortunately, a disheartening number of complaints are dismissed as wontfix.

[smolck]

So, in theory, we could fix this by adding support for subpixel positioning in GNvim (note that I don’t know much about how font rendering and such works)? Would that be feasible?

Alternatively, we could round the fonts such that they are rendered like they used to be?

[vhakulinen]

Seems like you already hunted down the likely source of this bug.

A poor man's solution for fixing this would be to round up the cell metrics, but I'd rather see gnvim to support subpixel positioning if possible.

[clason]

@vhakulinen To be honest, I had the same issue already with pango 1.43, so that can't be the whole story (at least for me). Still, the pango 1.44 issue seems to be much more widespread, and a fix for that just might work for me as well!

[smolck]

. . . but I'd rather see gnvim to support subpixel positioning if possible.

@vhakulinen Do you have an idea of how you’d want this done? I haven’t looked into it, but it shouldn’t be too difficult, right?

[vhakulinen]

I'm not sure yet, but ceiling the values we pass into queue_draw_area could be a starting point and see how that helps. AFAIK just casting floats to i32 (as we do currently) just drops the decimals effectively flooring the values.

[last-partizan]

@vhakulinen take a look at this commit in pango: https://gitlab.gnome.org/GNOME/pango/commit/77b78746c901f95ca45a9ccffe9c32a38c0fb32b

[smolck]

. . . take a look at this commit in pango: https://gitlab.gnome.org/GNOME/pango/commit/77b78746c901f95ca45a9ccffe9c32a38c0fb32b

Once this hits Arch/the AUR, I'll test it (it hasn't yet AFAIK). If our problems are due to subpixel positioning, that commit should fix it (right?). If not, then we'll need to keep searching for the actual problem. Either way, I'm glad they decided to default to rounding as it used to be.

[cljoly]

Disclaimer: I took the occasion to learn how PKGBUILD works. I could be completely wrong.

It looks like pango-git in AUR always builds from the last commit.

When I tried to install package pango-git, it reported installing version from commit e160a3cd, which is current master and after 77b78746. This would be consistent with [pkgver autobump](https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function) and what we can read from the PKGBUILD of pango-git.

Spoiler alert: I had the problems described here with pango 1.44, solved by downgrading to 1.43 but not solved by upgrading to master.

[smolck]

@leowzukw Are you sure? At the bottom of the package details for pango-git on the AUR it says Last Updated: 2019-08-02 01:00, and the commit in question was authored on August 3rd at 7:59pm according to GitLab (says that time when I hover over the 1 day ago part of authored 1 day ago under the commit on this page). I assumed that meant pango-git's outdated, but I may be wrong.

[cljoly]

I can’t be positive but when you try manually building the package, the makepkg commands modifies the version number in the PKGBUILD file. And it is to the last version after that (i.e. last commit on master).

[cljoly]

Found something else arguing for the auto-update feature.

Because these packages download the latest available source when you execute makepkg

[smolck]

Hmm, didn't know that. I guess we had better keep looking into why the problems arise. Thanks @leowzukw for the info!

[vhakulinen]

Further pango 1.44 discussions in #85. Original issue here doesn't seem to be related to pango 1.44.

[vhakulinen]

After much of research: you can either use a font that has a bold styled font or disable synthetic styles system wide (I guess by removing /etc/fonts/conf.d/90-synthetic.conf).

We could also, in gnvim, load up fonts manually and thus bypassing any creating of synthetic/fake fonts withing gtk/pango/fontconfig and what not or detect synthetic fonts in the rendering process by calling pango_font_face_is_synthesized and skipping bold styles if that returns true. And PRs for this are welcome. I'm not too familiar with the whole font pipeline and thus don't have much more pointers for where to look at.

[clason]

@vhakulinen Thank you! Disabling synthetic bold through the conf.d file is a good workaround that works for my original problem. (I'm leaving the open for now in case someone has an idea about the original pango/cairo rendering problem, but feel free to close it whenever you like as upstream issue and workaround-exists.)

[vhakulinen]

Be aware that the /etc/fonts/conf.d/90-synthetic.conf affects the whole system.

I'll leave this open for now.

[clason]

I know, but a) it doesn't seem to affect Qt applications and b) I had the same issue in other pango-based editors, so for me the global effect is reasonable.

Actually, this workaround can be made more specific by creating a ~/.config/fontconfig/fonts.conf with

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="font">
        <test name="spacing" compare="eq">
            <const>mono</const>
        </test>
        <edit name="embolden" mode="assign">
            <bool>false</bool>
        </edit>
    </match>
</fontconfig>

and making sure the user.conf is loaded after the synthetic.conf (from https://askubuntu.com/a/106890). One could even add a test name="family" to disable synthetic bold only for a single font.

[isovector]

I just ran into this issue today, installing gnvim from AUR. The workaround above didn't resolve the issue for me.

$ pacman -Q | grep "pango\|gnvim"
gnvim-git r273.65846f4-1
pango 1:1.44.7+11+g73b46b04-1

---

edit; fixed this by downgrading pango to 1.43