7 ms·

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 "

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.

vinberdon 3y ago
Yeah... I hate this. Solves a "problem" for someone with a different type of OCD than mine.
- jay_kyburz 3y ago
  This is a solution looking for a problem.
cosmotic 3y ago
This is going to make a lot of brains itch.
- andix 3y ago
  My brain seems to scan for differences to familiar patterns. For code that just doesn't look right. When I see stuff like this, it feels like finding a bug/typo. So a lot of false alarms. Maybe my brain would adjust after a while. And maybe I'm also different to other people. I think my reading skills are a bit skewed towards recognizing words/patterns instead of reading characters (probably some form of compensation for my dyslexia).
mortenjorck 3y ago
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 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.
- tobr 3y ago
  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 3y ago
    [deleted]
  - Stratoscope 3y ago
    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.
    - deleted 3y ago
crazygringo 3y ago
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.
- gwern 3y ago
  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 https://www.coderelay.io/fontemon.html you know the sky is the limit for what the rewrites can do!
  - crazygringo 3y ago
    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).
    - galaxyLogic 3y ago
      > 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?
    - eternityforest 3y ago
      What about distributing the space amount more that one letter, and ensuring no two of the same letter are ever different. You'd allow things to get out of sync and not be on a perfect grid, so long as you could align everything at key points where a line has the same character on two successive lines, or some other case where you know you need alignment. Everything else would just look like a proportional font. Maybe it would influence coders too much and subconsciously make them choose names that line up well though...

vinberdon 3y ago

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

jay_kyburz 3y ago
This is a solution looking for a problem.

cosmotic 3y ago

This is going to make a lot of brains itch.

andix 3y ago
My brain seems to scan for differences to familiar patterns. For code that just doesn't look right. When I see stuff like this, it feels like finding a bug/typo. So a lot of false alarms. Maybe my brain would adjust after a while. And maybe I'm also different to other people. I think my reading skills are a bit skewed towards recognizing words/patterns instead of reading characters (probably some form of compensation for my dyslexia).

mortenjorck 3y ago

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

tobr 3y ago
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 3y ago
  [deleted]
- Stratoscope 3y ago
  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.
  - deleted 3y ago

crazygringo 3y ago

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.

gwern 3y ago
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 https://www.coderelay.io/fontemon.html you know the sky is the limit for what the rewrites can do!
- crazygringo 3y ago
  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).
  - galaxyLogic 3y ago
    > 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?
  - eternityforest 3y ago
    What about distributing the space amount more that one letter, and ensuring no two of the same letter are ever different. You'd allow things to get out of sync and not be on a perfect grid, so long as you could align everything at key points where a line has the same character on two successive lines, or some other case where you know you need alignment. Everything else would just look like a proportional font. Maybe it would influence coders too much and subconsciously make them choose names that line up well though...