53 comments

[ 3.5 ms ] story [ 65.4 ms ] thread
Getting fonts to render correctly is a difficult task. Compositing in linear color space is the visually correct way to blend colors. But in practice no platform renders and composites fonts in linear color space, and each has opinionated approaches to how fonts should be rendered. Font designers can design a font with a specific platform in mind, that on another platform looks terrible. And people who spend all day working with a terminal can be very picky about how they want text to look. The latest release of Kitty provides tooling to allow tweaking the compositing settings so that any font in any color, can render as desired on any platform.
This is not technically correct as best as I can ascertain.

When we think about AA, it is a representation of sub pixel occlusion. As such, using uniform tristimulus to sample the “in between” value is incorrect.

There is simply no “correct” approach because there are no known models that properly model visual cognition.

What we can say though, is that the intermediate subpixel should not sample RGB tristimulus, but a loose nonuniform representation that approximates the lower order visual signal representation.

When discarding signal, RGB tristimulus is more “correct”. When interpolating the signal, approximate lightness is more “correct”. Some solid analysis is available here: https://hhoppe.com/filtering.pdf

You don't have to do subpixel AA. It's arguably worse on modern high DPI displays because of the color fringing that wouldn't be present with grayscale AA.
Subpixel AA is always bad - it just might be a necessary but disgusting hack on screens with too low resolution to render fonts comfortably...

Screenshots and screen recordings of subpixel AA content is foo without magic to get clients to disable such rendition during capture...

How about subpixel hinting? A white 1-pixel vertical line has the same amount of fringing whether it's RGB or GBR or BRG.
> Getting fonts to render correctly is a difficult task.

Only if you insist in blurry fonts. Rendering sharp bitmap fonts is trivial. With the microscopic pixels that we have nowadays, bitmap fonts have more sense than ever. Too bad there is not a lot of variety in bitmap fonts of huge pixel size.

I actually find that "with the microscopic pixels we have nowadays", all fonts are fine.

I'm typing this on a 24" 4K screen, using normal fonts and they are very sharp. I do use sub-pixel rendering and don't have any issue even with light text on dark background (Using Linux X11 with fontconfig 2.14.2).

However, the issue is that as soon as you leave high-end laptops, you actually rarely have "microscopic pixels". Most "business" screens are still a blurry mess with 1920x1080 24" panels. 32" 4k panels are serviceable (light text on dark background can get rainbowy), but you better not look at them from too close. 8k panels are still very expensive, at least in Western Europe.

For these screens, I've found that bitmap fonts are the best. They're the only way to have really crisp text, and not some rainbowy-mess. And don't get me started on the fashion trend of skinny light fonts on dark backgrounds.

> However, the issue is that as soon as you leave high-end laptops, you actually rarely have "microscopic pixels".

What? I have had the complete opposite experience. High-end laptops (like, the ones that have multiple GPUs, or portable workstations, or gaming laptops, or etc.) tend to have utterly terrible displays, whereas cheap ultrabooks and chromebooks are the ones that get the 4K treatment. Maybe different allocation of cost?

It's indeed probably a question of definitions. I admit I wasn't thinking about "gaming" laptops nor models with dedicated GPUs, since I don't have a use for those and tend to prefer models without.

I was thinking about macbooks and the likes of Dell XPS and Lenovo X1. I was referring to them as "high-end" since models with 4k screens tend to cost more than your "regular" enterprise-issue laptops, which usually have atrocious screens. The only laptops with HIDPI screens under 2000 € I can think of are the base Mx macbook airs. Since there are many "workable" (from a performance standpoint) models under 2000 € [0], I consider anything above "high end".

