`Systemd-analyze critical-chain` missing first characters in returned unit names #203

Closed
opened 1 year ago by carbonchauvinist · 14 comments

Running systemd-analyze critical-chain in foot (foot-git 1.5.3.r193.g134e1d3-1) has the unit names missing the first character on every line except the first in the hierarchy (see attached screen grab for reference).

I've verified this is not the case with other terminals installed (e.g. sakura) and that this happens in or out of a tmux session.

Interestingly, the character is actually there because if I copy from the screen buffer and paste into another application the missing character comes along.

Please let me know if I can provide any more info.

Running `systemd-analyze critical-chain` in foot (foot-git 1.5.3.r193.g134e1d3-1) has the unit names missing the first character on every line except the first in the hierarchy (see attached screen grab for reference). I've verified this is not the case with other terminals installed (e.g. sakura) and that this happens in or out of a tmux session. Interestingly, the character is actually there because if I copy from the screen buffer and paste into another application the missing character comes along. Please let me know if I can provide any more info.
dnkl commented 1 year ago
Owner

Sounds like a font issue.

  • Are you using the same font in all terminals?
  • Does it work if you set tweak.allow-overflowing-double-width-glyphs=no in foot.ini?
Sounds like a font issue. * Are you using the same font in all terminals? * Does it work if you set `tweak.allow-overflowing-double-width-glyphs=no` in `foot.ini`?
dnkl commented 1 year ago
Owner

Can you paste that square angle character (that is at the beginning of each line) here?

Can you paste that square angle character (that is at the beginning of each line) here?

You're right it seems to be related to a font issue; I changed the font from my "sf mono" usual to "cousine" in foot.ini and the issue went away.

Though, with that being said -- adding

[tweak]

allow-overflowing-double-width-glyphs=no

to my foot.ini fixed the issue even using the affected font (sf mono).

Here's the character(s) (note it's two characters for me), pasted from the font that's giving me issue (in case that matters) with the tweak you gave me enabled:

└─
and with the tweak you gave me disabled (again in case that makes a difference?)
└─

You're right it seems to be related to a font issue; I changed the font from my "sf mono" usual to "cousine" in foot.ini and the issue went away. Though, with that being said -- adding ``` [tweak] allow-overflowing-double-width-glyphs=no ``` to my foot.ini fixed the issue even using the affected font (sf mono). Here's the character(s) (note it's two characters for me), pasted from the font that's giving me issue (in case that matters) with the tweak you gave me enabled: `└─` and with the tweak you gave me disabled (again in case that makes a difference?) `└─`
dnkl commented 1 year ago
Owner

and with the tweak you gave me disabled (again in case that makes a difference?)

No, allow-overflowing-double-width-glyphs is cosmetical only. It doesn't affect the contents of the cells, only how the are rendered. Sorry, I should have been clearer, but was in a bit of a hurry.

└─

yeah, that's two characters: BOX DRAWINGS LIGH UP AND RIGHT and BOX DRAWINGS LIGHT HORIZONTAL. Both should have a display width of 1. That makes me think you primary font, sf mono, doesn't have these glyphs, and that foot is loading them from a fallback font. Fallback fonts doesn't necessarily match the primary font's cell width (not exactly anyway), which means the glyphs can overlap. This is especially true if the fallback font is a non-monospace font.

You can see if this is happening by running foot sh from another terminal (so that you see the log output). You should see four fonts being loaded at startup: your primary font in regular/bold/italic/bold+italic). Then, paste └─. If it says it's loading another font, then that's the fallback font.

Anyway. Normally, overlapping glyphs are cropped by foot. I.e. they are not allowed to overlap. However, in order to handle icon fonts, like Font Awesome, or Material Design Icons (and Powerline?), and legacy emojis with a display width of 1 (e.g. ☹), foot tries to detect single-width characters with double-width glyphs, and allows these to overlap.

Setting allow-overflowing-double-width-glyphs=no disables this behavior.

This was initially disabled by default, but I recently changed that in 5b43477cc2.

