The "Texture Healing" feature is a really smart use of OpenType features to make problematic monospace combinations look much better without breaking the grid at all.
One naive way to do this would be to create ligature pairs for difficult pairs (mi, lm, etc). But instead, they seem to be selecting character alternates that fill the fixed width differently based on their surroundings.
Commit Mono font does something similar and calls it “Smart kerning”. Visit https://commitmono.com/ and click on the “04 Intelligent” tab for details.
In practice this is unusable. Because the width of the letters now depends on the succeeding character, the text jumps as you write it. Super annoying.
It doesn't in this font? Possibly because of what they talk about where it optimistically gives as much space as possible to succeeding glyphs. You can try it on the page; the code sample boxes are editable. I see no jumping when I type "calming", their example word.
[append] Oh, I do see some jumping when I type "optimized". Honestly, it doesn't seem very jarring to me; the jumping is always right where the edit point is so the added or removed letter causes a much bigger jump.
Unrelated, but why is it that Font marketing pages specifically always have such cool-looking demoes? I love the navigation on that site, I might steal that for my own site
If this gets popular, I could see a text editor that lets you use a non-healing version of the font for any text that has been written in the viewport and then swaps it out as soon as you no longer looks at that block of text – or straight up uses a different font for my modifications compared to the committed code.
But even without anything like that, if it’s good for reading I like to use different fonts when reviewing and writing code to help with the context-switch, so I think this could be useful to me. And I guess people in regions where a single keystroke isn’t always a single character such as Korea, China, Japan and the arab world might be used to the jarring effect already?
Could the “jump” problem be improved with a subtle transition (200ms, 1s, etc) from one state to the other?
If the editor “repaints” commit mono on the letter-pair boundary, I could see that being a very jumpy UX — ie: the letter I just typed is moving by a few pixels. But if that repaint happens on the word boundary it might be less noticeable?
In either case, a transition could be helpful for commit mono and/or Monaspace. (But agreed with above comments that Monaspace is more subtle because it spreads the spacing over the entire word, so maybe the transition is not actually percievable or worth it). :)
It really is super clever! And the crazy part is that it's been possible for a super long time, just nobody thought of the technique. Mad props to Riley Cran and the entire crew at https://lettermatic.com for devising this technique as a part of this project.
I'm curious: did the team consider applying the technique to letter pairs like Ty and TA that traditionally get kerned closer together in proportional fonts?
As far as I can tell from the demo, these pairs currently aren't affected by texture healing, and they look a little awkward in Radon especially.
Meh... not convinced. Once you have toggled the checkbox a few times, you start noticing inconsistencies: e.g. in the example shown by default, the second "m" in "time_limit" is obviously wider than the first one because it has more space to "grow" having "i"s on both sides. Not sure if I like this...
So many people here are now praising texture healing, but to me its just half-way measure. Why are we as a community so resistant for adopting variable-width fonts? This texture healing already breaks perfect character cell grid, so in some ways it feels like worst of both worlds.
I feel at least partially the same about fancy ligatures; we could just use the actual characters in source code, Unicode is widely supported. Raku does that, but it would need better typesetting (with variable-width fonts) to really shine.
It sometimes breaks out of the grid, but there still is a grid. Things are sometimes not micro-aligned but still macro-aligned, and that matters (to me).
It only breaks the grid visually (and not by much); for layout purposes, which is what you depend on, the grid is still intact.
Why do we keep using fixed-width fonts? Because a lot of stuff has been written that depends on a columnar grid. Most notably, terminals are absolutely predicated on it and fundamentally cannot support any other mode of operation.
To begin with: visual alignment, ASCII art, diagrams using box-drawing characters, &c., both in code and in the output of diverse tools:
def function_name(and_long_parameter_list,
so_that_it_wraps="like so"):
pass
ABC_D = 1 # Explanation
ABC_EFG = 2.0 # Another one
ABC_HI = 34 # A third one
┌────────┬─────────────┐
│ Tables │ Using │
┝━━━━━━━━┿━━━━━━━━━━━━━┥
│ Cell │ Box-drawing │
│ Cello │ characters │
│ Viola │ ⋮ │
│ Voilà │ │
└────────┴─────────────┘
error: cannot find macro `behold` in this scope
--> <anon>:1:13
|
1 | fn main() { behold!() }
| ^^^^^^
$ ls -la
total 43210
drwxr-xr-x 17 root root 4096 Jan 1 23:45 .
drwxr-xr-x 17 root root 4096 Jan 1 23:45 ..
lrwxrwxrwx 1 root root 7 Feb 29 2020 bin -> usr/bin
drwxr-xr-x 2 root root 0 Dec 31 23:59 boot
⋮
(I included the ⋮ in the box drawing table deliberately, because it demonstrates a weakness in the scheme: terminals and most monospacy text editors force stuff into the grid, just clipping or overflowing the cell if a glyph has to come from a fallback font, but most other things don’t, so you end up with visual alignment breaking if the fallback font used has different metrics. Also the whole East Asian Width thing and ucwidth and whatever is super messy. Your monospace font may or may not include the box-drawing characters, but it’s much more unlikely to include ⋮.)
Terminals are also built on columnar behaviour; there are escape codes for moving the cursor to such-and-such a line and column, for example, and things like a side-by-side split require columnar behaviour.
Text editors can go non-monospaced, but it breaks various content for the reasons discussed, and you’ll need monospace for any terminal because loads of stuff will break otherwise, so combined with inertia, even editors that support proportional fonts aren’t often used that way if they default to monospace.
(Me, I’d rather like to use a proportional font while editing, but I’m not moving off Vim for it, so I’ll probably never get it. But for presentation, I like to go at least partially proportional with the monospace font Triplicate’s Poly variant, which breaks strict monospaceness, widening characters like w/m/W/M and narrowing characters like i/j/l/1. As for what Monaspace’s texture healing, I like it most of the time, but am not sold on cases like some_function_w_, where the last two underscores are markedly shorter than the first and it feels unbalanced.)
To build on to sibling chrismorgan's excellent post, fixed-width fonts/ASCII art/Unicode drawing are a really elegant way to get 80% of what you'd ever want. Getting to 100% involves a full-on rendering system and markup which is 10x the work and complexity. To date, most people don't want that in their editor.
The issue with that is that it would reduce the space between pairs that need it (such as mb). Taken to an extreme, mm would run together into one letter.
I was initially thinking ... "OK, another monospace font (family), look nice", until I got to "texture healing" which really made me want to try it out.
I really like the idea of using different style of font for different things, but as primarily terminal user, I don't even know which terminals support it (if any), and then we would need CLI text editors support as well. But I think it's a great idea.
Theoretically, anything based on xterm should have the capability for it. ESC[<10-19>m is the escape sequence to pick font 0-9. In practice though, is a different question. I use Alacritty, but I cannot find if this is supported and trying to do it myself isn't getting any results.
I'm curious what people think of the "Mix & Match" examples.
Radon (the handwriting one) seems to complement the other fonts well because it's basically an italic. But all the others are so similar, with their identical metrics and whatnot, that the "authoritative docstrings" and "Copilot voice" examples are really hard to distinguish.
tbh this immediately popped into my mind before scrolling down the page - having a handwritten comment is neat and adds another differentiation to reduce strain when browsing code. some will hate it, but personally I want to try it.
I've loved Victor Mono [0] Italic for this reason for years! I find prose much easier to read with some slight joined-up lettering, which I totally concede is a 100% personal. Worth a look as well though!
This is a hearty number of ligatures, and yet it is still not enough for me. Now that != and <= are table stakes, I keep noticing how nice Fira Code's alignment of the * height in *ptr, or the centering of the : in X:Y, or the raising of the x in 0xFF are. And the shaping of the Krypton variant would be my favorite - if the crossbar of the lowercase t was not so far below the height of e.g. the lowercase c. So I think I'm still sticking with Fira Code for now (but will certainly be checking back in a year to see what they've changed with user feedback).
I enjoy the idea, but I do wonder why we don't see more condensed fonts like PragmataPro. I've been using it for close to a decade and I'd love to see more options in the space, but no-one seems willing to go that narrow. Berkeley Graphics has been promising a condensed version of Berkeley Mono for almost a year but nothing has happened there.
Even Monaspace here has a width slider, which starts at "wider than PragmataPro" and just slides to "silly width". I wonder why they didn't try sliding down to a condensed version?
I agree entirely. PragmataPro is my daily driver, and anything else feels way too expansive.
Default Iosevka is close, but the leading is much larger. Luckily you can customize it to be almost identical (set `leading = 1110` in the config; value obtained by trial and error).
I was on a quest to find the narrowest font and Quinze was the answer. It's something like 20% narrower than Iosevka and M+. I can't find an easy comparison with PragmataPro but if Iosevka is a free interpretation of PragmataPro like you mentioned then Quinze should be narrower as well.
In fact Quinze is so narrow that when I attempted to force its use in all monospace text in the browser, readability took a hit instead of improving. This is because at the same height it is much smaller than "normal" fonts. In my coding setup I use a huge font size which works great with the narrow width.
I guess the downside is that Quinze is very minimal: pretty much only ASCII, no ligature, no customization etc. None of those bother me.
I am a big fan of Protesilaos Stavrou's custom "Iosevka Comfy" build (https://github.com/protesilaos/iosevka-comfy). This is probably the best font ever designed to my eyes, even more than my paid version of PragmataPro.
I just discovered M+. I rather like the "60" variants, and found the default (50) width is too narrow for me. For my tastes legibility seems to suffer with the 50 variants. However, that might be narrow enough for you.
Speaking of condensed font, anyone has a recommendation for a good (paid or free) Serif condensed font?
I'm using "Bell MT" to replace Times in browser (and also using it for variable-pitch font in emacs Org mode), it is good but I wish it had a taller/condensed version.
Also, one of the best condensed mono font is "The Sans Mono Condensed" which first popularized by early Oreilly books (it has since switched to other mono fonts). The downside is that it only has a western character set but I liked it a lot
I'm bothered by the Rd symbol of Radon on the page, it's should be Rn. It makes me double-check if there's actually an element that's not Radium (Ra), not Radon (Rn), but also starts with an R and has a d in its name.
Sadly I think that because of that flag it does not enable ligatures.
I was able to see ligatures and text healing in vim running in a patched st* though. I really like it thanks! The text healing only moves the line subtly as I type and when I cursor over there are no droppings from the widened 'm' for example. It's well thought-out for code.
Are you sure? On OSX they're showing up in Font Book under "Fixed Width" fonts. I'm using whatever version was released today, so that might be a recent fix.
For me, I think proportional fonts are the way text was meant to seen, and monospaced fonts exist to accommodate the limitations of computers, printers and typewriters.
Why is that? In text or punctuation?
For words it’s more readable. The punctuation is designed for coding. The numerals are still monospaced.
I would love to use a proportional font for coding but I am not aware of any Vim frontends that cleanly support it. I would be fine to stick with using monospace when using Vim over SSH but even though Neovim has opened the floodgates to frontends it seems that very few support proportional fonts (and the ones that do tend to be painfully slow to use).
I'm always really confused about how dotted zeroes became the norm for these fonts. I always confuse them with eights and vastly prefer slashed zeroes. Would love to try this if it had such a variant.
There's languages where a slashed circle is a letter, and a slashed zero makes things confusing. Dotted zeroes have much less opportunity for confusion in that direction. I guess type designers could emphasise the convex sides of a dotted zero with the concave sides of an "8" to keep them visually distinct, but I don't know if this font does that.
Texture healing is a really smart and beautiful idea! I will try to apply it to Chinese handwriting, which is often monospace. A lot of common, but really dense characters (especially traditional ones, for example these: 邊鐵餐廳臺藥機麵顧露樓幫讓) could benefit from receiving additionally space to spread out.
It's a shame that on VS Code at least (I'm not sure if this applies in other contexts), the "textual healing" feature goes hand-in-hand with ligatures. There is no way to enable textual healing if you prefer not to use programming ligatures.
When on its own, which it is in the descriptions, I couldn't tell if it was an I, Z or l. It looks cool, so I guess I'd just get used to it. But I fully agree that those tails are really exaggerated.
I have a love/hate relationship with that song. I hate it because some guy used to play it on repeat on a server-wide radio on an old Garry's Mod surf server I frequented... On the other hand, I love being reminded of those times.
There is no point in cranking out yet another code font that doesn't have hinting. PragmataPro and Berkeley Mono are such well loved fonts not because of their aesthetic quality (code fonts are (proudly) ugly), but because of how well their hinting has been done.
If I want an unhinted, but well performing, font... there is Iosevka. Which I use.
If you're interested in a free, but carefully hinted coding font, my Luculent font [0][1] may be worth a look. The hinting is its defining feature, since I hate fuzzy font rendering. I wrote every line of TTF hinting code in it myself (no autohinting), and it is legible down to 5x11 pixel sized characters even if you disable antialiasing, so long as your font engine interprets the hints.
Is there a trick to getting these to work in Sublime Text? I normally use Source Code Pro, which also comes in a bunch of variations, and I can set font_face to "Source Code Pro Medium" or "Source Code Pro Semibold Italic" and I get the right result. But setting it to "Monataype Krypton Medium" doesn't work at all. "Monatype Krypton" does, but the Regular variants are too skinny.
Font selection is always a bit wonky on OSX in my experience. Sublime doesn't offer a separate font weight knob but does offer "font_options" which takes an array of string values – specifying bold will get you a bold by default font. For an arbitrary weight what worked for me was to use the PostScript name e.g. "MonaspaceArgonVar-ExtraLightItalic". There are plenty of ways to find the PS name but on OSX (on Sonoma at least) you can go into the Font Book app and find it under identifiers after you've selected a specific variant.
Unfortunately, it's on the editor to support mixing fonts. There's never been multiple compatible monospaced fonts before so no editors really support this yet. Lots of editors also don't support variable typefaces properly yet (ahem, VS Code) but this is going to change.
Ultimately what you're describing is the future! But we have to release the typefaces to bootstrap that future.
We made a prototype extension that hack it into VS Code. But they're hacky af and not really releasable.
Do you know of any Linux terminal (eg. xterm, gnome-terminal, etc.) that would support multiple fonts? I'm intrigued, shouldn't be very hard to add support to command-line programs (once terminals supported it).
I've configured Neovim's syntax highlighting to make comments bold italic, and then I've configured my terminal (Kitty) to display a different font for bold italic text.
Using this approach, you can use up to 4 different fonts: One for normal text, one for italic, one for bold, and one for bold italic. And the font for each group doesn't necessarily need to be that style, e.g. you can use a non-bold version for the `bold` font, etc.
This looks really cool! I personally use Jetbrains Mono [0] as my goto font, but with the different-fonts-per-context and texture-healing features I might switch to this.
Is there a functional purpose to Krypton? If it just looks cool, that's fine; I just wonder what I don't know about mono fonts.
Edit and OT: Interesting HN algorithm behavior: I just wrote two posts in this thread (on different topics). The first appeared at the top of the page, as usual for new comments. When I clicked "Submit" on the second one, it appeared below the first one. My guess is that it was because it's much shorter. (First comment:
https://news.ycombinator.com/item?id=38213113 )
Krypton's 0 is angular how I like it for my coding font, but I only do it for zero. It'd be nice if the digits could vary how high they start, like in old textbooks.
The texture healing feature seems awesome, and supporting lots of weights, OT features, etc seems good (so long as your editor supports them, though web-based editors like vscode should). I don’t love the italic options — most of the variants only change slant. Xenon changes a little. I guess you’re meant to switch to Radon for italics but I find it looks far too scratchy, even if you increase the weight a bit (which will then not match the rest of the text). I also don’t love how all-caps text renders, though I don’t see that much all-caps at the moment.
In the sample text box, when I enable the grid, sometimes the gridlines pass right through the characters. For example, the default settings (Neon, size 16, weight 300, width 100, slant 0, texture healing on (or off), ligatures on), in the line "// Implement timing", the gridlines encroach on charcters in "Implement" and clearly intersect characters in "timing".
If it's just an issue with the textbox, it doesn't matter. If it's an issue with the monospaced font, that's a problem.
I've tried many of the hip programming fonts but the one I keep coming back to is Ubuntu Mono. It's the only font that can give me a good density on my standard DPI screen. All the others seem to look like absolute crap when they are small and only look good when each character uses up about twice the pixels that I want it to.
Makes me wonder how other people deal with so few characters on their screen, or is everyone using high DPI, >1080p monitors?
I might try this one, but I doubt it will be any improvement.
A nice detail I never noticed in typography is how the $-sign loses the vertical line on heavier weights. It's visible on the first example-line, the font gets bolder on hover.
Well, what if instead of wanting APL (an array-based programming language that really has nothing in common semantically with the one I use day-to-day), I just want things that are conceptually one symbol to actually look like one symbol? After all, you do not have to use my computer which has them enabled, and you do not have to enable them to use fonts that include them. This is straightforwardly 'other people should stop having preferences': No, thank you.
Jetbrains, VSCode people, whomever: edit mode and presentation view. There are times when I think for a lot of people the traditional math style makes sense for reading, but when it comes to editing, it bothers the hell out of me too.
That's use, not abuse, it's 2 chars, but 1 symbol, so it makes sense to use 1 symbol to represent it. That's the fundamental benefit - matching meaning to representation
Another way to fix the inconsistency is for the language designers to get unstuck from the past and allow literal ≠ in code
I like everything about this! Font families seem like an incredible idea that I'm surprised nobody's done before, variable fonts are new to me and super interesting, textural healing seems like a huge step forward, and damn if that isn't one of the smoothest sites I've ever played with. Nice work!
> Font families seem like an incredible idea that I'm surprised nobody's done before
Oh this has been done for decades. Metafont (by the inimitable Don Knuth) let you describe glyphs as toolpaths in code. You could have as many parameters as you wanted; I've seen examples where a sans-serif is smoothly swept into a serif.
Metafont never got adopted as much as I would have hoped; the lack of a graphical editor and some impedance mismatch with OpenType probably prevented its wider adoption.
there are still people using it---a few examples of being used in Malayalam: https://typedrawers.com/discussion/4912/metafont-in-2023-nup... (the paper linked there has more information); the comments have work by another group which was presented at the TeX Users Group conference a few months ago.
Also, according to Don Knuth himself: "Asking an artist to become enough of a mathematician to understand how to write a font with 60 parameters is too much".
Part of me loves texture healing, part of me hates it, but I think enough of me likes it to maybe give it a try. Did find a "bug" or something where a bunch of "///////" goes out of whack though.
If someone who maintains this site happens to be here: in the “code ligatures” section, where .overflow-y-scroll is used, that should be doing `overflow-y: auto` rather than `overflow-y: scroll`… though honestly I’m sceptical about the wisdom of the height capping anyway.
`overflow: scroll` is almost never (p>0.999) the right thing, and users that don’t use overlay scrollbars are suffering because of the poor choice of name, getting a forced scrollbar when one is almost never appropriate. (This includes almost all Windows for now, I believe; and some Linux, probably no longer most since GNOME is bent on ruining everyone’s life; and some macOS.)
—⁂—
When is `overflow: scroll` legitimate?
One obsolete case is preventing document scrolling when a modal is open, without triggering reflow due to the scrollbar disappearing, but I say the side-effects are still worse than the problem (the document scrollbar is nonsensical while the modal is open), so you should let it be (why was scrolling the document under the modal such a problem anyway?), or prevent scrolling by means other than scrollbar manipulation, by capturing it in the modal backdrop.
Another obsolete case is avoiding a bit of layout shift when switching between pages if some fit in the viewport an others don’t; but honestly it’s so long since I’ve seen a site where any pages fit in the viewport… and more to the point, this is better handled with `scrollbar-gutter` (not supported by Safari; you could use @supports to fall back to `overflow: scroll`, but the importance and number of affected users—since Safari is normally overlay scrollbars—are so tiny I don’t think it’s worth it).
The only arguably legitimate case I can think of is on spreadsheets/data grid components, where you can reasonably prefer to display a noop scrollbars rather than just reserving the space for them.
OK, and one other: code to find scrollbar dimensions for various layout purpose normally uses `overflow: scroll` on a temporary element and this is legit, even though you could do it other, mildly more complex ways; but it also makes assumptions about scrollbars always being the same size, and there’s honestly no reason why they should be, and `scrollbar-width` has shown a distinct appetite for using thinner scrollbars in some places and a browser could reasonably vary its default scrollbar width based on the dimensions. And scrollbar-dimension-finding isn’t particularly common, and the problems it’s used to solve are mostly better handled in other ways; now if only viewport units weren’t broken by design in the presence of document scrollbars…
I’ve contemplated campaigning for explicit deprecation of `overflow: scroll` and getting warnings shown in dev tools if you use them, because I’ve seen it misused so many times in the last decade, where people actually meant `overflow: auto`, and other than scrollbar-dimension-finding doubt I’ve seen even a single legitimate and reasonable use in that time.
I have used it a few times in cases where I am showing some text whose size will vary a bit, around the scrolling threshold. Better to consistently show the scrollbar than have everything jump.
Still surprised that you are so worked up by this - is it really so common or so problematic?
I encounter inappropriate `overflow: scroll` that should have been `overflow: auto` very frequently (in the scheme of things), probably averaging over once a month.
Your use case sounds like it might be better handled by `scrollbar-gutter: stable`, though I might adjust my judgement on seeing it.
I'm guessing they'd say "because it looks nicer". I'm not aware of a language that treats it specially.
I do think I've seen it before, I don't think it's a new idea. Probably some typographic tradition from when it was used as a section separator in prose.
I find { to be ok, although I kinda expected them to differ across the font family (esp. Mechanical)
The one that kills me is the squiggly comparisons ~>, I find it horrible and doesn't evoke the kind of comparison I see in Gemfiles.
I read |> as "pipe + redirect" for me so turning them to triangles make them lose a ton of meaning.
Oh and != is so much wider than >=, probably because == is, so as not to be confused with = which kinda makes sense but is visually jarring. It's even more jarring with === which gets so wide and thin three-band that it loses its "equalness" and becomes a striped rectangle.
The healing is a nice trick but the difference of m character width riles me up when they line up vertically:
limit
gamut
I can't quite make sense of the whole of ss04 </ glyphs. I feared \/ and /\ would be terrible for awkperlruby regexes, but they only apply if there's whitespace around (still / \/ / is an improbable yet valid regex that would have it transformed)
Turns out a font can only infer so much based only on characters when combinations are contextual.
But the most annoying thing is that even if that was solved, ligatures are terrible when editing, especially when your (line) caret ends up in the middle of a ligature or (box) over half of the character (or third), which breaks the illusion/abstraction as you now have to think about the underlying characters.
I really hate most of these fontLigatures. They just confuse me, many of the character combination I never even used in the languages I code in. And others look so different that I would be afraid to not know what they actually are.
Some seem useful but is seems I can not pick them individually and have to commit to an entire group of them. The symbol for </> (something I never used anyway) looks like the absolute worst to me, like how is that better? And especially of you do rarely or never used it you get forced into this shit if you like other things from that group and enable it.
Turning two == into one long one, NO! I think people just overthink it, it becomes confusing and not more readable.
Some other fonts use character variants for this, so you can personalize your own setup. For example, with Fira Code[0], if you want to tell VS Code to not use the long = for == but still space it in a less ugly way, instead of setting ligatures to true, you set it to "'ss08'", which will then do the same thing to === and != and !==. This is also where they can hide their 'overthinking' glyphs, so the discerning user can enable them but they won't disrupt you if you just install the font normally. For example I have ss06, ss07, and cv27 enabled, for distinct escaping backslashes, =~ and !~ operators, and smooth-square [].
Yes, but how many of the features will work, and how to configure them, will depend on your application and the toolkit it uses. It also seems to vary by application on MacOS and Windows, so I don't think it's notably worse on Linux.
> Monospaced fonts are generally incompatible with one another. Each one uses different metrics, making it impossible to mix different fonts. Each Monaspace font is designed to be seamlessly mixed and matched. Layer more meaning onto code, with a palette that goes beyond colors and bolder weights. Build interfaces for code that require more structure and hierarchy.
FTA. It means you can do things like have inline comments use Radon, docstrings use Xenon, code use Neon, and string literals use Krypton for more visual difference -- without the line heights and columns getting all weird because of it.
Unfortunately a brilliant and predictable play by Microsoft following its established "Embrace, Extend, Extinguish" doctrine.
This beautiful feature is created by the GitHub team and is only available on VS Code, strengthening its lead over the other editors.
This fact has led me to look more closely at Commit Mono, suggested by nvartolomei in his comment (this article). I love the texture healing idea, and that font looks to be more open and easier to use in other environments.
It does seem to only be tested in VS Code, though. It "works" everywhere (except some terminal emulators, which don't see it as monospaced), but you may have trouble enabling all of the features everywhere.
Using multiple fonts isn't available in VS Code right now, not without doing something hacky with 3rd party custom CSS plugin. It isn't available anywhere without doing something hacky (setting different fonts for italic and bold in the terminal, for example).
The "Texture Healing" feature is a really smart use of OpenType features to make problematic monospace combinations look much better without breaking the grid at all.
One naive way to do this would be to create ligature pairs for difficult pairs (mi, lm, etc). But instead, they seem to be selecting character alternates that fill the fixed width differently based on their surroundings.
Commit Mono font does something similar and calls it “Smart kerning”. Visit https://commitmono.com/ and click on the “04 Intelligent” tab for details.
In practice this is unusable. Because the width of the letters now depends on the succeeding character, the text jumps as you write it. Super annoying.
Cool for reading. Awful for writing.
It doesn't in this font? Possibly because of what they talk about where it optimistically gives as much space as possible to succeeding glyphs. You can try it on the page; the code sample boxes are editable. I see no jumping when I type "calming", their example word.
[append] Oh, I do see some jumping when I type "optimized". Honestly, it doesn't seem very jarring to me; the jumping is always right where the edit point is so the added or removed letter causes a much bigger jump.
1 reply →
Unrelated, but why is it that Font marketing pages specifically always have such cool-looking demoes? I love the navigation on that site, I might steal that for my own site
1 reply →
If this gets popular, I could see a text editor that lets you use a non-healing version of the font for any text that has been written in the viewport and then swaps it out as soon as you no longer looks at that block of text – or straight up uses a different font for my modifications compared to the committed code.
But even without anything like that, if it’s good for reading I like to use different fonts when reviewing and writing code to help with the context-switch, so I think this could be useful to me. And I guess people in regions where a single keystroke isn’t always a single character such as Korea, China, Japan and the arab world might be used to the jarring effect already?
2 replies →
Could the “jump” problem be improved with a subtle transition (200ms, 1s, etc) from one state to the other?
If the editor “repaints” commit mono on the letter-pair boundary, I could see that being a very jumpy UX — ie: the letter I just typed is moving by a few pixels. But if that repaint happens on the word boundary it might be less noticeable?
In either case, a transition could be helpful for commit mono and/or Monaspace. (But agreed with above comments that Monaspace is more subtle because it spreads the spacing over the entire word, so maybe the transition is not actually percievable or worth it). :)
Exactly my experience as well.
[flagged]
It really is super clever! And the crazy part is that it's been possible for a super long time, just nobody thought of the technique. Mad props to Riley Cran and the entire crew at https://lettermatic.com for devising this technique as a part of this project.
I'm curious: did the team consider applying the technique to letter pairs like Ty and TA that traditionally get kerned closer together in proportional fonts?
As far as I can tell from the demo, these pairs currently aren't affected by texture healing, and they look a little awkward in Radon especially.
Meh... not convinced. Once you have toggled the checkbox a few times, you start noticing inconsistencies: e.g. in the example shown by default, the second "m" in "time_limit" is obviously wider than the first one because it has more space to "grow" having "i"s on both sides. Not sure if I like this...
Also, type mimi in the first code example: the two 'm's have different width...
So many people here are now praising texture healing, but to me its just half-way measure. Why are we as a community so resistant for adopting variable-width fonts? This texture healing already breaks perfect character cell grid, so in some ways it feels like worst of both worlds.
I feel at least partially the same about fancy ligatures; we could just use the actual characters in source code, Unicode is widely supported. Raku does that, but it would need better typesetting (with variable-width fonts) to really shine.
I hate ligatures in code.
It sometimes breaks out of the grid, but there still is a grid. Things are sometimes not micro-aligned but still macro-aligned, and that matters (to me).
2 replies →
It only breaks the grid visually (and not by much); for layout purposes, which is what you depend on, the grid is still intact.
Why do we keep using fixed-width fonts? Because a lot of stuff has been written that depends on a columnar grid. Most notably, terminals are absolutely predicated on it and fundamentally cannot support any other mode of operation.
To begin with: visual alignment, ASCII art, diagrams using box-drawing characters, &c., both in code and in the output of diverse tools:
(I included the ⋮ in the box drawing table deliberately, because it demonstrates a weakness in the scheme: terminals and most monospacy text editors force stuff into the grid, just clipping or overflowing the cell if a glyph has to come from a fallback font, but most other things don’t, so you end up with visual alignment breaking if the fallback font used has different metrics. Also the whole East Asian Width thing and ucwidth and whatever is super messy. Your monospace font may or may not include the box-drawing characters, but it’s much more unlikely to include ⋮.)
Terminals are also built on columnar behaviour; there are escape codes for moving the cursor to such-and-such a line and column, for example, and things like a side-by-side split require columnar behaviour.
Text editors can go non-monospaced, but it breaks various content for the reasons discussed, and you’ll need monospace for any terminal because loads of stuff will break otherwise, so combined with inertia, even editors that support proportional fonts aren’t often used that way if they default to monospace.
(Me, I’d rather like to use a proportional font while editing, but I’m not moving off Vim for it, so I’ll probably never get it. But for presentation, I like to go at least partially proportional with the monospace font Triplicate’s Poly variant, which breaks strict monospaceness, widening characters like w/m/W/M and narrowing characters like i/j/l/1. As for what Monaspace’s texture healing, I like it most of the time, but am not sold on cases like some_function_w_, where the last two underscores are markedly shorter than the first and it feels unbalanced.)
1 reply →
To build on to sibling chrismorgan's excellent post, fixed-width fonts/ASCII art/Unicode drawing are a really elegant way to get 80% of what you'd ever want. Getting to 100% involves a full-on rendering system and markup which is 10x the work and complexity. To date, most people don't want that in their editor.
3 replies →
thats not what it does - it maintains monoSPACE while chaning the characters to not look the same width -- the best of both worlds, if anything
2 replies →
This is really cool!
I’m probably missing the obvious, but it seems to just make the “m” wider.
The issue with that is that it would reduce the space between pairs that need it (such as mb). Taken to an extreme, mm would run together into one letter.
I was initially thinking ... "OK, another monospace font (family), look nice", until I got to "texture healing" which really made me want to try it out.
I really like the idea of using different style of font for different things, but as primarily terminal user, I don't even know which terminals support it (if any), and then we would need CLI text editors support as well. But I think it's a great idea.
Theoretically, anything based on xterm should have the capability for it. ESC[<10-19>m is the escape sequence to pick font 0-9. In practice though, is a different question. I use Alacritty, but I cannot find if this is supported and trying to do it myself isn't getting any results.
Texture healing requires ligatures (specifically `calt`) and Alacritty does not support ligatures.
Alacritty does not support that, afaik.
I'm curious what people think of the "Mix & Match" examples.
Radon (the handwriting one) seems to complement the other fonts well because it's basically an italic. But all the others are so similar, with their identical metrics and whatnot, that the "authoritative docstrings" and "Copilot voice" examples are really hard to distinguish.
The mix and match is what convinced me to give this font a try. I’ve been using Operator Mono for years now specifically because of it’s true italics.
I’ve wanted to switch to an open alternative to Operator Mono for a long time now, and I think because of the mix and match, this finally is the one.
tbh this immediately popped into my mind before scrolling down the page - having a handwritten comment is neat and adds another differentiation to reduce strain when browsing code. some will hate it, but personally I want to try it.
I've loved Victor Mono [0] Italic for this reason for years! I find prose much easier to read with some slight joined-up lettering, which I totally concede is a 100% personal. Worth a look as well though!
[0] https://rubjo.github.io/victor-mono/
yeah, i flipped through the samples without even realizing it was changing anything in the code sample box until i got to the radon variant.
those other variants are not nearly different enough to really convey information.
How do you configure different fonts? This was the first thing I wanted to try, but can't figure it out. Am I missing anything obvious?
I tried to use custom css in vscode but couldn’t figure out how to get it to work.
I really like this idea. Is this supported anywhere yet or just something for future?
This is a hearty number of ligatures, and yet it is still not enough for me. Now that != and <= are table stakes, I keep noticing how nice Fira Code's alignment of the * height in *ptr, or the centering of the : in X:Y, or the raising of the x in 0xFF are. And the shaping of the Krypton variant would be my favorite - if the crossbar of the lowercase t was not so far below the height of e.g. the lowercase c. So I think I'm still sticking with Fira Code for now (but will certainly be checking back in a year to see what they've changed with user feedback).
Curiously for an example home page, the linked site's example ...
... misaligning the two ** in /** is awkward.
I enjoy the idea, but I do wonder why we don't see more condensed fonts like PragmataPro. I've been using it for close to a decade and I'd love to see more options in the space, but no-one seems willing to go that narrow. Berkeley Graphics has been promising a condensed version of Berkeley Mono for almost a year but nothing has happened there.
Even Monaspace here has a width slider, which starts at "wider than PragmataPro" and just slides to "silly width". I wonder why they didn't try sliding down to a condensed version?
I agree entirely. PragmataPro is my daily driver, and anything else feels way too expansive.
Default Iosevka is close, but the leading is much larger. Luckily you can customize it to be almost identical (set `leading = 1110` in the config; value obtained by trial and error).
+1 for PragmataPro, bought it 4 years ago and haven't looked back yet.
Have you tried Quinze? https://www.programmingfonts.org/#quinze
I was on a quest to find the narrowest font and Quinze was the answer. It's something like 20% narrower than Iosevka and M+. I can't find an easy comparison with PragmataPro but if Iosevka is a free interpretation of PragmataPro like you mentioned then Quinze should be narrower as well.
In fact Quinze is so narrow that when I attempted to force its use in all monospace text in the browser, readability took a hit instead of improving. This is because at the same height it is much smaller than "normal" fonts. In my coding setup I use a huge font size which works great with the narrow width.
I guess the downside is that Quinze is very minimal: pretty much only ASCII, no ligature, no customization etc. None of those bother me.
Iosevka is pretty narrow and also popular. Not sure if it meets your definition, but might be worth a look.
I am a big fan of Protesilaos Stavrou's custom "Iosevka Comfy" build (https://github.com/protesilaos/iosevka-comfy). This is probably the best font ever designed to my eyes, even more than my paid version of PragmataPro.
Here is a screenshot of Iosevka Comfy in action: https://share.combo.cc/-bN9f8hAiiG
and Iosevka Comfy Motion, with tasteful serifs: https://share.combo.cc/-BNHfhV4zgu
Yeah, it is because AFAIK Iosevka is a free interpretation of PragmataPro! So you are definitely correct :D
I just discovered M+. I rather like the "60" variants, and found the default (50) width is too narrow for me. For my tastes legibility seems to suffer with the 50 variants. However, that might be narrow enough for you.
https://mplusfonts.github.io/
Speaking of condensed font, anyone has a recommendation for a good (paid or free) Serif condensed font?
I'm using "Bell MT" to replace Times in browser (and also using it for variable-pitch font in emacs Org mode), it is good but I wish it had a taller/condensed version.
Also, one of the best condensed mono font is "The Sans Mono Condensed" which first popularized by early Oreilly books (it has since switched to other mono fonts). The downside is that it only has a western character set but I liked it a lot
Try the "Recursive Mono" or "PT Mono" variants of Iosevka.
I'm bothered by the Rd symbol of Radon on the page, it's should be Rn. It makes me double-check if there's actually an element that's not Radium (Ra), not Radon (Rn), but also starts with an R and has a d in its name.
Noticed this too, it's been since fixed :)
Rhodium, but that's Rh.
Neat, one more element to the "Rd" element group.
It does not set the mono flag, so I had to try it with GTK2 gvim to even load the font:
Sadly I think that because of that flag it does not enable ligatures.
I was able to see ligatures and text healing in vim running in a patched st* though. I really like it thanks! The text healing only moves the line subtly as I type and when I cursor over there are no droppings from the widened 'm' for example. It's well thought-out for code.
If I could ask for a feature it would be to select some variants, like angular 0 with reverse slash or to leave the ! in the != ligature. To see what I mean: https://github.com/be5invis/Iosevka/blob/main/doc/stylistic-...
* https://st.suckless.org/patches/ligatures/
Are you sure? On OSX they're showing up in Font Book under "Fixed Width" fonts. I'm using whatever version was released today, so that might be a recent fix.
Just checked, don't show-up in under fixed, monaspace 1.000 macos 13.6.1
2 replies →
I am having the same issue in KDE Konsole: https://imgur.com/a/Dj1HZiu
I have to explicitly set the "Show all fonts" checkbox which shows all "non monospaced" fonts.
Seems like in modern times, on modern systems, we can move beyond monospaced fonts for code.
I have recommended this many times here, but I use a proportional coding font: Input Sans
https://input.djr.com
What are the reasons for your recommendations? One problem I might see is that it is even harder to spot a typo with this font.
For me, I think proportional fonts are the way text was meant to seen, and monospaced fonts exist to accommodate the limitations of computers, printers and typewriters.
Why is that? In text or punctuation?
For words it’s more readable. The punctuation is designed for coding. The numerals are still monospaced.
I would love to use a proportional font for coding but I am not aware of any Vim frontends that cleanly support it. I would be fine to stick with using monospace when using Vim over SSH but even though Neovim has opened the floodgates to frontends it seems that very few support proportional fonts (and the ones that do tend to be painfully slow to use).
Does it support ligatures such as >= to ≥? I tried the web preview on a phone maybe it is a limitation of Firefox on Android?
For others, this is ligatures https://fonts.google.com/knowledge/glossary/ligature
I don’t think so? I personally don’t use that feature :)
I'm always really confused about how dotted zeroes became the norm for these fonts. I always confuse them with eights and vastly prefer slashed zeroes. Would love to try this if it had such a variant.
There's languages where a slashed circle is a letter, and a slashed zero makes things confusing. Dotted zeroes have much less opportunity for confusion in that direction. I guess type designers could emphasise the convex sides of a dotted zero with the concave sides of an "8" to keep them visually distinct, but I don't know if this font does that.
This is why some fonts like Atkison Hyperlegible use reverse slashed zero, which removes the confusion.
Θ.
3 replies →
I suggested slash zero in an issue and some rando mentioned dotted zeroes serve the same purpose. So annoying.
Texture healing is a really smart and beautiful idea! I will try to apply it to Chinese handwriting, which is often monospace. A lot of common, but really dense characters (especially traditional ones, for example these: 邊鐵餐廳臺藥機麵顧露樓幫讓) could benefit from receiving additionally space to spread out.
I keep using Berkeley Mono! That font is just perfect! This font and the styles are a bit wonky for me...
It's a shame that on VS Code at least (I'm not sure if this applies in other contexts), the "textual healing" feature goes hand-in-hand with ligatures. There is no way to enable textual healing if you prefer not to use programming ligatures.
From https://github.com/githubnext/monaspace?tab=readme-ov-file#v...
> If you want coding ligatures but do not want texture healing, you can elide the calt setting:
GP asked for the opposite of that. Ligatures are troublesome while writing code.
2 replies →
Lower case 'l' on Radon looks too much like a 'Z'. It needs rounder tails.
When on its own, which it is in the descriptions, I couldn't tell if it was an I, Z or l. It looks cool, so I guess I'd just get used to it. But I fully agree that those tails are really exaggerated.
When I get that feeling / I need textural healing
I have a love/hate relationship with that song. I hate it because some guy used to play it on repeat on a server-wide radio on an old Garry's Mod surf server I frequented... On the other hand, I love being reminded of those times.
for anyone unaware, Marvin Gaye - Sexual Healing https://youtu.be/fn4i8bAfnMY
No hinting apparently, so only for hi-DPI.
That's all I need to know about this font.
There is no point in cranking out yet another code font that doesn't have hinting. PragmataPro and Berkeley Mono are such well loved fonts not because of their aesthetic quality (code fonts are (proudly) ugly), but because of how well their hinting has been done.
If I want an unhinted, but well performing, font... there is Iosevka. Which I use.
If you're interested in a free, but carefully hinted coding font, my Luculent font [0][1] may be worth a look. The hinting is its defining feature, since I hate fuzzy font rendering. I wrote every line of TTF hinting code in it myself (no autohinting), and it is legible down to 5x11 pixel sized characters even if you disable antialiasing, so long as your font engine interprets the hints.
[0] http://eastfarthing.com/luculent/
[1] https://fontlibrary.org/en/font/luculent (live example in browser)
2 replies →
It looks fine on my standard DPI screens, but I'm assuming that that's because the freetype2 autohinter is being used.
Doesn't appear in gVim on Windows, need to set the panose attribute first:
Is there a trick to getting these to work in Sublime Text? I normally use Source Code Pro, which also comes in a bunch of variations, and I can set font_face to "Source Code Pro Medium" or "Source Code Pro Semibold Italic" and I get the right result. But setting it to "Monataype Krypton Medium" doesn't work at all. "Monatype Krypton" does, but the Regular variants are too skinny.
Font selection is always a bit wonky on OSX in my experience. Sublime doesn't offer a separate font weight knob but does offer "font_options" which takes an array of string values – specifying bold will get you a bold by default font. For an arbitrary weight what worked for me was to use the PostScript name e.g. "MonaspaceArgonVar-ExtraLightItalic". There are plenty of ways to find the PS name but on OSX (on Sonoma at least) you can go into the Font Book app and find it under identifiers after you've selected a specific variant.
Thanks, this works!
So tl;dr it's: "MonaspaceVARIANT-WEIGHT", no spaces.
1 reply →
The name format is "Monaspace <variant>", and to use weight in Sublime Text "Monaspace <variant> <weight>".
Confirmed, other resposne is wrong.
Format that worked for me is :
"font_face": "Monaspace Neon Light",
Texture healing is that kind of feature you never knew you needed until you knew about it. A perfect candidate for my next obsession.
How would you configure a text editor or terminal to use different fonts based on syntax (e.g. neon for code, argon for comments)?
Hi! I worked on this at Next.
Unfortunately, it's on the editor to support mixing fonts. There's never been multiple compatible monospaced fonts before so no editors really support this yet. Lots of editors also don't support variable typefaces properly yet (ahem, VS Code) but this is going to change.
Ultimately what you're describing is the future! But we have to release the typefaces to bootstrap that future.
We made a prototype extension that hack it into VS Code. But they're hacky af and not really releasable.
> so no editors really support this yet
Emacs and Vim have both supported this since at least last century.
1 reply →
Do you know of any Linux terminal (eg. xterm, gnome-terminal, etc.) that would support multiple fonts? I'm intrigued, shouldn't be very hard to add support to command-line programs (once terminals supported it).
1 reply →
I wonder if terminal escape code sequences would arise to support this too!
I've configured Neovim's syntax highlighting to make comments bold italic, and then I've configured my terminal (Kitty) to display a different font for bold italic text.
Using this approach, you can use up to 4 different fonts: One for normal text, one for italic, one for bold, and one for bold italic. And the font for each group doesn't necessarily need to be that style, e.g. you can use a non-bold version for the `bold` font, etc.
I use kitty and neovim too, would you mind sharing how you got this to work?
1 reply →
Feels very hacky.
1 reply →
In vscode probably easy because it is all CSS?
Other editors/terminal emulators would probably need to add support for this.
Some IDEs support configuring the font per syntactic category, i.e. with the same granularity as syntax highlighting colors.
This looks really cool! I personally use Jetbrains Mono [0] as my goto font, but with the different-fonts-per-context and texture-healing features I might switch to this.
0: https://www.jetbrains.com/lp/mono/
Beautiful.
Even to my aesthetically un-nuanced sensitivity, these fonts look good
Is there a functional purpose to Krypton? If it just looks cool, that's fine; I just wonder what I don't know about mono fonts.
Edit and OT: Interesting HN algorithm behavior: I just wrote two posts in this thread (on different topics). The first appeared at the top of the page, as usual for new comments. When I clicked "Submit" on the second one, it appeared below the first one. My guess is that it was because it's much shorter. (First comment: https://news.ycombinator.com/item?id=38213113 )
Krypton's 0 is angular how I like it for my coding font, but I only do it for zero. It'd be nice if the digits could vary how high they start, like in old textbooks.
The texture healing feature seems awesome, and supporting lots of weights, OT features, etc seems good (so long as your editor supports them, though web-based editors like vscode should). I don’t love the italic options — most of the variants only change slant. Xenon changes a little. I guess you’re meant to switch to Radon for italics but I find it looks far too scratchy, even if you increase the weight a bit (which will then not match the rest of the text). I also don’t love how all-caps text renders, though I don’t see that much all-caps at the moment.
In the sample text box, when I enable the grid, sometimes the gridlines pass right through the characters. For example, the default settings (Neon, size 16, weight 300, width 100, slant 0, texture healing on (or off), ligatures on), in the line "// Implement timing", the gridlines encroach on charcters in "Implement" and clearly intersect characters in "timing".
If it's just an issue with the textbox, it doesn't matter. If it's an issue with the monospaced font, that's a problem.
That is a result of texture healing. The page explains how it works.
Texture healing should keep the letters within the grid. Also, it happens with texture healing on or off.
I've tried many of the hip programming fonts but the one I keep coming back to is Ubuntu Mono. It's the only font that can give me a good density on my standard DPI screen. All the others seem to look like absolute crap when they are small and only look good when each character uses up about twice the pixels that I want it to.
Makes me wonder how other people deal with so few characters on their screen, or is everyone using high DPI, >1080p monitors?
I might try this one, but I doubt it will be any improvement.
A nice detail I never noticed in typography is how the $-sign loses the vertical line on heavier weights. It's visible on the first example-line, the font gets bolder on hover.
Can we please stop with abusing ligatures for things like != into ≠? If you want APL, please use APL and leave the rest of us alone.
!= is two bloody characters not one.
And now people are doing it for 3 characters.
With this kind of thing, you get all the text editing idiocy of combining characters (like emojis) for no benefit at all.
See: Text Editing Hates You Too https://lord.io/text-editing-hates-you-too/
Well, what if instead of wanting APL (an array-based programming language that really has nothing in common semantically with the one I use day-to-day), I just want things that are conceptually one symbol to actually look like one symbol? After all, you do not have to use my computer which has them enabled, and you do not have to enable them to use fonts that include them. This is straightforwardly 'other people should stop having preferences': No, thank you.
Fortunately for you the ligatures are optional and have no impact on the underlying text. To be "left alone" you have to do exactly nothing.
> To be "left alone" you have to do exactly nothing.
Unfortunately that's not true.
The problem shows itself when looking at codeblocks that developers share (in docs, blogs, videos, etc...)
Ligatures become a readability problem.
7 replies →
No. People like them. No one is forcing you to use them. Stop complaining about it.
I have a proposal here...
Jetbrains, VSCode people, whomever: edit mode and presentation view. There are times when I think for a lot of people the traditional math style makes sense for reading, but when it comes to editing, it bothers the hell out of me too.
IntelliJ IDEA has this feature: https://www.jetbrains.com/help/idea/reader-mode.html
In addition to ligatures, you get IMO a better version of the "Mix & Match" idea: doc comments are rendered as normal proportional text.
That's use, not abuse, it's 2 chars, but 1 symbol, so it makes sense to use 1 symbol to represent it. That's the fundamental benefit - matching meaning to representation
Another way to fix the inconsistency is for the language designers to get unstuck from the past and allow literal ≠ in code
This has a "Silicon Valley tabs vs spaces" Richard vibe all over it. Nobody's forcing you to use ligatures - it's IDE / font specific.
With all these different faces being displayed at once, this risks being the typographical equivalent of "Angry Fruit Salad" syntax highlighting…
I'm always interested in monospace fonts for coding. But personally, I still haven't found any font that can beat JetBrains Mono.
I like everything about this! Font families seem like an incredible idea that I'm surprised nobody's done before, variable fonts are new to me and super interesting, textural healing seems like a huge step forward, and damn if that isn't one of the smoothest sites I've ever played with. Nice work!
> Font families seem like an incredible idea that I'm surprised nobody's done before
Oh this has been done for decades. Metafont (by the inimitable Don Knuth) let you describe glyphs as toolpaths in code. You could have as many parameters as you wanted; I've seen examples where a sans-serif is smoothly swept into a serif.
Metafont never got adopted as much as I would have hoped; the lack of a graphical editor and some impedance mismatch with OpenType probably prevented its wider adoption.
there are still people using it---a few examples of being used in Malayalam: https://typedrawers.com/discussion/4912/metafont-in-2023-nup... (the paper linked there has more information); the comments have work by another group which was presented at the TeX Users Group conference a few months ago.
Also, according to Don Knuth himself: "Asking an artist to become enough of a mathematician to understand how to write a font with 60 parameters is too much".
2 replies →
I'm staying on BitstromWera Nerd Font. Works great with Starship.
https://www.nerdfonts.com/font-downloads
https://starship.rs
Part of me loves texture healing, part of me hates it, but I think enough of me likes it to maybe give it a try. Did find a "bug" or something where a bunch of "///////" goes out of whack though.
My monospace font is https://tug.org/FontCatalogue/latinmodernmonolight/
I want "m" with a short middle leg. Can I have it? E.g. in Iosevka (https://typeof.net/Iosevka/) I can choose.
I'm confused that Neon and Argon are described as "sans" when they seem to have serifs? See the bottoms of the i and r for instance.
Beautiful, but too wide. Iosevka NF lets me fit a lot more information and work comfortably in three columns of code in my Emacs on a 5K screen.
It's a really cool idea to have a collection of monospaced fonts that work wonderfully together. I can't wait to give this a spin today.
Cool new font features, though hopefully we get a chance to get proper proportional fonts insead of this hack in the next decade or two
Wow, these are pretty nice, with a permissive license too by the looks of things. I like the serif one in particular, very readable to me.
If someone who maintains this site happens to be here: in the “code ligatures” section, where .overflow-y-scroll is used, that should be doing `overflow-y: auto` rather than `overflow-y: scroll`… though honestly I’m sceptical about the wisdom of the height capping anyway.
`overflow: scroll` is almost never (p>0.999) the right thing, and users that don’t use overlay scrollbars are suffering because of the poor choice of name, getting a forced scrollbar when one is almost never appropriate. (This includes almost all Windows for now, I believe; and some Linux, probably no longer most since GNOME is bent on ruining everyone’s life; and some macOS.)
—⁂—
When is `overflow: scroll` legitimate?
One obsolete case is preventing document scrolling when a modal is open, without triggering reflow due to the scrollbar disappearing, but I say the side-effects are still worse than the problem (the document scrollbar is nonsensical while the modal is open), so you should let it be (why was scrolling the document under the modal such a problem anyway?), or prevent scrolling by means other than scrollbar manipulation, by capturing it in the modal backdrop.
Another obsolete case is avoiding a bit of layout shift when switching between pages if some fit in the viewport an others don’t; but honestly it’s so long since I’ve seen a site where any pages fit in the viewport… and more to the point, this is better handled with `scrollbar-gutter` (not supported by Safari; you could use @supports to fall back to `overflow: scroll`, but the importance and number of affected users—since Safari is normally overlay scrollbars—are so tiny I don’t think it’s worth it).
The only arguably legitimate case I can think of is on spreadsheets/data grid components, where you can reasonably prefer to display a noop scrollbars rather than just reserving the space for them.
OK, and one other: code to find scrollbar dimensions for various layout purpose normally uses `overflow: scroll` on a temporary element and this is legit, even though you could do it other, mildly more complex ways; but it also makes assumptions about scrollbars always being the same size, and there’s honestly no reason why they should be, and `scrollbar-width` has shown a distinct appetite for using thinner scrollbars in some places and a browser could reasonably vary its default scrollbar width based on the dimensions. And scrollbar-dimension-finding isn’t particularly common, and the problems it’s used to solve are mostly better handled in other ways; now if only viewport units weren’t broken by design in the presence of document scrollbars…
I’ve contemplated campaigning for explicit deprecation of `overflow: scroll` and getting warnings shown in dev tools if you use them, because I’ve seen it misused so many times in the last decade, where people actually meant `overflow: auto`, and other than scrollbar-dimension-finding doubt I’ve seen even a single legitimate and reasonable use in that time.
I have used it a few times in cases where I am showing some text whose size will vary a bit, around the scrolling threshold. Better to consistently show the scrollbar than have everything jump.
Still surprised that you are so worked up by this - is it really so common or so problematic?
I encounter inappropriate `overflow: scroll` that should have been `overflow: auto` very frequently (in the scheme of things), probably averaging over once a month.
Your use case sounds like it might be better handled by `scrollbar-gutter: stable`, though I might adjust my judgement on seeing it.
1 reply →
Anyone could explain why *** ligature exists?
I'm guessing they'd say "because it looks nicer". I'm not aware of a language that treats it specially.
I do think I've seen it before, I don't think it's a new idea. Probably some typographic tradition from when it was used as a section separator in prose.
I’ve not seen it in code, but if you were writing prose you might use it as a section break.
https://en.wikipedia.org/wiki/Asterism_(typography)
Edit: it’s called an Asterism
It's used in Robot Framework code, but that's the only place I can think of.
Apparently line height is to tight on Alacritty and Kitty, I would like to have line height variant like width variant.
FWIW you can tweak the line height in kitty, see https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.modify_font
This is definitely one of the nicer of the 100’s of monospaced fonts. But my personal preference remains Consolas.
The site is awesome, but in VSCode it looks messy, and the characters are too wide. Sticking with Victor Mono.
I got addicted to nerdfont style icons everywhere. This seems awesome, but I wound try it without it.
Still looks worse than Iosevka. Let's just embrace writing code in proportional fonts already.
The Xenon is very similar to Go fonts. but it's still a really great set of fonts.
The website and typeface(s) design look like they took a tremendous amount of work.
Looks kind of cool but I cannot stand their { and }. Otherwise I might give it a try
I find { to be ok, although I kinda expected them to differ across the font family (esp. Mechanical)
The one that kills me is the squiggly comparisons ~>, I find it horrible and doesn't evoke the kind of comparison I see in Gemfiles.
I read |> as "pipe + redirect" for me so turning them to triangles make them lose a ton of meaning.
Oh and != is so much wider than >=, probably because == is, so as not to be confused with = which kinda makes sense but is visually jarring. It's even more jarring with === which gets so wide and thin three-band that it loses its "equalness" and becomes a striped rectangle.
The healing is a nice trick but the difference of m character width riles me up when they line up vertically:
I can't quite make sense of the whole of ss04 </ glyphs. I feared \/ and /\ would be terrible for awkperlruby regexes, but they only apply if there's whitespace around (still / \/ / is an improbable yet valid regex that would have it transformed)
Turns out a font can only infer so much based only on characters when combinations are contextual.
But the most annoying thing is that even if that was solved, ligatures are terrible when editing, especially when your (line) caret ends up in the middle of a ligature or (box) over half of the character (or third), which breaks the illusion/abstraction as you now have to think about the underlying characters.
Definitely a no-go for me, but to each his own.
To be fair, ligatures are optional. I don’t like them either, but as long as I can turn it off I‘m ok
1 reply →
what happened to Helium?
I have tried many fonts over the years. Nothing beats Monaco.
Quite good except Radon. I can not look at it
going to try this out.. clever font name ;)
I really hate most of these fontLigatures. They just confuse me, many of the character combination I never even used in the languages I code in. And others look so different that I would be afraid to not know what they actually are.
Some seem useful but is seems I can not pick them individually and have to commit to an entire group of them. The symbol for </> (something I never used anyway) looks like the absolute worst to me, like how is that better? And especially of you do rarely or never used it you get forced into this shit if you like other things from that group and enable it.
Turning two == into one long one, NO! I think people just overthink it, it becomes confusing and not more readable.
Some other fonts use character variants for this, so you can personalize your own setup. For example, with Fira Code[0], if you want to tell VS Code to not use the long = for == but still space it in a less ugly way, instead of setting ligatures to true, you set it to "'ss08'", which will then do the same thing to === and != and !==. This is also where they can hide their 'overthinking' glyphs, so the discerning user can enable them but they won't disrupt you if you just install the font normally. For example I have ss06, ss07, and cv27 enabled, for distinct escaping backslashes, =~ and !~ operators, and smooth-square [].
[0]: https://github.com/tonsky/FiraCode
Like most things in life, it depends on the reader:
- native language
- mathematically or symbolically oriented
- etc.
I personally find them imminently readable and use with Fira Code font.
No one cares. Just don't use them.
Can this be used on Linux?
Yes, but how many of the features will work, and how to configure them, will depend on your application and the toolkit it uses. It also seems to vary by application on MacOS and Windows, so I don't think it's notably worse on Linux.
Looks amazing
i use Fira Code. nothing beats Fira.
[flagged]
Superfamily? they're just making up stuff so they can bundle a bunch of fonts and say people are using "theirs"
blah
> Monospaced fonts are generally incompatible with one another. Each one uses different metrics, making it impossible to mix different fonts. Each Monaspace font is designed to be seamlessly mixed and matched. Layer more meaning onto code, with a palette that goes beyond colors and bolder weights. Build interfaces for code that require more structure and hierarchy.
FTA. It means you can do things like have inline comments use Radon, docstrings use Xenon, code use Neon, and string literals use Krypton for more visual difference -- without the line heights and columns getting all weird because of it.
Unfortunately a brilliant and predictable play by Microsoft following its established "Embrace, Extend, Extinguish" doctrine.
This beautiful feature is created by the GitHub team and is only available on VS Code, strengthening its lead over the other editors.
This fact has led me to look more closely at Commit Mono, suggested by nvartolomei in his comment (this article). I love the texture healing idea, and that font looks to be more open and easier to use in other environments.
It's a font, you can use it wherever you want...
It does seem to only be tested in VS Code, though. It "works" everywhere (except some terminal emulators, which don't see it as monospaced), but you may have trouble enabling all of the features everywhere.
Using multiple fonts isn't available in VS Code right now, not without doing something hacky with 3rd party custom CSS plugin. It isn't available anywhere without doing something hacky (setting different fonts for italic and bold in the terminal, for example).
I have never and don't ever intend to use VS Code. If you're anti Microsoft, just say so.