Comment by turnsout
2 years ago
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.
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.
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
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 it's good for reading, it's especially good for Github itself, which is a largely read-only interface for code.
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).
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?
1 reply →
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.)
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.
Yet the most popular editor is vscode which is browser based and has all the rendering tech just sitting there, largely unused.
2 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
Its ok but instead of uneven spacing you get uneven character widths.
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.
1 reply →
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.