What does all this mean? Well, if it is loading it from a fallback font, one option is to change the fallback list for sf mono. Either in FontConfig, or by customizing foot's own fallback list.

Another option is that I revert 5b43477cc2. I.e. make allow-overflowing-double-width-glyphs=no the default again.

But, I'm hoping a better solution is to tighten the requirements for when foot is allowed to overflow glyphs. Can you test #205, with sf mono, and with allow-overflowing-double-width-glyphs=yes?

> and with the tweak you gave me disabled (again in case that makes a difference?) No, `allow-overflowing-double-width-glyphs` is cosmetical only. It doesn't affect the contents of the cells, only how the are rendered. Sorry, I should have been clearer, but was in a bit of a hurry. > `└─` yeah, that's two characters: `BOX DRAWINGS LIGH UP AND RIGHT` and `BOX DRAWINGS LIGHT HORIZONTAL`. Both should have a display width of 1. That makes me think you primary font, sf mono, doesn't have these glyphs, and that foot is loading them from a fallback font. Fallback fonts doesn't necessarily match the primary font's cell width (not exactly anyway), which means the glyphs can overlap. This is especially true if the fallback font is a non-monospace font. You can see if this is happening by running `foot sh` from another terminal (so that you see the log output). You should see **four** fonts being loaded at startup: your primary font in regular/bold/italic/bold+italic). Then, paste `└─`. If it says it's loading another font, then that's the fallback font. Anyway. Normally, overlapping glyphs are cropped by foot. I.e. they are **not** allowed to overlap. However, in order to handle icon fonts, like _Font Awesome_, or _Material Design Icons_ (and _Powerline_?), and _legacy_ emojis with a display width of 1 (e.g. ☹), foot tries to detect **single-width characters** with **double-width glyphs**, and allows these to overlap. Setting `allow-overflowing-double-width-glyphs=no` disables this behavior. This was initially disabled by default, but I recently changed that in https://codeberg.org/dnkl/foot/commit/5b43477cc27bf5e6ea4dd4ad821efd0141e6ce3f. What does all this mean? Well, **if** it is loading it from a fallback font, one option is to change the fallback list for sf mono. Either in FontConfig, or by customizing foot's own fallback list. Another option is that I revert https://codeberg.org/dnkl/foot/commit/5b43477cc27bf5e6ea4dd4ad821efd0141e6ce3f. I.e. make `allow-overflowing-double-width-glyphs=no` the default again. But, I'm hoping a better solution is to tighten the requirements for when foot is allowed to overflow glyphs. Can you test https://codeberg.org/dnkl/foot/pulls/205, with sf mono, and with `allow-overflowing-double-width-glyphs=yes`?

Thanks for the detailed explanation of what's going on - I do appreciate it.

When back at my laptop this evening I'll make sure to test a different fallback font for the sf mono; my guess is that your hypothesis is right and that those glyphs are being drawn with a different font. If so, I'll change the fallback font and that should be good enough for me.

I'll also make sure to test #20, with sf mono and with allow-overflowing-double-width-glyphs=yes and report back as well.

Thanks for the detailed explanation of what's going on - I do appreciate it. When back at my laptop this evening I'll make sure to test a different fallback font for the sf mono; my guess is that your hypothesis is right and that those glyphs are being drawn with a different font. If so, I'll change the fallback font and that should be good enough for me. I'll also make sure to test [#20](https://codeberg.org/dnkl/foot/pulls/20), with sf mono and with `allow-overflowing-double-width-glyphs=yes` and report back as well.
dnkl commented 1 year ago
Owner

Can you test #20

Sorry, made a typo there. Should be #205

> Can you test #20 Sorry, made a typo there. Should be https://codeberg.org/dnkl/foot/pulls/205
dnkl added the
bug
label 1 year ago

You can see if this is happening by running foot sh from another terminal (so that you see the log output). You should see four fonts being loaded at startup: your primary font in regular/bold/italic/bold+italic). Then, paste └─. If it says it’s loading another font, then that’s the fallback font.

