Few more additional ones, more about editing than just rendering:
The style change mid ligature has a related problem. While it might be reasonable not to support style change in the middle of ligature, you still want to select individual letters within ligatures like "ff", "ffi" and "fl". The problem just like with color change is that neither the text shaper nor program rendering text knows where each individual letter within ligature glyph is positioned. Font simply lacks this information.
From what I have seen most programs which support it use similar approximation as what Firefox uses for coloring - split the ligature into equal parts. Works good enough for something like "fi", "fl" not so much for some of ligatures within programming fonts that combine >= into ≥.
There are even worse edge cases in scripts for other languages. There are ligatures which look roughly like the 2 characters which formed it side by side but in reverse order. There are also some ligatures in CJK fonts which combine 4 characters in a square.
Backspace erases characters at finer granularity than it's possible to select them.
With regards to LTR/RTL selection weirdness I recently discovered that some editors display small flag on the cursor displaying current position direction when it's in mixed direction text.
The ligatures part of this article gets me every time I re-read it. I think reading this article may have been the first time I realized that even large, well-funded projects are still done by people who are just regular humans, and sometimes settle for something that's good enough.
I've tried to ask this before in various contexts and I've never been able to find an answer but maybe commenters on a post like this would know.
I like the way that the CJK fonts render without anti-aliasing on windows. I want to know why and how to cause windows to render a non-cjk font of my choosing in this aliased style. I am not opposed to hex-editing or otherwise modifying the font if that's necessary. I've never been able to find information bout the mechanism or how it's triggered.
Hmm I use Firefox and the rendering I see in Firefox looks nothing like the render the author gets in Firefox; in fact the text rendering I get looks very similar to the "Chrome" rendering. Obviously this must depend on the libraries linked during the build process.
Depending on your OS Firefox will select from multiple rendering backends based on your GPU, driver etc.
On Windows it may or may not be using DirectWrite for text rasterization as a general thing, and in some cases text might be rasterized using a different fallback path if DirectWrite can't handle the font, I think.
IIRC this was/is true for Chrome as well, where in some cases it software rasterizes text using Skia instead of calling through to the OS's font implementation.
> Don’t ask about the code which line-breaks partial ligatures though.
Wondered about this. All the circular dependencies sound like you could feasibly get some style/layout combinations that lead to self-contradictory situations.
E.g. consider a ligature that's wider than the characters' individual glyphs. If the ligature is at the end of the box, it could trigger a line break. But that line break would also break up the ligature and cause the characters to be rendered as individual glyphs, reducing their width - which would undo the line break. But without the line break, the ligature would reconnect, increase the width and restore the line break, etc etc...
How did they get the exact effect to show what they want in the text here instead of say, me seeing the exact same visuals for each browser as I am reading it from a single browser?
The real takeaway from the article is that you can rathole forever on ill-defined problems. Decide upfront whether you care about actual humans and their usecases or hypothetical humans and their hypothetical usecases.
Or even, which subset of humans' uses cases you wish to concern yourself with as you can't always please everyone or tackle everyone's problems. If one only cared about a single language everything becomes much easier.
Few more additional ones, more about editing than just rendering:
The style change mid ligature has a related problem. While it might be reasonable not to support style change in the middle of ligature, you still want to select individual letters within ligatures like "ff", "ffi" and "fl". The problem just like with color change is that neither the text shaper nor program rendering text knows where each individual letter within ligature glyph is positioned. Font simply lacks this information.
From what I have seen most programs which support it use similar approximation as what Firefox uses for coloring - split the ligature into equal parts. Works good enough for something like "fi", "fl" not so much for some of ligatures within programming fonts that combine >= into ≥.
There are even worse edge cases in scripts for other languages. There are ligatures which look roughly like the 2 characters which formed it side by side but in reverse order. There are also some ligatures in CJK fonts which combine 4 characters in a square.
Backspace erases characters at finer granularity than it's possible to select them.
With regards to LTR/RTL selection weirdness I recently discovered that some editors display small flag on the cursor displaying current position direction when it's in mixed direction text.
>But if the transform is an animation this will actually look even worse
I wish they provided an example video of this since I can't visualize it. My natural thinking is subpixel antialiasing should look fine.
>the characters will jiggle as each glyph bounces around between different subpixel snappings and hints on each frame.
This shouldn't be a big issue unless your animation is slow and your subpixels are big.
(2019) Popular in:
2023 (290 points, 119 comments) https://news.ycombinator.com/item?id=36478892
2022 (399 points, 154 comments) https://news.ycombinator.com/item?id=30330144
2019 (542 points, 170 comments) https://news.ycombinator.com/item?id=21105625
The ligatures part of this article gets me every time I re-read it. I think reading this article may have been the first time I realized that even large, well-funded projects are still done by people who are just regular humans, and sometimes settle for something that's good enough.
I've tried to ask this before in various contexts and I've never been able to find an answer but maybe commenters on a post like this would know.
I like the way that the CJK fonts render without anti-aliasing on windows. I want to know why and how to cause windows to render a non-cjk font of my choosing in this aliased style. I am not opposed to hex-editing or otherwise modifying the font if that's necessary. I've never been able to find information bout the mechanism or how it's triggered.
Just disable ClearType and all your text will be uniform :)
Well that's not what I want, I want to specifically prevent some passages in text from being rendered as anti-aliased for art reasons.
Hmm I use Firefox and the rendering I see in Firefox looks nothing like the render the author gets in Firefox; in fact the text rendering I get looks very similar to the "Chrome" rendering. Obviously this must depend on the libraries linked during the build process.
The article is from 2019, things might also simply have changed since then.
Depending on your OS Firefox will select from multiple rendering backends based on your GPU, driver etc.
On Windows it may or may not be using DirectWrite for text rasterization as a general thing, and in some cases text might be rasterized using a different fallback path if DirectWrite can't handle the font, I think.
IIRC this was/is true for Chrome as well, where in some cases it software rasterizes text using Skia instead of calling through to the OS's font implementation.
> Don’t ask about the code which line-breaks partial ligatures though.
Wondered about this. All the circular dependencies sound like you could feasibly get some style/layout combinations that lead to self-contradictory situations.
E.g. consider a ligature that's wider than the characters' individual glyphs. If the ligature is at the end of the box, it could trigger a line break. But that line break would also break up the ligature and cause the characters to be rendered as individual glyphs, reducing their width - which would undo the line break. But without the line break, the ligature would reconnect, increase the width and restore the line break, etc etc...
Good. I hated it first!
And the companion article: https://lord.io/text-editing-hates-you-too/
(posted in other other threads too)
How did they get the exact effect to show what they want in the text here instead of say, me seeing the exact same visuals for each browser as I am reading it from a single browser?
You mean in the parts that say "Here's what they look like in Safari" and so on? Those are just .pngs.
The real takeaway from the article is that you can rathole forever on ill-defined problems. Decide upfront whether you care about actual humans and their usecases or hypothetical humans and their hypothetical usecases.
Or even, which subset of humans' uses cases you wish to concern yourself with as you can't always please everyone or tackle everyone's problems. If one only cared about a single language everything becomes much easier.