Show bold text in bright colours #199

Closed
opened 12 months ago by Minoru · 7 comments
Minoru commented 12 months ago

XFCE4 Terminal has a handy setting under Colours → Palette: "Show bold text in bright colours". It does what it says on the tin. For me, this significantly enhances the contrast in applications like Mutt, Irssi, Mcabber, and Newsboat.

Would it be possible to have the same for foot?

XFCE4 Terminal has a handy setting under *Colours → Palette*: "Show bold text in bright colours". It does what it says on the tin. For me, this significantly enhances the contrast in applications like Mutt, Irssi, Mcabber, and Newsboat. Would it be possible to have the same for foot?
Owner

I believe most terminals have that option.

The reason I haven't (yet) added it to foot is that the general trend in the terminal ecosystem is to move away from drawing bold text in bright colors. What used to be the default is no longer that. The idea is to separate the two (bold and bright) to give applications a more fine grained control over its looks.

However, that doesn't take into account all the users that have become accustomed to this. Which is why all(?) terminals still have the option - they just flipped the default from enabled to disabled.

In that light, I think it makes perfect sense to add the option to foot as well.

I believe most terminals have that option. The reason I haven't (yet) added it to foot is that the general trend in the terminal ecosystem is to move away from drawing bold text in bright colors. What used to be the default is no longer that. The idea is to separate the two (bold and bright) to give applications a more fine grained control over its looks. However, that doesn't take into account all the users that have become accustomed to this. Which is why all(?) terminals still have the option - they just flipped the default from enabled to disabled. In that light, I think it makes perfect sense to add the option to foot as well.
dnkl added the
enhancement
label 12 months ago
dnkl closed this issue 12 months ago

Hi @dnkl,

I was wondering if this option could make use of the defined bright colors in foot.ini (given that they exist) instead of multiplying the color's luminance by 1.3 (in color_brighten function).

As otherwise the bold-text-in-bright option doesn't make use of the defined colors, which is a bit confusing (and there is no control on that 1.3 value).

Or maybe is it because there is more than the 8 colors to brighten 🤔 ?

Keep up the great work! 👍

Hi @dnkl, I was wondering if this option could make use of the defined bright colors in `foot.ini` (given that they exist) instead of multiplying the color's luminance by 1.3 (in [`color_brighten`](https://codeberg.org/dnkl/foot/src/branch/master/render.c#L255) function). As otherwise the `bold-text-in-bright` option doesn't make use of the defined colors, which is a bit confusing (and there is no control on that 1.3 value). Or maybe is it because there is more than the 8 colors to brighten 🤔 ? Keep up the great work! 👍
Owner

Or maybe is it because there is more than the 8 colors to brighten 🤔 ?

Correct, that's the main reason. Foot needs to be able to dim, and brighten, all possible 24-bit colors.

While it would be possible, technically, to make color_brigten() pattern match the color value against the 8 base colors, and apply the corresponding bright color if there's a match, I'm not so sure that's a good idea.

One example: an application uses a 24-bit color scheme, not related to your base-16 scheme. It unknowingly emits a color that happens to match one of your base-8 colors. That particular color will now be brightened differently from all other colors used by the application.

and there is no control on that 1.3 value

it wouldn't be completely unreasonable to make it configurable.

Keep up the great work! 👍

Thanks, I appreciate it!

> Or maybe is it because there is more than the 8 colors to brighten 🤔 ? Correct, that's the main reason. Foot needs to be able to dim, and brighten, **all** possible 24-bit colors. While it would be possible, technically, to make `color_brigten()` pattern match the color value against the 8 base colors, and apply the corresponding bright color if there's a match, I'm not so sure that's a good idea. One example: an application uses a 24-bit color scheme, not related to your base-16 scheme. It unknowingly emits a color that happens to match one of your base-8 colors. That particular color will now be brightened differently from all other colors used by the application. > and there is no control on that 1.3 value it wouldn't be completely unreasonable to make it configurable. > Keep up the great work! 👍 Thanks, I appreciate it!

Or maybe is it because there is more than the 8 colors to brighten 🤔 ?

Correct, that's the main reason. Foot needs to be able to dim, and brighten, all possible 24-bit colors.

While it would be possible, technically, to make color_brigten() pattern match the color value against the 8 base colors, and apply the corresponding bright color if there's a match, I'm not so sure that's a good idea.

One example: an application uses a 24-bit color scheme, not related to your base-16 scheme. It unknowingly emits a color that happens to match one of your base-8 colors. That particular color will now be brightened differently from all other colors used by the application.

Definitely not a good idea indeed. But we can ask ourself the corollary then, what are the colours defined in the config file used for, then? 🙃

and there is no control on that 1.3 value

it wouldn't be completely unreasonable to make it configurable.

Actually I don't know if that specific value is needed or not. What I would like to achieve is getting colors with more contrast when using bold-text-in-bright, not less. Otherwise colors appear with very low contrast, making it hard to read.

Users opinions may (will?) diverge here so a (combination of) parameter(s) would definitely be nice to have!