So I confirmed that we're not pulling a fallback font using the method you described above.

I also was able to test #205 with allow-overflowing-double-width-glyphs=yes and the issue was not present (see attached for screen grab).

> You can see if this is happening by running foot sh from another terminal (so that you see the log output). You should see four fonts being loaded at startup: your primary font in regular/bold/italic/bold+italic). Then, paste └─. If it says it’s loading another font, then that’s the fallback font. So I confirmed that we're not pulling a fallback font using the method you described above. I also was able to test #205 with `allow-overflowing-double-width-glyphs=yes` and the issue was not present (see attached for screen grab).
dnkl commented 1 year ago
Owner

So I confirmed that we’re not pulling a fallback font using the method you described above.

Interresting. That suggests your monospace font isn't monospace after all... Or that its metrics is wrong - perhaps the font designer intended a wider letter spacing.

If you want to, we can dig further into this. It would basically amount to rebuilding foot against a patched fcft. Initially just to log more font metric details.

I also was able to test #205 with allow-overflowing-double-width-glyphs=yes and the issue was not present (see attached for screen grab)

Good! Hopefully we can merge that one soon.

> So I confirmed that we’re not pulling a fallback font using the method you described above. Interresting. That suggests your monospace font isn't monospace after all... Or that its metrics is wrong - perhaps the font designer intended a wider letter spacing. If you want to, we can dig further into this. It would basically amount to rebuilding foot against a patched fcft. Initially just to log more font metric details. > I also was able to test #205 with allow-overflowing-double-width-glyphs=yes and the issue was not present (see attached for screen grab) Good! Hopefully we can merge that one soon.

If you want to, we can dig further into this. It would basically amount to rebuilding foot against a patched fcft. Initially just to log more font metric details.

I'm up for this if you think it it's worthwhile.

Good! Hopefully we can merge that one soon.

I will point out, and this may be an issue with my font specifically, and also the fact that I know which letter/glyph was missing initially and therefore I'm paying closer attention to it than I would otherwise... but one can see that the first letter after the BOX DRAWINGS LIGHT UP AND RIGHT and BOX DRAWINGS LIGHT HORIZONTAL is quite squished/compressed (for instance take a look at the "m" in "multi-user.target..." line in the attached image). Is that a byproduct of the fact that my font may not actually be truly mono? Or is something else at play here?

Thanks again for creating and sharing this great tool. And I must add that one of the reasons I switched to your foot terminal as my daily driver in the first place is the way it handled fonts "out of the box". Without any additional configuration on my end, it just seemed noticably better to my eyes than any other terminals I'd been using in the past.

> If you want to, we can dig further into this. It would basically amount to rebuilding foot against a patched fcft. Initially just to log more font metric details. I'm up for this if you think it it's worthwhile. >Good! Hopefully we can merge that one soon. I will point out, and this may be an issue with my font specifically, and also the fact that I know which letter/glyph was missing initially and therefore I'm paying closer attention to it than I would otherwise... but one can see that the first letter after the `BOX DRAWINGS LIGHT UP AND RIGHT` and `BOX DRAWINGS LIGHT HORIZONTAL` is quite squished/compressed (for instance take a look at the "m" in "multi-user.target..." line in the attached image). Is that a byproduct of the fact that my font may not actually be truly mono? Or is something else at play here? Thanks again for creating and sharing this great tool. And I must add that one of the reasons I switched to your foot terminal as my daily driver in the first place is the way it handled fonts "out of the box". Without any additional configuration on my end, it just seemed noticably better to my eyes than any other terminals I'd been using in the past.
dnkl commented 1 year ago
Owner

I’m up for this if you think it it’s worthwhile.

I was debugging another font issue and since AUR had sf mono, I installed it and did it myself :)

Here's the metrics for some common characters:

info: fcft.c:680: 'A': advance=17, bitmap width: 16, c-offset=1
info: fcft.c:680: 'M': advance=17, bitmap width: 15, c-offset=1
info: fcft.c:680: 'W': advance=17, bitmap width: 18, c-offset=0
info: fcft.c:680: '#': advance=17, bitmap width: 17, c-offset=0
info: fcft.c:680: 'f': advance=17, bitmap width: 14, c-offset=2
info: fcft.c:680: '─': advance=17, bitmap width: 23, c-offset=-3

