Live data from Hacker News

Texture Healing for Monospace Fonts

github.com

31–40 of 103 posts

Re: Texture Healing for Monospace Fonts

#32

It bothers way me more that the same glyph can differ within the same word than it satisfies me that the glyphs are very slightly more proportional. The third "m" in the "minimum" example being narrower than the "m"s adjacent to the two "i"s makes my brain itch. Same for the "i"s in "miniature". Makes me feel like I'm looking through a fish-eye lens, or that my glasses prescription is off.

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 in the context of a busy code block, has the effect of smoothing out the visual rhythm of the characters with only a minor disruption of the monospace grid. Perhaps it's not for everyone (it is a trade-off), but I think it's a smart compromise.

Re: Texture Healing for Monospace Fonts

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

Re: Texture Healing for Monospace Fonts

#34

It bothers way me more that the same glyph can differ within the same word than it satisfies me that the glyphs are very slightly more proportional. The third "m" in the "minimum" example being narrower than the "m"s adjacent to the two "i"s makes my brain itch. Same for the "i"s in "miniature". Makes me feel like I'm looking through a fish-eye lens, or that my glasses prescription is off.

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

#35

It bothers way me more that the same glyph can differ within the same word than it satisfies me that the glyphs are very slightly more proportional. The third "m" in the "minimum" example being narrower than the "m"s adjacent to the two "i"s makes my brain itch. Same for the "i"s in "miniature". Makes me feel like I'm looking through a fish-eye lens, or that my glasses prescription is off.

Yeah... I hate this. Solves a "problem" for someone with a different type of OCD than mine.

This is a solution looking for a problem.

Re: Texture Healing for Monospace Fonts

#36
This is great as it improves glyph/bg contrast when possible (i.e. readability of individual glyphs) and it makes the text's texture look more uniform (hence the name).

Things people here seem to misunderstand:

1. The grid is not affected. The resp. letters stay within their grid-aligned bounding boxes.

2. Letters may change while you type but this is not noticeable in practice. I have a 3.2x2k 15" screen on my laptop. At my editor's effective font size of around 20px (capital letters, from baseline to top) the change in shape is about a pixel for something like the letter 'm'.

Caveat: I'm an ex-typographer. As such I not only do care way more about these things than the average engineer. I'm also more aware that these things do have an effect on eye/brain/visual system strain that is possibly very hard to quantify.

But legibility of a text is a thing. And the font with its properties is one very important factor (font width/kerning/line height are equally important in that regard -- nevertheless).

Edit: typos

Re: Texture Healing for Monospace Fonts

#38
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…

Huh, on a linux desktop the "own voice" example just seems to change height and weight and nothing else. (Still horrible, but it just looks like it's "breathing".) On mobile (android chrome), it looked like it was changing in more dimensions, I'd almost call it "writhing". I hope "reduced animation" turns this kind of thing off (but I couldn't find the setting in chrome at a quick look...)

Re: Texture Healing for Monospace Fonts

#39
post #25

I tried out Monaspace but felt that the fonts were a bit thin for my QHD monitor I use as my primary display. It might be better on a retina/4k monitor though. Perhaps fonts are something you get used to after some time using it, but I ended up switching back to my favorite font, Input Mono (which, as a coding font, isn't actually monospace, so it brings a bunch of cool features and doesn't need to do texture healing…

Good tip! I might try this variable width idea. Seems a bit out there.

Re: Texture Healing for Monospace Fonts

#40

This is great as it improves glyph/bg contrast when possible (i.e. readability of individual glyphs) and it makes the text's texture look more uniform (hence the name). Things people here seem to misunderstand: 1. The grid is not affected. The resp. letters stay within their grid-aligned bounding boxes. 2. Letters may change while you type but this is not noticeable in practice. I have a 3.2x2k 15" screen on my lapto…

[deleted]
Post reply on HN