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.
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.
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.
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?
> 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
The text editor widget on their page is a bunch of "line" divs with individual terms being inside spans. If you add an inline style of
to a single line div or a single term span, it won't do the healing. If one of the CSS pseudo selectors worked for these kinds of elements (I see there are a lot that apply to forms, but.. maybe :active / :active-within would work for editable spans?), you could have healing automatically apply to terms when they 'blur' / when they're no longer active.
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
Probably because if you care about typography, you care about design and you crafted that demo page with passion, instead of picking a free template with 3 columns adorned by free icons of rockets, gears and brains.
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). :)
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.
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).
If two character combination breaking the grid is acceptable then is three character combos ok too? What about four characters, or twenty? Where do you draw the line?
I draw the line at spaces, usually, because functionally there are usually spaces around where I care to have alignment.
But also, since I'm writing a character stream, I care about being able to see it as a monotonic stream of distinct characters (which is why I hate hate hate ligatures for e.g. "!=") and moving characters a tiny bit doesn't break that.
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.)
I agree with that many present tools expect character grid, but moving away from character grid would be not as much work as it seems IMO.
Code can be aligned with elastic tabstops ( https://nickgravgaard.com/elastic-tabstops/ ) or virtual formatting (that things are aligned according to syntax regardless of whitespace).
Things to align in terminals are mostly tables, and they could be rendered as tables if the terminal supporting that knew that they are tables. Nushell natively supports tabular data structures, so rendering them as proper tables would need just one change – the table renderer.
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.
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...
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.
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).
To expand on this, Emacs uses a system called "faces" to draw different textual elements, for example font-lock-comment-face to draw comments. Faces can have different attributes, like font family, foreground colour, background colour, having a box around it,...
So if I want to use a variable pitch font (like say... DejaVu Sans) to draw comments, I can set the font-lock-comment-face to use the "DejaVu Sans" family.
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'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!
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.
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".
More like, asking a mathematician to become enough of a typographer to design a font that looks clean and consistent and actually aids reading is too much.
Real typographers know that the Computer Modern family is garbage.
Who are these typographers, any examples? Considering:
• The design of Computer Modern was based on Monotype Modern 8A, which was made by a "real typographer" for Monotype corporation and used for decades in several textbooks by Addison-Wesley, including the first editions of TAOCP volumes 1–3 (and 2nd ed of vol 1).
• Knuth got close feedback on the font specimens at various steps of the process (and incorporated the suggestions) from many of the world's top font designers, in particular Hermann Zapf, Matthew Carter, Richard Southall, Charles Bigelow and Kris Holmes, who between them are behind such typefaces as Palatino, Optima, Verdana, Georgia, and Lucida. (Zapf and Southall visited Knuth at Stanford and spent weeks working closely with him on the fonts.) I imagine they wouldn't have spent so much time on it if they thought it was "garbage".
• Of course, Computer Modern, and Monotype Modern before it, are (intentionally) boring "workhorse" fonts for textbooks and won't win any points for being stylish or novel or a work of typographic genius — but within that category, CM is AFAICT something close to the best possible rendering of the basic design, very far from "garbage". I'm curious who thinks otherwise. (I've read a few reviews from typographers and no one said the font was bad; one I remember praised the even "texture" of the page, though that was more a result of TeX's Knuth–Plass line-breaking rather than the font itself.)
• (There is also a well-known issue with CM's appearance on low-resolution devices like computer screens rather than print, and especially the "spindly" appearance of the vector font that usually ends up getting used today if one asks for Computer Modern—see my answer at https://tex.stackexchange.com/a/361722 and links in the comments on it—but those have nothing to do with Knuth's design; in fact Knuth personally still uses the Metafont-generated bitmap fonts unlike everyone else. And there are now "newcomputermodern" and "mlmodern" to remedy this.)
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.
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 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.
> 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.
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 [].
At some point you'll just have to accept that not everyone has the exact same tastes as you. Initially it was "don't force ligatures on me I want to be left alone", now it's "other people are forbidden from using ligatures because I might be forced to gasp glance at one in a video". Grow up!
A paragraph from a draft I wrote a couple of years ago (which I should probably finish off and publish):
> Here’s a concrete example of the mess that it is: <https://www.youtube.com/watch?v=OSgIEDMekSg&t=157>. He says, “so we can write an if statement, so we can say ‘if want is not equal to got’”, with the character `!` briefly visible on screen, then a ≠. Fortunately he was aware enough to put text over the video “I’m using the ‘Fira Code’ font, which shows ‘!=’ in this neat way. Try it!”, so the beginner (since this is designed for beginners) at least gets some hint—but I bet that more than a few will forget and find it difficult to figure out what it is again, and anyone that’s skimming may just miss that part altogether.
In education material in particular, coding ligatures are emphatically not OK. How on earth is the user supposed to figure out that that wide ≠ is actually typed !=? So you’re putting a stumbling-block in their path.
Fun fact: the King James Version of the Bible uses “:)” 37 times (e.g. Matthew 24:15) and “;)” 53 times (e.g. Deuteronomy 4:31).
I’ve had auto-emojification of character sequences like :) cause problems on more than one occasion, e.g. in things like copying logs and getting them mangled. I strongly oppose those sorts of transformations being applied willy-nilly. Converting :) into U+1F642 or similar at authoring time is OK, so long as I can turn it off, but doing it blindly causes enough problems and helps little enough that it just shouldn’t be done any more, not when most devices have ready access to actual emoji input.
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.
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.
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
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.
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).
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.
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.
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.
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 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.
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.
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
205 comments
[ 5.9 ms ] story [ 276 ms ] threadOne 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.
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.
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.
[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.
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?
The text editor widget on their page is a bunch of "line" divs with individual terms being inside spans. If you add an inline style of
or, more completely, to a single line div or a single term span, it won't do the healing. If one of the CSS pseudo selectors worked for these kinds of elements (I see there are a lot that apply to forms, but.. maybe :active / :active-within would work for editable spans?), you could have healing automatically apply to terms when they 'blur' / when they're no longer active.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). :)
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 might be ok but there is a reason why type designers make every character to be the same and try to balance everything including spacing.
Monospaced fonts designs are dictated exactly by that limit of fixed character+fixed space.
But maybe the “healing” might not be verydistracting.
But this was designed by type designers. So you can make exactly the same argument about texture healing.
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).
But also, since I'm writing a character stream, I care about being able to see it as a monotonic stream of distinct characters (which is why I hate hate hate ligatures for e.g. "!=") and moving characters a tiny bit doesn't break that.
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.)
Code can be aligned with elastic tabstops ( https://nickgravgaard.com/elastic-tabstops/ ) or virtual formatting (that things are aligned according to syntax regardless of whitespace).
Things to align in terminals are mostly tables, and they could be rendered as tables if the terminal supporting that knew that they are tables. Nushell natively supports tabular data structures, so rendering them as proper tables would need just one change – the table renderer.
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.
Other editors/terminal emulators would probably need to add support for this.
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.
Emacs and Vim have both supported this since at least last century.
So if I want to use a variable pitch font (like say... DejaVu Sans) to draw comments, I can set the font-lock-comment-face to use the "DejaVu Sans" family.
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.
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.
[0] https://rubjo.github.io/victor-mono/
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.
those other variants are not nearly different enough to really convey information.
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.
Real typographers know that the Computer Modern family is garbage.
• The design of Computer Modern was based on Monotype Modern 8A, which was made by a "real typographer" for Monotype corporation and used for decades in several textbooks by Addison-Wesley, including the first editions of TAOCP volumes 1–3 (and 2nd ed of vol 1).
• Knuth got close feedback on the font specimens at various steps of the process (and incorporated the suggestions) from many of the world's top font designers, in particular Hermann Zapf, Matthew Carter, Richard Southall, Charles Bigelow and Kris Holmes, who between them are behind such typefaces as Palatino, Optima, Verdana, Georgia, and Lucida. (Zapf and Southall visited Knuth at Stanford and spent weeks working closely with him on the fonts.) I imagine they wouldn't have spent so much time on it if they thought it was "garbage".
• Of course, Computer Modern, and Monotype Modern before it, are (intentionally) boring "workhorse" fonts for textbooks and won't win any points for being stylish or novel or a work of typographic genius — but within that category, CM is AFAICT something close to the best possible rendering of the basic design, very far from "garbage". I'm curious who thinks otherwise. (I've read a few reviews from typographers and no one said the font was bad; one I remember praised the even "texture" of the page, though that was more a result of TeX's Knuth–Plass line-breaking rather than the font itself.)
• (There is also a well-known issue with CM's appearance on low-resolution devices like computer screens rather than print, and especially the "spindly" appearance of the vector font that usually ends up getting used today if one asks for Computer Modern—see my answer at https://tex.stackexchange.com/a/361722 and links in the comments on it—but those have nothing to do with Knuth's design; in fact Knuth personally still uses the Metafont-generated bitmap fonts unlike everyone else. And there are now "newcomputermodern" and "mlmodern" to remedy this.)
for anyone unaware, Marvin Gaye - Sexual Healing https://youtu.be/fn4i8bAfnMY
blah
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.
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.
[0]: https://github.com/tonsky/FiraCode
- native language
- mathematically or symbolically oriented
- etc.
I personally find them imminently readable and use with Fira Code font.
Even to my aesthetically un-nuanced sensitivity, these fonts look good
!= 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/
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.
> Here’s a concrete example of the mess that it is: <https://www.youtube.com/watch?v=OSgIEDMekSg&t=157>. He says, “so we can write an if statement, so we can say ‘if want is not equal to got’”, with the character `!` briefly visible on screen, then a ≠. Fortunately he was aware enough to put text over the video “I’m using the ‘Fira Code’ font, which shows ‘!=’ in this neat way. Try it!”, so the beginner (since this is designed for beginners) at least gets some hint—but I bet that more than a few will forget and find it difficult to figure out what it is again, and anyone that’s skimming may just miss that part altogether.
In education material in particular, coding ligatures are emphatically not OK. How on earth is the user supposed to figure out that that wide ≠ is actually typed !=? So you’re putting a stumbling-block in their path.
> Fortunately he was aware enough to put text over the video “I’m using the ‘Fira Code’ font, which shows ‘!=’ in this neat way. Try it!”
It's not a difficult concept. Nobody gets confused if :) is displayed as an emoji.
—⁂—
Fun fact: the King James Version of the Bible uses “:)” 37 times (e.g. Matthew 24:15) and “;)” 53 times (e.g. Deuteronomy 4:31).
I’ve had auto-emojification of character sequences like :) cause problems on more than one occasion, e.g. in things like copying logs and getting them mangled. I strongly oppose those sorts of transformations being applied willy-nilly. Converting :) into U+1F642 or similar at authoring time is OK, so long as I can turn it off, but doing it blindly causes enough problems and helps little enough that it just shouldn’t be done any more, not when most devices have ready access to actual emoji input.
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.
In addition to ligatures, you get IMO a better version of the "Mix & Match" idea: doc comments are rendered as normal proportional text.
Another way to fix the inconsistency is for the language designers to get unstuck from the past and allow literal ≠ in code
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.
[0] http://eastfarthing.com/luculent/
[1] https://fontlibrary.org/en/font/luculent (live example in browser)
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.
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 )
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?
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
https://mplusfonts.github.io/
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'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