I was even eyeing some Dell Latitude and Lenovo P a year or so ago (can't remember the exact model), which I would qualify as "portable workstations", since they had 4 DIMM slots, 3 or 4 NVMe slots and at least one of them actually had some kind of Xeon CPU with ECC RAM. They all had options for a 4K screen. They all cost more than 4000 €. Whereas the laptops we typically get at work (HP Pro and Elite books) top out at FHD, and usually are quite dim and sometimes don't even have 8 bit panels.

---

[0] My current laptop is an EliteBook 845 G8. The laptop itself was around 1500 €, and upgraded to 64 GB of RAM and a Samsung 980 Pro, came in around 1800-1900 €. Aside from the absurdly bad screen, it's a laptop that is powerful enough for my needs.

> nor models with dedicated GPUs

Yeah, those are not high-end laptops; they are premium laptops. Important distinction—premium means price, while high-end means performance.

> The only laptops with HIDPI screens under 2000 € I can think of are the base Mx macbook airs

my own laptop (ROG Zephyrus M15) was around $1300. I regret buying it though, because it sucks terribly, but at least it has a 4K screen.

4K Chromebooks can be had for under $1000 and even as low as $750 in some cases. The ultrabooks (non-ChromeOS) can get even cheaper, but tend to hover around that price range.

We truly live in a golden age of terminal emulators.

I still remember how essentially nothing happened in the terminal world from the late 90s until a few years ago (other than iTerm2 on macOS), and suddenly we have Kitty, Alacritty, Foot, and Wezterm, each developed independently of the others, and each of them better than anything that came before. It's amazing to watch these projects evolve.

Are these better than XTerm wrt latency?

I find XTerm (in Linux) and Terminal.app (in macOS) much snappier.

These measurements seem to agree with my subjective perception: https://danluu.com/term-latency

Those measurements are several years old and thus say essentially nothing about the current generation of these terminals, which are all under very active development.

XTerm is X11 only. Considering that Wayland is much more lightweight than X11, it's hard to imagine XTerm beating e.g. Foot, which is purpose-built for modern Wayland desktops, with almost no abstraction in between.

Not to mention that these terminals have much better overall engineering than XTerm, whose README famously states "This is undoubtedly the most ugly program in the distribution." That line alone is enough for me to avoid XTerm like the plague.

> Considering that Wayland is much more lightweight than X11

That's irrelevant. More relevant is that Wayland is adamant about presenting "perfect frames" (ie no frame tearing), which requires a sync/checkpoint for everything that's displaying, which inherently puts a lower bound on latency that non-sync-respecting X11 isn't subject to.

What's more relevant is that Wayland is adamant on ensuring that scanout is an option as often as possible, making it extremely efficient and fast to put stuff on screen.

Also, every pixel has a "checkpoint" sampled at the display refresh rate. With tearing, the checkpoint of a pixel differs from its neighbors, with each subsequent pixel (leading to rolling shutter artifacts), whereas without, all pixels show the same sample.

At the cost of glitches, tearing and higher render load let's you put slightly newer data in the bottom third or quarter of your screen.

Not really something to write home about, especially considering that X11-users commonly run external compositors exactly to get that tear-free behavior.

Why no love for Zutty (https://tomscii.sig7.se/zutty)? It's far more feature-complete than Kitty or Alacritty, without sacrificing much in way of performance or latency.
These terminals still speak an archaic and anachronistic protocol, fragmentation in the supported feature set puts IE6 and Opera Mobile to shame, and TUI applications that run in terminal emulators feel completely out of place in a modern (modern = I'd say past 20, maybe 30 years) desktop environment.

I can open vim, irssi, moc, htop, nethack, or a dozen other TUI apps, and every one of them has different key bindings, different color scheme (sometimes assuming/hardcoding white text on dark background, sometimes vice versa), different paradigm for supporting multiple buffers, different way to configure it, different way to exit - but each window still has the same icon in the task bar. KDE did this better in 1996. Mac did this better in 1984.

Even if I stick 100% to using CLI (stdio) programs, the facilities have barely improved at all since the time job control was introduced - there's a lot of potential to actually innovate here, but that would probably require breaking out of the separate terminal+shell paradigm. There were more radical attempts, but AFAICT the bleeding edge of innovation in mainstream emulators is iTerm displaying the process tree in a popup.

It's the most rich ecosystem of lowest common denominator software in existence. We have sRGB correct linear gamma blending, but Emacs in terminal still loads the wrong dark/light theme - unless you cobble together a hundred lines of custom elisp glue. I don't even understand why we need gamma blending, nobody can implement an actual production-quality graphics editor in a terminal (unless you want to double down on sixels...).

If tmux control mode was ever implemented for kitty I'd use it, but Goyal hates multiplexers so he refuses to do it.

Luckily it looks like wezterm will have support eventually.

> Goyal hates multiplexers so he refuses to do it.

So very on brand for him.

Why people keep investing themselves into Goyal's one-man-fiefdom projects is a mystery to me. I haven't used kitty, but I absolutely loathe Calibre more than any other software I use. The man couldn't design a user interface to save his life, common functions nearly everyone wants are time-consuming to set up, and the fact that calibre-web is better in every possible way speaks volumes. It took me years to realize that calibre-web had nothing to do with him, otherwise I would have switched much sooner.

I don't get this open reluctance of people that contribute a lot of time and work towards open source. Sounds a lot like entitlement to me.

I don't know anything about the drama you mention. I just know kitty is a fine terminal emulator I use all the time (also with tmux/byobu) and I am thankful the author created it. Calibre I also use from time to time and it works for my purpose. I am happy it exists and I can just shovel my ebooks onto my kindle.

It sounds like you used Calibre for years but still complain about it even though it's free..

Usually I agree but the maintainer of kitty is bonkers rude. There have been several issues concerning privacy and security regarding kitty. The responses of the maintainer regarding these very valid concerns made me switch to wezterm/sakura/foot in an instant.

He also accepts lots of PRs from contributers. Once you do this, it is no longer your project only.

An example PR (there are a few others equally concerning): https://github.com/kovidgoyal/kitty/pull/3544

I see. I read the PR you linked and have to partially agree. Yes the maintainer's reaction was rude and seemed much like an overreaction. However the original comment could also be seen as offensive and lecturing.

I don't want to defend phone-home mechanisms because I am personally not a fan but an update check really is different from surveillance. I in general agree with the comment that the feature should be opt-in but the argument was not presented in a good way.

Yes, you are right. I am also highly opinionated, when it comes to opt-out phone home functionality in terminal software. Just wanted to point out where some of the drama comes from and also make aware of possible consequences. I could imagine people are not opening security PRs or issues because of the maintainers attitude.
Does calibre-web support syncing collections from PC to Kobo ?
> The kobo sync with calibre-web is only for books. You can choose to sync your entire library or just a specific shelf. You add books to that shelf and sync, it will make sure the books on that shelf are on your kobo.

>For syncing reading progress across devices KOReader is apparently the way to go. You can setup syncing on there and any device that has KOReader installed will have the same reading position.

From google.

+ OPDS support regardless of device

Thanks, I haven't yet switched to koreader so I'll stick with calibre (and its horrible UI, I agree) for a while.
I'm using calibre-web + Boox Darwin. Maybe not as functional as some other solutions, but you get a great personal library and books sync over opds. (Not progress sync, but I don't really need it)
I use Calibre as an epub reader. Does anyone know of good alternatives on Linux? I’ll look into calibre-web of course.
Mupdf with plugins for lightweight fetishists? Foliate for lazies like me. Okular if your running KDE/Plasma already?
calibre-web is not a replacement for calibre. The real hard part is all the ebook conversion stuff, which calibre-web can do by... calling calibre binaries. So saying "it has nothing to do with him" is quite the statement.

Calibre has saved my bacon countless of times. It's absolutely crazy how many crappily formatted epubs are out there (not pirated ones, mind you, but bought from stores). Without Calibre to clean these up, my reading experience would have been so much worse.

I'm very curious what kinds of fixes you're talking about. Would you mind expanding a bit on what's broken and how you fixed things?
> Why people keep investing themselves into Goyal's one-man-fiefdom projects is a mystery to me.

You gain some, you lose some. Kitty is really low-latency and renders most Unicode shenanigans correctly (the main exception being RTL text). I can live with the fact that I don't get a normal menu bar on Wayland then :-)

Kitty does everything I want out of a terminal multiplexer out of the box already. Sure, there are other features that might be gained by using tmux inside a terminal that has extra support for it, but as a maintainer he makes the call if it's worth the complexity to add features he doesn't use and disagrees on whether it's a good fit for his app.

Even if you open a pull request for this, that is asking the maintainer their many many hours of future maintenance and support they have to do to keep this feature alive and improved, all for free.

I unfortunately have to use Calibre to convert Kindle Ebooks into a sensible format. One needs to fight Calibre so it doesn't destroy any images in the conversion process.
I can second Wezterm. I've used a lot of emulators and Wezterm is far and away the best one. My daily driver across all platforms and has never failed me.
wezterm on arch is 113mb chungus compared to alacritty at just 6mb, but i guess people like me would be happier with foot maybe.
Yes and alacritty has a ton of issues with rendering and performance.
(comment deleted)
I don't get the negativity...I use Kitty and I think its great, and I stopped using tmux most of the time

Goyal is opinionated but so what? you are free to not use his free software...or you could fork it

I actually find his sass amusing...

> you are free to not use his free software

That's exactly what they're doing, what are you talking about?

That this comment thread seems focused on taking him down personally
It just says he hates multiplexers. Presumably a statement of fact and not an attack.
> I use Kitty and I think its great, and I stopped using tmux most of the time

I want to go 100% kitty (both locally and via SSH), but I don't know whether it can persist sessions. With tmux I can kill the Kitty app, and when I reopen it, all tabs are there, and any running processes keep running in the background (especially important for SSH).

Is kitty able to do something like that?

I don't know anything about Goyal except that his name is Goyal, he maintains Kitty and he thinks muliplexers are stupid.

That's something I learned digging through kitty's github issues when doing a deep dive looking for a term that runs on Linux and supports tmux control mode.

This turned me off from using it as someone who needs tmux daily and I wanted to share that information so that others like me might save some time investigating.

I've stared at the comparison image between MacOS and Kitty and the only thing I can tell is that Kitty is displaying the colored text in a very different way - frankly, one that is harder to read on account of being lower contrast.

In plain English, can someone explain what's going on, and why anyone should care?

they've gotten font rendering to be similar to macOS, so the fact that you can't really tell a difference is the point. scroll down for more screen shots that show the improvement
Which comparison image are you looking at? The images on the linked gh pr show only b&w text?
When trying to blend two different colors, for instance when you have antialiased white text on black background (or for that matter, fuchsia text on an image), there's a question on how you do the blending mathematically. The “obvious” way of doing a*alpha + b*(1-alpha) for the pixel values is wrong, since the pixel values don't correspond directly to the number of photons (they are compressed using a non-linear curve, because that allows us to use 8-bit displays instead of, say, 16-bit). In particular, this means that white-on-black and black-on-white don't actually render visually the same.

This patch corrects that, and adds some contrast controls since few people would prefer the 100% physically correct blending (I'd assume fonts are not designed for that in the first place, so the alpha value coming out of the subpixel calculation isn't really optimal). This brings it closer to macOS' Terminal.app.