alacritty: [Mac Big Sur] 'use_thin_strokes: true' appears to no longer work

For anyone following this issue, you can get thin strokes on latest Alacritty and macOS now, you just need to use:

$ defaults write -g AppleFontSmoothing -int 0

The use_thin_strokes config field has been removed as discussed above.

If you still want smoothing (read: slightly bolder fonts) for the rest of the system, but not in Alacritty, you can do org.alacritty instead of -g in the above command. Personally I think it’s much nicer on everything and would suggest people give it a try if they haven’t before. (It requires a restart to take effect for the whole system, but Alacritty just needs to be relaunched for it to take effect, as it reads the default when loading fonts.)

The patches earlier in the thread are no longer necessary.

I have managed to get it to work, thank you @puremourning & @dangh! I cloned @puremourning’s repo’s and added .cargo/config.toml as per his instructions, excellent work on his behalf!

git clone https://github.com/puremourning/alacritty.git
git clone https://github.com/puremourning/winit.git
git clone https://github.com/puremourning/crossfont.git
mkdir ./alacritty/.cargo && touch config.toml
echo 'paths = [ "../crossfont", "../winit" ]' >> ./alacritty/.cargo/config.toml

Now the “use_thin_strokes” option in alacritty.yml actually renders the font thinner! A note: To see changes in the “use_thin_strokes” option Alacritty has to be quit and restarted.

For anyone interested, you can also find a pre-built version for Intel Macs on my github.

On the left you can see the official build and on the right a build with @puremouring’s tweaks applied:

For anyone who is hitting this and (like me) prefers the way iTerm renders this you can get the fonts to render “thin” and look good on retina displays with this change in the crossfont repo:

