Live data from Hacker News

Texture Healing for Monospace Fonts

github.com

41–50 of 103 posts

Re: Texture Healing for Monospace Fonts

#41

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…

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)

Re: Texture Healing for Monospace Fonts

#42

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…

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)

The text states that, but then in the Healing Examples section [0], the "m" in "filming" clearly spills over its left border line.

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

#43
post #34

Earlier 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.

[deleted]

Re: Texture Healing for Monospace Fonts

#44
post #23

Tried 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…

> It might be nice for reading code, but for editing code it feels weird that glyphs change their size while you type.

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

#45
The value here is to improve legibility of body copy, e.g. code, not headlines, where optical spacing rules change, so the example choice is odd. This definitely makes sense for programming, I would like to see this in Jet Brains Mono.

Re: Texture Healing for Monospace Fonts

#46
post #33

Seeing 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.

This is how I feel about English language where every 'e' in Mercedes is different.

Re: Texture Healing for Monospace Fonts

#47

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…

It seems to be a weird mix of half-assed kerning and scaling mixed together.

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

#49
post #3

Isn't this just kerning but with extra steps?

It's more partial or constrained kerning (you can't leave your "box"), and then on top of that glyphs are being scaled at the same time to take up space "left over". In a proportional font it would just be kerned and the overall "footprint" changes.

Re: Texture Healing for Monospace Fonts

#50
post #34

Earlier 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.

This seems to be an unpopular opinion, but proportional fonts are great.

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.

Post reply on HN