Hmm -- I do not understand what is the use case for this. For best design, clearly, I'd use a proportional font. So whenever I want a monospace font, there are reasons that exclude proportional fonts. An obvious reason would be a grid that the letters need to be arranged in (for whatever reason). But then, I can only imagine that any smart rearrangement of letters out of their grid box will be unwanted, because it in…
Texture Healing for Monospace Fonts
41–50 of 103 posts
Re: Texture Healing for Monospace Fonts
#42Hmm -- I do not understand what is the use case for this. For best design, clearly, I'd use a proportional font. So whenever I want a monospace font, there are reasons that exclude proportional fonts. An obvious reason would be a grid that the letters need to be arranged in (for whatever reason). But then, I can only imagine that any smart rearrangement of letters out of their grid box will be unwanted, because it in…
In this technique the letters do not leave their grid box. A wide letter next to a narrow letter will at most push hard up against the edge of its box (usually there has to be white space there so that, e.g. mm doesn’t become one glyph)
Is that just a poorly drawn/incorrect example graphic?
[0] https://github.com/githubnext/monaspace/blob/main/docs/Textu...
Re: Texture Healing for Monospace Fonts
#43Earlier quoted context omitted.
I think this all makes a lot more sense when seen in a practical context rather than the blown-up examples in the feature documentation. Take a look at the code editor examples on the main site for Github Monaspace: https://monaspace.githubnext.com Scroll down to the "Five Fonts" section and try unchecking the texture healing toggle. The fisheye effect you get when looking at the font in 200pt goes away at 16pt, and…
I think this is a fun innovation and I might try to use it in my terminal, but for coding, the real solution should be obvious: use a proportional font.
Re: Texture Healing for Monospace Fonts
#44Tried it here: https://monaspace.githubnext.com/ It might be nice for reading code, but for editing code it feels weird that glyphs change their size while you type. Also readability wise I'm not convinced. In the example there is a combination like "_m_", in this case the lette m is much nicer to read. But then i typed "mml", which makes the two m's very different looking. Also the line number 10 on top of 11 looks…
Applying display typography techniques to code is an objectively bad idea for both reading and writing.
They even enable ligatures by default on the demo which is far worse. For those of us who actually have to get work done and not just fetishize code and fawn over aesthetics, it's a fundamental requirement that every single character be as unambiguous and consistent as possible.
Re: Texture Healing for Monospace Fonts
#45Re: Texture Healing for Monospace Fonts
#46Seeing the exact same character in a single word having two different sizes is way more infuriating to me than a classic monospaced font having "wide" i and "narrow" m. Maybe I'd get used to it over time but right now my eyes get hung up on the differences.
Re: Texture Healing for Monospace Fonts
#47Hmm -- I do not understand what is the use case for this. For best design, clearly, I'd use a proportional font. So whenever I want a monospace font, there are reasons that exclude proportional fonts. An obvious reason would be a grid that the letters need to be arranged in (for whatever reason). But then, I can only imagine that any smart rearrangement of letters out of their grid box will be unwanted, because it in…
Perceptually, based only on playing with it a minute, it seems to improve legibility a bit (but not as much as a proportional font would be) but also visually breaks the alignment a little sometimes.
Not sure it's a worthwhile overall, but interesting.
Re: Texture Healing for Monospace Fonts
#48Re: Texture Healing for Monospace Fonts
#49Isn't this just kerning but with extra steps?
Re: Texture Healing for Monospace Fonts
#50Earlier quoted context omitted.
I think this all makes a lot more sense when seen in a practical context rather than the blown-up examples in the feature documentation. Take a look at the code editor examples on the main site for Github Monaspace: https://monaspace.githubnext.com Scroll down to the "Five Fonts" section and try unchecking the texture healing toggle. The fisheye effect you get when looking at the font in 200pt goes away at 16pt, and…
I think this is a fun innovation and I might try to use it in my terminal, but for coding, the real solution should be obvious: use a proportional font.
One question people sometimes ask is, "How can you code in a proportional font? How do you line things up in columns?"
The answer is you don't. For example, the Black code formatter for Python completely eschews column alignment of this sort:
foo.bar(one,
two,
three)
(Imagine that the words were long enough that the whole thing wouldn't fit on one line.)Instead, Black formats it like this:
foo.bar(
one,
two,
three
)
No column alignment, only indentation. Code formatted like this is equally readable in a proportional or monospaced font. You don't need monospaced fonts!I've read and written all my code in proportional fonts for close to 20 years. My current one is Trebuchet++, a variant of Trebuchet MS that I customized in FontForge.
Trebuchet MS is pretty good on its own. For example, all of the "confusable" glyphs are easy to distinguish. And it renders very nicely on a high-DPI display.
Its tilde is pretty bad, though. It's tiny and almost looks like a hyphen. So that was the first thing I fixed, putting in a better tilde.
Then I experimented with spacing for the _ and . glyphs. I added negative margin on both sides of the _, while keeping its width. And I added positive spacing on both sides of the . glyph. Consider code like this:
snake_case_name.another_snaky_name()
These spacing changes have the affect of pulling the individual words in each name closer together, while increasing the separation between the two names.
It is subtle, but to my eye it helps readability.
Next up will be to add some positive margin inside the three pairs of brackety things: (), [], {}. I have always found that it helps readability to add a space inside parens and such, but most contemporary code formatters prohibit this. With a proportional font I can tweak the font to put some visual spacing there.