ben@BeniMac2020 crossfont % git diff
diff --git a/src/darwin/mod.rs b/src/darwin/mod.rs
index aded7a7..9a0f84f 100644
--- a/src/darwin/mod.rs
+++ b/src/darwin/mod.rs
@@ -445,10 +445,13 @@ impl Font {
 
         if use_thin_strokes {
             cg_context.set_font_smoothing_style(16);
+            cg_context.set_allows_font_smoothing(false);
+            cg_context.set_should_smooth_fonts(false);
+        } else {
+            cg_context.set_allows_font_smoothing(true);
+            cg_context.set_should_smooth_fonts(true);
         }
 
-        cg_context.set_allows_font_smoothing(true);
-        cg_context.set_should_smooth_fonts(true);
         cg_context.set_allows_font_subpixel_quantization(true);
         cg_context.set_should_subpixel_quantize_fonts(true);
         cg_context.set_allows_font_subpixel_positioning(true);

Not exactly an official API. The iTerm2 author stumbled on something, tried it and liked the look (which is fine). But it is not how Apple wants folks to do things (me thinks).

This is something not uncommon to iTerm. Which is why I’d like to point out that this is not something Alacritty will get into. iTerm is a macOS terminal emulator, which is why it is fine to invest significant amounts of time tweaking it specifically for macOS, but Alacritty is not. Should there be a relatively standard process to make this work, then that’s perfectly fine.

After battling this issue for two weeks, which involved me going bonkers thinking something was working when it actually wasn’t, I firmly believe the best solution is to use a thinner font.

If your goal is just to adjust the font weight, then any of this configuration is completely misguided really. This option is for subjectively improved text rendering on lower DPI displays, thinner fonts are just a side effect.

use_thin_fonts seems to be a headache, firstly it is macOS only so probably should be named mac_use_thin_fonts, but it only works for High Sierra, Mojave and Catalina (nothing prior and currently nothing latter). Seems a platform specific burden.

I know some folks will want this, but I feel like we are battling against Apple itself.

These are pretty much my thoughts on the matter too. I think eventually we’ll probably just end up going the way of removing this option, since there’s little benefit and macOS doesn’t seem like they are particularly interested in providing this feature. With high DPI monitors, as provided by many macOS systems, it should only become less and less relevant over time. For people that did not understand the purpose of this option and used it solely to change the font’s thickness, there should be plenty of other fonts out there to choose from (or they can modify the font itself).

I also tried to adjust the font weight by following all suggestions above (I am using Menlo Regular, size 13), but I was unable to get a thinner stroke. I am running macOS Big Sur 11.2.3 and alacritty 0.7.2 (5ac8060).

Because the rest of the terminals don’t exhibit this rendering behavior, I wonder what might be the actual cause of this 🤔

Apple keeps changing it’s font subsystem from release to release, that much is obvious.

The iTerm2 solution contains this comment:

// This seems to be available at least on 10.8 and later. The only reference to it is in
// WebKit. This causes text to render just a little lighter, which looks nicer.

Not exactly an official API. The iTerm2 author stumbled on something, tried it and liked the look (which is fine). But it is not how Apple wants folks to do things (me thinks).

After battling this issue for two weeks, which involved me going bonkers thinking something was working when it actually wasn’t, I firmly believe the best solution is to use a thinner font. Fonts like Iosevka provide build script, hence font weight is adjustable for this particular font. So I built myself a thinner font which totally solved this issue.

Alacritty does not provide box drawing because simplicity and maintainability are desired goals.

use_thin_fonts seems to be a headache, firstly it is macOS only so probably should be named mac_use_thin_fonts, but it only works for High Sierra, Mojave and Catalina (nothing prior and currently nothing latter). Seems a platform specific burden.

I know some folks will want this, but I feel like we are battling against Apple itself.

My 2 cents.

Could you see if #1635 (comment) works for you?

No unfortunately.

They’ve probably changed their APIs again. There has been some effort from Apple to remove this setting, it might just be gone now.

iTerm2 thin-strokes still works on Big Sur if that is a useful data point.

I would be interested if other Big Sur users encounter this issue. It would be nice to know if this is a Big Sur issue, or an issue just for me. At the moment I suspect all Big Sur users will encounter this.

Note, Apple absolutely nags you to upgrade, so it proves hard to resist. I now wish I hadn’t.

I put this in .cargo/config.toml under alacritty:

paths = [ "../crossfont", "../winit" ]

in ../winit I have this commit:

commit 43580969341fce3be1cc76ab3593f544cf370b8c (HEAD -> master, pm/master)
Author: Ben Jackson <puremourning@gmail.com>
Date:   Fri Jun 18 16:13:39 2021 +0100

    Autohide dock and menu bar, rather than make it impossible to exit fullscreen

diff --git a/src/platform_impl/macos/window_delegate.rs b/src/platform_impl/macos/window_delegate.rs
index d77c8957..f657363c 100644
--- a/src/platform_impl/macos/window_delegate.rs
+++ b/src/platform_impl/macos/window_delegate.rs
@@ -496,8 +496,8 @@ extern "C" fn window_will_use_fullscreen_presentation_options(
     // we don't, for consistency. If we do, it should be documented that the
     // user-provided options are ignored in exclusive fullscreen.
     (NSApplicationPresentationOptions::NSApplicationPresentationFullScreen
-        | NSApplicationPresentationOptions::NSApplicationPresentationHideDock
-        | NSApplicationPresentationOptions::NSApplicationPresentationHideMenuBar)
+        | NSApplicationPresentationOptions::NSApplicationPresentationAutoHideDock
+        | NSApplicationPresentationOptions::NSApplicationPresentationAutoHideMenuBar)
         .bits()
 }

In ../crossfont I have this commit:

