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

81–90 of 103 posts

Re: Texture Healing for Monospace Fonts

#81

Post by seanhunter »

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!

It's a fundamentally bad idea. I think for anything to look monospace for me the following two properties are non-negotiable.

1) Horizontal spacing needs to align vertically between glyphs of the same letters on separate lines. This is the example I give elsewhere of a letter "i" being in a very slightly different position than the same letter just two lines above it. I personally find this extremely disturbing and unpleasant to look at in monospace.

2) The glyph of a letter needs to be the exact same between instances of the same letter that are in any kind of visual proximity. This is the "gimme" example the parent of your comment gives. AnyThinG ElSe LoOkS lIkE jumblycase. Which I think we can all agree is just plain horrible.

Re: Texture Healing for Monospace Fonts

#82

Post by deaddodo »

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…

After seeing it in a larger context like that, I'm even more in agreement with OP. The weirdly random letter alignment screws with my brain much more than I thought from just the localized examples in the topic link.

I'll stick to the consistent design for a slightly less aesthetic experience for that reason alone.

Re: Texture Healing for Monospace Fonts

#83

Post by deaddodo »

virtualritz wrote: post #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 lapto…

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

Their own examples literally show that this isn't the case. Just look at the "filming" example, with the "m". In addition, their five fonts showcase shows that letters that "need space" can overbound.

I think it's accurate to say that a word respects it's bounding box, but interior glyphs don't necessarily. Unless their own examples are somehow misrepresentative.

Re: Texture Healing for Monospace Fonts

#84

Post by ReleaseCandidat »

jval43 wrote: post #78
sublinear wrote: post #44

Earlier quoted context omitted.

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

Ligatures are great if done right. E.g. the set in Fira Code gives me a 2 character wide ≠ instead of != so it retains the monospace widths.

All "coding" ligatures in all monospace fonts work like that.

Re: Texture Healing for Monospace Fonts

#86

Post by sublinear »

pikelet wrote: post #68
sublinear wrote: post #44

Earlier quoted context omitted.

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

Please stop diluting words like objectively for things that you just feel strongly about.

I suppose you've never dealt with encoding issues. Encoding issues are very common, funnily enough, when you're writing code meant to handle display text. Not just web pages, but even native apps that must support almost any language that isn't English. Not all work is lighthearted when it comes to fixing these mistakes, nor is the testing reliable. Accessibility is a huge deal and can bring about lawsuits. Really, it even has security implications. If one is this sloppy about fonts I doubt there's much validation going on elsewhere, yet injection attacks should be trivial to mitigate. Why overcomplicate this? No mere font in your editor is going to distinguish between the string literals for the user and the rest of the code being displayed to the programmer.

I'm not misusing these words for hyperbole. We're talking about text. Words like "literal" and "objective" belong here. At this stage of the game, few subjective decisions are left to tinker with in programming. I'm sorry if that sort of thing brings you joy. Get another hobby.

It's objectively bad to alter the visual presentation of font glyphs for non-functional purposes. If a programmer sees the same glyph with varying width, they have to wonder if it's the same underlying character. If a ligature is applied, they have to wonder if it's the same character being displayed. That's a huge waste of time for little to no benefit. We are very far away from these concerns being a thing of the past. The cognitive load must still sometimes fall back on human inspection. A cute font shouldn't prevent you from doing that, nor should anyone need to break out the hex editor to be sure. This simple knowledge cannot die off into obscurity yet.

If y'all want pretty code it must be done at the text encoding and compiler level (invent a new keyboard layout while you're at it!), not in the fonts... but that too would just repeat the sins of the past. :)

Re: Texture Healing for Monospace Fonts

#87

Post by virtualritz »

deaddodo wrote: post #83
virtualritz wrote: post #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 lapto…

> 1. The grid is not affected. The resp. letters stay within their grid-aligned bounding boxes. Their own examples literally show that this isn't the case. Just look at the "filming" example, with the "m". In addition, their five fonts showcase shows that letters that "need space" can overbound. I think it's accurate to say that a word respects it's bounding box, but interior glyphs don't necessarily. Unless their ow…

> Their own examples literally show that this isn't the case. Just look at the "filming" example, with the "m". In addition, their five fonts showcase shows that letters that "need space" can overbound.

They don't, it's an optical illusion. That's the whole point. Read the whole text and/or open the example images which show the different versions of 'm' and 'i' side by side and measure their bounding boxes. Or open the fonts in a font editor.

They have all the same width.

Think about the implications if what you said were true. The font (or typeset engine) can't know how many pairs or triplets of these special case letter combos are in a word or a line. So you can't make sure a word stays the same width. It's impossible. There is no 'lookahead' the font designer can use to ensure this.

The only option really, to respect the grid, is staying inside equally spaced bounding boxes that are the core property of a monospaced font.

Re: Texture Healing for Monospace Fonts

#88

Post by [deleted] »

adastra22 wrote: post #59
Stratoscope wrote: post #50

Earlier quoted context omitted.

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.

[deleted]

Re: Texture Healing for Monospace Fonts

#89

Post by alex-moon »

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…

For me it's not about lining things up in columns as much as it is about column widths. So, for example, hitting up or down, I know which character the cursor is going to go to (which means I can string keypresses together and do them in a fluid movement). Putting in a hard limit for line lengths (which is very important to me, I know opinions on this differ) means that limit can be drawn as a literal line on the UI (which in turn means I know how small I can resize the editor pane to be). Similar lines with slightly different values (e.g. 'x', 'y' and 'z') will line up so the different values are underneath each other everywhere they appear in the line (also those lines will be the same length which reassures me those lines are the same outside the variables/values).
Post reply on HN