Keep up the great work! 👍

Thanks, I appreciate it!

I've discovered foot very recently via Debian (testing) package repositories I and truly love it! It's Alacritty without being opinionated 🙊🚀!

> > Or maybe is it because there is more than the 8 colors to brighten 🤔 ? > > Correct, that's the main reason. Foot needs to be able to dim, and brighten, **all** possible 24-bit colors. > > While it would be possible, technically, to make `color_brigten()` pattern match the color value against the 8 base colors, and apply the corresponding bright color if there's a match, I'm not so sure that's a good idea. > > One example: an application uses a 24-bit color scheme, not related to your base-16 scheme. It unknowingly emits a color that happens to match one of your base-8 colors. That particular color will now be brightened differently from all other colors used by the application. Definitely not a good idea indeed. But we can ask ourself the corollary then, what are the colours defined in the config file used for, then? 🙃 > > > and there is no control on that 1.3 value > > it wouldn't be completely unreasonable to make it configurable. Actually I don't know if *that* specific value is needed or not. What I would like to achieve is getting colors with **more** contrast when using `bold-text-in-bright`, not less. Otherwise colors appear with very low contrast, making it hard to read. Users opinions may (will?) diverge here so a (combination of) parameter(s) would definitely be nice to have! > > > Keep up the great work! 👍 > > Thanks, I appreciate it! I've discovered `foot` very recently via Debian (testing) package repositories I and truly love it! It's Alacritty without being opinionated 🙊🚀!

I played a bit with color_brighten and got close to the result I was looking for.

My personal taste: return hsl_to_rgb(hue, min(100, sat * 1.5), min(100, lum * 0.8));.

A way to fine tune these values via config would be very convenient 👌.

I played a bit with `color_brighten` and got close to the result I was looking for. My personal taste: `return hsl_to_rgb(hue, min(100, sat * 1.5), min(100, lum * 0.8));`. A way to fine tune these values via config would be very convenient 👌.
Owner

Definitely not a good idea indeed. But we can ask ourself the corollary then, what are the colours defined in the config file used for, then? 🙃

Legacy legacy legacy. Many programs use 24-bit color schemes without bothering with the 16 base colors (or rather, can be set up to do that). But there are also many programs that only supports the 16 base colors.

The key difference is that a 24-bit application needs to define the exact colors it uses, while one that uses the 16 base colors just need to decide whether to use "red" or "green" - it doesn't care, and doesn't know, what "red" or "green" actually looks like.

I personally think using the 16 base colors is more appriate in many cases, as it allows me define a uniform color scheme in a single place. But the downside is of course that we're limited to only 16 colors. Well, technically only 8, with 8 brighter shades (but don't tell solarized that).

Users opinions may (will?) diverge here so a (combination of) parameter(s) would definitely be nice to have!

I don't use bold-text-in-bright myself, meaning all I can do is say what's possible and what's not. I also prefer not adding configuration options unless necessary (haven't been very successful with that though). Why don't you open a new issue for this, and we'll see if others chime in? And, mapping colors to the base-8 table and using the corresponding bright color isn't mutually exclusive to making the parameters used in color_brighten() configurable. I.e. might be a good idea to include that in the new issue as well.

What I would like to achieve is getting colors with more contrast when using bold-text-in-bright, not less

Honestly, what I think would be best for everyone, is if applications stopped assuming bold means bright, and instead gave users more fine grained control over font attributes.

> Definitely not a good idea indeed. But we can ask ourself the corollary then, what are the colours defined in the config file used for, then? 🙃 Legacy legacy legacy. Many programs use 24-bit color schemes without bothering with the 16 base colors (or rather, _can_ be set up to do that). But there are also many programs that only supports the 16 base colors. The key difference is that a 24-bit application needs to define the _exact_ colors it uses, while one that uses the 16 base colors just need to decide whether to use "red" or "green" - it doesn't care, and doesn't _know_, what "red" or "green" actually looks like. I personally think using the 16 base colors is more appriate in many cases, as it allows me define a uniform color scheme in a single place. But the downside is of course that we're limited to only 16 colors. Well, technically only 8, with 8 brighter shades (but don't tell solarized that). > Users opinions may (will?) diverge here so a (combination of) parameter(s) would definitely be nice to have! I don't use `bold-text-in-bright` myself, meaning all I can do is say what's possible and what's not. I also prefer not adding configuration options unless necessary (haven't been very successful with that though). Why don't you open a new issue for this, and we'll see if others chime in? And, mapping colors to the base-8 table and using the corresponding bright color isn't mutually exclusive to making the parameters used in `color_brighten()` configurable. I.e. might be a good idea to include that in the new issue as well. > What I would like to achieve is getting colors with more contrast when using bold-text-in-bright, not less Honestly, what I think would be best for everyone, is if applications stopped assuming bold means bright, and instead gave users more fine grained control over font attributes.

Why don't you open a new issue for this, and we'll see if others chime in?

Done, see #360 🙂

>Why don't you open a new issue for this, and we'll see if others chime in? Done, see #360 🙂
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.