commit 3d0d7385d07277aa8c4b156555280523e90cba09 (HEAD -> master, pm/master)
Author: Ben Jackson <puremourning@gmail.com>
Date:   Mon Jun 14 17:21:59 2021 +0100

    Actually disable font smoothing when thin_strokes is enabled

    MacOS Big Sur changed font smoothing in some strage way, apparently
    disabling it at the OS level. Or something. It's hard to get clear
    information on this, but by _enabling_ font smoothing we end up with fat
    over-bright/high contract characters on MacOS.

    So to actually get thin fonts, enable anti-aliasing but disable font
    smoothing. This works for me(TM), and makes alacritty look like iTerm
    and Terminal.app.

diff --git a/src/darwin/mod.rs b/src/darwin/mod.rs
index aded7a7..9a0f84f 100644
--- a/src/darwin/mod.rs
+++ b/src/darwin/mod.rs
@@ -445,10 +445,13 @@ impl Font {

         if use_thin_strokes {
             cg_context.set_font_smoothing_style(16);
+            cg_context.set_allows_font_smoothing(false);
+            cg_context.set_should_smooth_fonts(false);
+        } else {
+            cg_context.set_allows_font_smoothing(true);
+            cg_context.set_should_smooth_fonts(true);
         }

-        cg_context.set_allows_font_smoothing(true);
-        cg_context.set_should_smooth_fonts(true);
         cg_context.set_allows_font_subpixel_quantization(true);
         cg_context.set_should_subpixel_quantize_fonts(true);
         cg_context.set_allows_font_subpixel_positioning(true);

I then just build Alacritty (I think).

Thin fonts rendering, generally, is more useful for low DPI screens than high.

A couple points:

• 1. Use of a thinner font totally solves this issue. That has been and will remain the best solution.
• 1. Apple does not provide a stable API to achieve the thin fonts look. The iTerm2 implementation uses a buried-treasure discovery that Apple seems want to change from certain OS release to the next.
• 1. This is a Mac only feature that goes somewhat against the cross platform nature of Alacritty. At this point, a year after I created this request, I am of the belief that Alacritty should just remove use_thin_strokes completely since it doesn’t work for Mac OS releases prior to High Sierra (2017) and releases later than Catalina (10.15 / 2019).

My 2cents.

@philip1987 patching non root package will not working.

$ cargo test --release
warning: patch for the non root package will be ignored, specify patch at the workspace root:
package:   /Users/dang/Desktop/src/alacritty/alacritty/Cargo.toml
workspace: /Users/dang/Desktop/src/alacritty/Cargo.toml
    Finished release [optimized + debuginfo] target(s) in 0.08s
     Running unittests (target/release/deps/alacritty-abf26233c9be56a7)

You may want to set the path in the dependencies section instead:

--- a/alacritty/Cargo.toml
+++ b/alacritty/Cargo.toml
@@ -28,7 +28,7 @@ serde_json = "1"
 glutin = { version = "0.27.0", default-features = false, features = ["serde"] }
 notify = "4"
 parking_lot = "0.11.0"
-crossfont = { version = "0.3.0", features = ["force_system_fontconfig"] }
+crossfont = { path = "../../crossfont", features = ["force_system_fontconfig"] }
 copypasta = { version = "0.7.0", default-features = false }
 libc = "0.2"
 unicode-width = "0.1"

Nothing will get me to change from Iosevka. I just simply hacked the private-build-plans.toml build script and added a thin variant as such:

    [buildPlans.iosevka-custom.weights.light]
    shape = 350
    menu  = 300
    css   = 300

Then it is just a matter of building the font.

And in my alacritty.yml I have these font settings:

font:
  normal:
    family: Iosevka Custom
    style: Light

  bold:
    family: Iosevka Custom
    style: Light

  italic:
    family: Iosevka Custom
    style: Light Italic

That gets me the exact thin strokes style I like on Mac.

It changes the global setting, that’s why you need to restart it to make it work.

Quite likely, I think I created this request just after upgrading, probably no reboots or log outs involved.

That’s why I’m not particularly concerned right now.

Yes, closing this is correct. Also this back and forth has likely provided some knowledge if other users hit the issue.

Best regards and many thanks.