The advance width is what foot uses as cell width. So in that sense, the font is monospace. However, looking at the , we see that it is much wider. It is intended (by the font designer) to extend 3px outside the cell on both left and right side.

I have no idea why. Box characters are supposed to cover the entire cell. Not less, not more. And this one is off by too much for it to be a rounding error.

#198 would fix this.

but one can see that the first letter after the BOX DRAWINGS LIGHT UP AND RIGHT and BOX DRAWINGS LIGHT HORIZONTAL is quite squished/compressed (for instance take a look at the “m” in “multi-user.target...” line in the attached image).

I think this is mostly an impression; the box character covers the entire cell width, making it end up closer to the next character than other characters do. Furthermore, m is usually one of the widest characters in a monospace font, and it too will typically cover the entire cell. Put those two together and things get tight.

It might also be that a single sub-pixel column is shaved off from m. Foot, or fcft really, uses font metrics provided by FreeType. It (FreeType) notes that antialiased glyphs may be slightly wider than what the font metrics indicate. We can't "widen" the cells to accomodate this, because a) we don't know by how much to widen it, and b) it would make the character spacing wrong, and the font would look really bad.

This isn't a problem for applications that render whole text runs, but for a grid/cell based application it is a problem. For foot, the major problem is that each cell is rendered indvidually. Another problem is that cells in a terminal emulator can all have different attributes. In particular, different foreground and background colors; rendering antialiased glyphs (that bleed into neighbouring cells) correctly is impossible in this case.

This is a very similar issue to #207.

Thanks again for creating and sharing this great tool. And I must add that one of the reasons I switched to your foot terminal as my daily driver in the first place is the way it handled fonts “out of the box”

Thanks! I have no idea what I did, but must have done something right...

> I’m up for this if you think it it’s worthwhile. I was debugging another font issue and since AUR had sf mono, I installed it and did it myself :) Here's the metrics for some common characters: ``` info: fcft.c:680: 'A': advance=17, bitmap width: 16, c-offset=1 info: fcft.c:680: 'M': advance=17, bitmap width: 15, c-offset=1 info: fcft.c:680: 'W': advance=17, bitmap width: 18, c-offset=0 info: fcft.c:680: '#': advance=17, bitmap width: 17, c-offset=0 info: fcft.c:680: 'f': advance=17, bitmap width: 14, c-offset=2 info: fcft.c:680: '─': advance=17, bitmap width: 23, c-offset=-3 ``` The advance width is what foot uses as cell width. So in that sense, the font **is** monospace. However, looking at the `─`, we see that it is **much** wider. It is **intended** (by the font designer) to extend 3px **outside** the cell on both left and right side. I have no idea _why_. Box characters are supposed to cover the entire cell. Not less, not more. And this one is off by too much for it to be a rounding error. https://codeberg.org/dnkl/foot/issues/198 would fix this. > but one can see that the first letter after the BOX DRAWINGS LIGHT UP AND RIGHT and BOX DRAWINGS LIGHT HORIZONTAL is quite squished/compressed (for instance take a look at the “m” in “multi-user.target...” line in the attached image). I think this is mostly an impression; the box character covers the entire cell width, making it end up closer to the next character than other characters do. Furthermore, `m` is usually one of the widest characters in a monospace font, and it too will typically cover the entire cell. Put those two together and things get tight. It _might_ also be that a single sub-pixel column is shaved off from `m`. Foot, or fcft really, uses font metrics provided by FreeType. It (FreeType) notes that antialiased glyphs may be slightly wider than what the font metrics indicate. We can't "widen" the cells to accomodate this, because a) we don't know by how much to widen it, and b) it would make the character spacing wrong, and the font would look really bad. This isn't a problem for applications that render whole text runs, but for a grid/cell based application it is a problem. For foot, the major problem is that each cell is rendered indvidually. Another problem is that cells in a terminal emulator can all have different attributes. In particular, different foreground and background colors; rendering antialiased glyphs (that bleed into neighbouring cells) correctly is impossible in this case. This is a very similar issue to https://codeberg.org/dnkl/foot/issues/207. > Thanks again for creating and sharing this great tool. And I must add that one of the reasons I switched to your foot terminal as my daily driver in the first place is the way it handled fonts “out of the box” Thanks! I have no idea _what_ I did, but must have done _something_ right...

