[HN Gopher] Texture Healing for Monospace Fonts
       ___________________________________________________________________
        
       Texture Healing for Monospace Fonts
        
       Author : notpushkin
       Score  : 93 points
       Date   : 2023-11-10 17:07 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | notpushkin wrote:
       | I'm not sure if the name "Texture Healing" is descriptive enough
       | (perhaps I'm not that much of a typography nerd I think I am!),
       | but I love the idea. Basically it resolves pairs or triplets of
       | monospace letters to make some of them wider when adjacent letter
       | can be made narrower instead.
       | 
       | Another variation on that theme are "duospace fonts", like iA
       | Writer Duo [1]. Those use two character widths instead of one
       | (i.e. wide characters are always 1.5x wider than narrow). I think
       | this could work for code, too.
       | 
       | [1]: https://ia.net/topics/in-search-of-the-perfect-writing-font
        
         | kevin_thibedeau wrote:
         | I'd call it dynamic monospace.
        
         | agalunar wrote:
         | I've never heard "texture" used this way, although that's not
         | saying much. My personal opinion would be that it's not the
         | right word. I have heard the term "color" used in typography to
         | describe the balance of positive and negative space on the page
         | in phrases like "even (or uneven) color". But although that
         | feels closer, it also doesn't feel quite right in this case. It
         | reminds me of the subtle changes in tracking and glyph width
         | that some justification engines perform:
         | 
         | "Most of the type set in the past five hundred years is
         | justified type, and most of it has been justified line by line,
         | by the simple expedient of altering the space between the
         | words. There are, however, better ways. Scribes justify text as
         | they write by introducing abbreviations and subtly altering the
         | widths of letters. Gutenberg replicated the feat by cutting and
         | casting a host of abbreviations and ligatures along with
         | multiple versions of certain letters differing modestly in
         | width. In the early 1990s, Peter Karow and Hermann Zapf devised
         | a means of doing much the same in the digital medium[.] [...]
         | Another thing computer software can do - because Karow taught
         | it how - is justify text by making subtle alterations in the
         | spaces _within_ letters as well as those between letters and
         | words."
         | 
         |  _The Elements of Typographic Style,_ fourth edition, by Robert
         | Bringhurst, pp 191-192.
        
           | dwringer wrote:
           | I think "texture" makes sense, if only by analogy to the
           | calligraphic hand Textura, or the etymological derivation of
           | "text" itself.
        
       | xeonmc wrote:
       | Isn't this just kerning but with extra steps?
        
         | gzalo wrote:
         | With the difference that it keeps the font monospaced (in
         | average), and usually kerning doesnt change shapes
        
         | karaterobot wrote:
         | It looks like it's also switching between variants of the same
         | letter which are different widths, not just varying the space
         | between characters.
        
         | Dwedit wrote:
         | Monospaced Kerning would be a better name than "Texture
         | Healing".
        
       | starkparker wrote:
       | 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 wrote:
         | Yeah... I hate this. Solves a "problem" for someone with a
         | different type of OCD than mine.
        
           | jay_kyburz wrote:
           | This is a solution looking for a problem.
        
         | cosmotic wrote:
         | This is going to make a lot of brains itch.
        
           | andix wrote:
           | 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 wrote:
         | 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.
        
           | tobr wrote:
           | 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.
        
       | graypegg wrote:
       | The thing I'm curious to see is this font feature being used
       | while typing. I feel like the characters kind of "jiggling"
       | behind your cursor as you type is going to be kind of weird, no?
        
         | mistercow wrote:
         | From testing out the monaspace fonts, it's really not very
         | noticeable. It only affects one character back, and they only
         | do it for the really egregious cases, so during normal typing,
         | you barely see it happening. That's similar to normal ligatures
         | e.g. ffi, where you typically don't notice the swap.
        
         | topspin wrote:
         | We're at a point where the places that monospace prevails (code
         | editors, obviously) have been festooned with so many other
         | visual intrusions while typing that that additional jank the
         | jiggling adds will be lost in the noise.
        
         | ReleaseCandidat wrote:
         | You see a bit of movement when writing "mimimimimi..." I don't
         | know if I would have noticed that during "normal" editing.
         | 
         | But I don't like the font, so no real tests ;)
        
       | kstrauser wrote:
       | I feel like this would drive me nuts when dealing with code,
       | CSVs, or other kinds of data I'd commonly be viewing with a mono
       | font. Two adjacent rows nearly identical rows might look more
       | different than they really are, say because an "im" changed to an
       | "wm" and the "m" is moving around.
       | 
       | That's not to say it's bad at all, just that I think it wouldn't
       | be right for how I'd mostly likely be using such a font.
        
       | mewse-hn wrote:
       | I don't like how this article has no examples with a terminal
       | window or a code window where monospace gives a nice grid layout
       | to the text
        
         | ReleaseCandidat wrote:
         | The actual website has an (interactive) editor window:
         | https://monaspace.githubnext.com/
        
       | ChrisArchitect wrote:
       | Related:
       | 
       | Might as well be in this thread on the Monaspace fonts
       | https://news.ycombinator.com/item?id=38210574
        
       | taosx wrote:
       | Tried it but honestly I like Iosevka too much. I love to split my
       | code into-multiple side-by-side windows and Iosevka is perfect.
        
       | BaculumMeumEst wrote:
       | this looks really nice except 0's often look super weirdly fat
       | and out of place
        
       | devit wrote:
       | It seems to me the problem with that font is that the strokes are
       | way too thick, making the "m" look like it's almost all ink, and
       | it also seems that the lowercase characters are far too tall for
       | their width.
       | 
       | If you use a normal stroke width (one that makes the empty space
       | in the "m" as wide as the stroke) and width/height ratio for all
       | characters, the problem naturally disappears, and in fact this is
       | not a problem for instance in Linux terminals with the default
       | fonts (normally DejaVu Sans Mono), where the characters look
       | perfectly natural and fine.
        
       | andix wrote:
       | 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
       | weird.
        
         | eichin wrote:
         | 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...)
        
       | Hansenq wrote:
       | 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).
       | 
       | https://input.djr.com/info/
        
         | Kuinox wrote:
         | Monospace can be parameterized, you can just make the font
         | weight larger.
        
       | hawski wrote:
       | It is impressive and interesting, but I would suggest just using
       | proportional fonts and stop caring about alignment.
        
         | dkarras wrote:
         | >and stop caring about alignment.
         | 
         | absolutely impossible for me, so perhaps it has a use for
         | likeminded folks.
        
       | beeforpork wrote:
       | 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 interfere with that
       | grid. Instead, stupidly simple letter placement will be what I
       | want.
       | 
       | I have an idea for an advanced technique that yields much better
       | visual appearance (but that is also not want you'd want, for the
       | same reasons): instead of just focussing on pairs of letters (so
       | primitive!), consider whole words and optimise their letters'
       | shape, width, and horizontal position, but keep the size of box
       | of the word. I call that 'equilibrium texture healing'.
        
       | TheCleric wrote:
       | Should have used the name "Textual Healing".
        
       | naet wrote:
       | 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.
        
       | virtualritz wrote:
       | 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 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 possible
       | 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).
        
       ___________________________________________________________________
       (page generated 2023-11-10 23:00 UTC)