Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Texture Healing for Monospace Fonts

github.com

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Texture Healing for Monospace Fonts

#51

Post by crazygringo »

starkparker wrote: post #4

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.

Yup, I unfortunately have to agree. It's a cool idea, but when I type "gimme" in the editor, the two adjacent m's are different widths, and it looks sooo wrong.

Interestingly enough, the fact that letterforms change as I type doesn't bother me the way I thought it would -- turns out I'm already kinda used to it from ligatures.

So points for being a clever idea to try out, but unfortunately what it does to a word like "gimme" just makes it a non-starter. Let's face it -- lowercase m's in monospace will always be ugly and cramped, but at least they're consistently so.

Re: Texture Healing for Monospace Fonts

#52

Post by gwern »

crazygringo wrote: post #51
starkparker wrote: post #4

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.

Yup, I unfortunately have to agree. It's a cool idea, but when I type "gimme" in the editor, the two adjacent m's are different widths, and it looks sooo wrong. Interestingly enough, the fact that letterforms change as I type doesn't bother me the way I thought it would -- turns out I'm already kinda used to it from ligatures. So points for being a clever idea to try out, but unfortunately what it does to a word like…

But is this a fundamentally bad idea, or is it, like kerning in general (which can require thousands of pairs to be defined), something that just needs more work?

It's not like this is limited to just a few pairs of letters like 'mi', or just pairs - if you've seen Fontemon https://www.coderelay.io/fontemon.html you know the sky is the limit for what the rewrites can do!

Re: Texture Healing for Monospace Fonts

#53

Post by [deleted] »

Stratoscope wrote: post #50
tobr wrote: post #34

Earlier quoted context omitted.

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

[deleted]

Re: Texture Healing for Monospace Fonts

#54

Post by crazygringo »

gwern wrote: post #52
crazygringo wrote: post #51

Earlier quoted context omitted.

Yup, I unfortunately have to agree. It's a cool idea, but when I type "gimme" in the editor, the two adjacent m's are different widths, and it looks sooo wrong. Interestingly enough, the fact that letterforms change as I type doesn't bother me the way I thought it would -- turns out I'm already kinda used to it from ligatures. So points for being a clever idea to try out, but unfortunately what it does to a word like…

But is this a fundamentally bad idea, or is it, like kerning in general (which can require thousands of pairs to be defined), something that just needs more work? It's not like this is limited to just a few pairs of letters like 'mi', or just pairs - if you've seen Fontemon https://www.coderelay.io/fontemon.html you know the sky is the limit for what the rewrites can do!

Specifically for monospace fonts, it's not obvious to me how any further work could fix it.

The same letterform having different widths just looks bad and wrong.

It's not like kerning, which always looks good when done well (for proportional fonts).

Re: Texture Healing for Monospace Fonts

#55

Post by andix »

sublinear wrote: post #44
andix wrote: 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 req…

I get my work done with ligatures. That's fine for me.

Re: Texture Healing for Monospace Fonts

#56

Post by anderskaseorg »

Hansenq wrote: 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…

Input Mono is actually monospace. Input Sans and Input Serif are the ones that aren’t (merely monospace-inspired).

Re: Texture Healing for Monospace Fonts

#57

Post by jrmg »

mortenjorck wrote: post #32
starkparker wrote: post #4

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 can’t help but think that the example in that page has used ‘timing’ so much to deliberately show off texture healing - it’s a great example because the ‘m’ can expand in both directions and the ‘i’s end up looking the same.

I suspect the state where different width variants of the same letter are close to each other would happen a lot more in the real world.

Re: Texture Healing for Monospace Fonts

#59

Post by adastra22 »

Stratoscope wrote: post #50
tobr wrote: post #34

Earlier quoted context omitted.

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

"If you stop doing things which derive benefits from monospaced fonts, then you can get away with a proportional font."

Thanks, but no. Your foo.bar() example is significantly less readable the way Black formats it.

Re: Texture Healing for Monospace Fonts

#60

Post by galaxyLogic »

crazygringo wrote: post #54
gwern wrote: post #52

Earlier quoted context omitted.

But is this a fundamentally bad idea, or is it, like kerning in general (which can require thousands of pairs to be defined), something that just needs more work? It's not like this is limited to just a few pairs of letters like 'mi', or just pairs - if you've seen Fontemon https://www.coderelay.io/fontemon.html you know the sky is the limit for what the rewrites can do!

Specifically for monospace fonts, it's not obvious to me how any further work could fix it. The same letterform having different widths just looks bad and wrong. It's not like kerning, which always looks good when done well (for proportional fonts).

> It's not obvious to me how any further work could fix it.

In "gimme" you could have a rule that when any character is next to itself both occurrences must have the same width. Wouldn't that fix the "gimme" example?

Post reply on HN