I was debugging another font issue and since AUR had sf mono, I installed it and did it myself :) ...

Thanks for the detailed and thorough response, I do appreciate your time!

I think this is mostly an impression...This is a very similar issue to #207.

OK, I understand, there's not much one can do about these one-off "irregularities" within specific fonts. Thanks again for looking into it.

Will this issue automatically close when you merge in #205? Or should I close it out now?

> I was debugging another font issue and since AUR had sf mono, I installed it and did it myself :) ... Thanks for the detailed and thorough response, I do appreciate your time! > I think this is mostly an impression...This is a very similar issue to #207. OK, I understand, there's not much one can do about these one-off "irregularities" within specific fonts. Thanks again for looking into it. Will this issue automatically close when you merge in #205? Or should I close it out now?
dnkl commented 1 year ago
Owner

It'll close automatically

It'll close automatically

Thanks! I have no idea what I did, but must have done something right...

It must be fcft no?

a small font loading and glyph rasterization library

Can I bother you for a quick answer as to what other terminals would use in place of fcft? (Doesn't have to be extremely detailed answer, I know your time is valuable)

I know you've stated that fcft is:

built on-top of FontConfig, FreeType2 and pixman

so would it be the glyph rasterization that you're doing in fcft that makes fonts just appear plain better in foot?

> Thanks! I have no idea _what_ I did, but must have done _something_ right... It must be fcft no? > a small font loading and glyph rasterization library Can I bother you for a quick answer as to what other terminals would use in place of fcft? (Doesn't have to be extremely detailed answer, I know your time is valuable) I know you've stated that fcft is: > built on-top of FontConfig, FreeType2 and pixman so would it be the glyph rasterization that you're doing in fcft that makes fonts just appear plain better in foot?
dnkl closed this issue 1 year ago
dnkl commented 1 year ago
Owner

Can I bother you for a quick answer as to what other terminals would use in place of fcft?

GTK-based terminals typically use Pango (which uses FontConfig and Harfbuzz, and at least used to use FreeType - they have been moving more logic over to Harfbuzz, but I think FreeType is still used for rasterizing).

QT-applications uses QT. Fairly sure they also use FontConfig+FreeType+Harfbuzz.

I believe both GTK and QT have ways/settings that overrides some aspects of FontConfig.

so would it be the glyph rasterization that you’re doing in fcft that makes fonts just appear plain better in foot?

It’s true that fcft is where the glyphs are rasterized. Foot “only” composites the glyphs (i.e. does alpha blending). But fcft itself doesn’t rasterize the glyphs; that’s FreeType.

One can roughly describe the relationship between FontConfig, FreeType, pixman and fcft like this:

fcft uses FontConfig to locate which font to load, and which options to apply (should we do antialiasing? Which kind of antialiasing? and lots more). These options need to be converted to FreeType API calls. There’s no automated way to do that, and it’s up to fcft to act as glue between the two. This is one area where things can be different between different font rendering libraries: which FontConfig options do you recognize and how do you translate them to FreeType?

FreeType then rasterizes the glyph into a mask. For bitmap fonts, this is basically a 0 or a 1 for each pixel, indicating whether that pixel should be opaque or transparent. Grayscale antialiased glyphs are similar, but have 256 alpha levels instead of just two, where 255 is completely opaque and 0 is transparent.

pixman is used by fcft as a middle layer between the FreeType rasterized mask and the application (e.g. foot). That is, fcft takes the FreeType mask and simply converts it to a pixman image.

You are a bit vague on how fcft/foot renders fonts better than other applications; it could be letter spacing, but I don’t think that’s it. More likely, it is how hinting and antialiasing is applied. That is, how FontConfig options are translated to FreeType. I don’t think fcft doesn’t anything special here. urxvt for example, doesn’t use fontconfig so needs to be configured differently. Or take GNOME, which may override default hinting and antialiasing, resulting in different looking fonts.

In my experience, the default FontConfig settings are pretty good. The problems begin when applications have their own settings that override FontConfig. That’s when you need to manually tweak things.

In foot it is pretty easy to test different fontconfig settings without changing the system defaults. You can simply append fontconfig options to the fonts in foot, or use the --font command line option. For example, to disable antialiasing completely, you can do foot -f <name>:antialias=false.

Or to explicitly use grayscale antialiasing (assuming antialiasing is enabled): foot -f <name>:rgba=none. Or to use RGB sub-pixel antialiasing: foot -f <name>:rgba=rgb. These two examples wont work if you have explicitly configured your monitor’s pixel layout in your compositor - if so, foot/fcft will use that sub-pixel layout regardless of what FontConfig’s rgba setting is.

> Can I bother you for a quick answer as to what other terminals would use in place of fcft? GTK-based terminals typically use Pango (which uses FontConfig and Harfbuzz, and at least _used_ to use FreeType - they have been moving more logic over to Harfbuzz, but I _think_ FreeType is still used for rasterizing). QT-applications uses QT. Fairly sure they also use FontConfig+FreeType+Harfbuzz. I believe both GTK and QT have ways/settings that overrides some aspects of FontConfig. > so would it be the glyph rasterization that you’re doing in fcft that makes fonts just appear plain better in foot? It’s true that fcft is where the glyphs are rasterized. Foot “only” composites the glyphs (i.e. does alpha blending). But fcft itself doesn’t rasterize the glyphs; that’s FreeType. One can roughly describe the relationship between FontConfig, FreeType, pixman and fcft like this: fcft uses FontConfig to locate _which_ font to load, and which options to apply (should we do antialiasing? Which _kind_ of antialiasing? and lots more). These options need to be converted to FreeType API calls. There’s no automated way to do that, and it’s up to fcft to act as glue between the two. This is one area where things can be different between different font rendering libraries: which FontConfig options do you recognize and how do you translate them to FreeType? FreeType then rasterizes the glyph into a **mask**. For bitmap fonts, this is basically a `0` or a `1` for each pixel, indicating whether that pixel should be opaque or transparent. Grayscale antialiased glyphs are similar, but have 256 alpha levels instead of just two, where 255 is completely opaque and 0 is transparent. pixman is used by fcft as a middle layer between the FreeType rasterized mask and the application (e.g. foot). That is, fcft takes the FreeType mask and simply converts it to a pixman image. You are a bit vague on _how_ fcft/foot renders fonts better than other applications; it could be letter spacing, but I don’t think that’s it. More likely, it is how hinting and antialiasing is applied. That is, how FontConfig options are translated to FreeType. I don’t think fcft doesn’t anything special here. urxvt for example, doesn’t use fontconfig so needs to be configured differently. Or take GNOME, which may override default hinting and antialiasing, resulting in different looking fonts. In my experience, the default FontConfig settings are pretty good. The problems begin when applications have their own settings that override FontConfig. That’s when you need to manually tweak things. In foot it is pretty easy to test different fontconfig settings without changing the system defaults. You can simply append fontconfig options to the fonts in foot, or use the `--font` command line option. For example, to disable antialiasing completely, you can do `foot -f <name>:antialias=false`. Or to explicitly use grayscale antialiasing (assuming antialiasing is enabled): `foot -f <name>:rgba=none`. Or to use RGB sub-pixel antialiasing: `foot -f <name>:rgba=rgb`. These two examples wont work if you have explicitly configured your monitor’s pixel layout in your compositor - if so, foot/fcft will use that sub-pixel layout regardless of what FontConfig’s `rgba` setting is.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.