Block characters are too tall

[SamusAranX]

...at least in iTerm 2 and Terminal.app, which are the only ligature-supporting, frequently-used apps that I have.

Fira Mono has the same problem, but this repo seems to be a little more active, so I'm opening the issue here.

[tonsky]

Thanks for reporting this! I’ll see what I can do. Wouldn’t they make vertical gaps if I make them shorter though?

[SamusAranX]

If Apple's font designers don't have to worry about multiple lines of block chars having vertical gaps, you shouldn't have to, either.
Let's take a look at █ U+2588 FULL BLOCK, repeated a bunch of times with different Apple-made fonts:

Monaco, by Apple (ew gross)

Menlo, by Apple (thoroughly okay)

SF Mono, by Apple (still good, imho. also in active development, this is what it looks like in macOS 10.12.5)

Fira Code (nice, but a bit too tall)

[jmcs]

I read FULL BLOCK as really being full vertical height (the keyword here being full). Apple Designers are not gods and their word is not gospel.

[ctongfei]

Yes, this influences the visual effects of progressbars using unicode block symbols.

[YaLTeR]

The same can be seen on the vertical line │. They are actually so tall they visibly overlap which doesn't look good. Look for the small bolder pieces where the stacked vertical lines join. Test file:

 ╭──
 │
 │
 │
 ╰──
     █
│││││││█
  UO █ 

Screenshots from otf-fira-code-git from commit 7a5965a:

• pango-view:
  
• Alacritty:
  
  
• Firefox Nightly:
  
  
• gucharmap:
  

When combined with full blocks to draw TUI the overlap is extremely noticable:

[tonsky]

Last time I looked into this it seemed different terminals/editors used different means to calculate font width. Also, some users (me included) intentionally increase line height for better readability. But I agree that overlapping lines look kind of ugly. Maybe it’s worth another look

[tonsky]

Interesting problem. So if I make box-drawing characters go up/down exactly to font metrics, it’s slightly not enough. I suspect that’s because editors have to round font metrics to non-fractional amount of pixels and that’s always slightly more than font metrics suggest.

This is Sublime Text 3 on macOS with Fira Code Retina 13px. Parens on the left were adjusted to not go outside font metrics. Parens on the right have previous behaviour (they overlap by quite a lot, and you can see it as @YaLTeR mentioned)

Another issue is that e.g. VS Code computes font height differently for some reason:

Same font, same size, but gaps are bigger!

So I’m afraid, sadly, there’s no right answer :( You either commit to gaps or have overlaps that render not that great at all.

[YaLTeR]

There's an argument to be made here that if the editors are rendering full blocks with gaps then it's an issue of the respective editors and should be fixed on that side. I personally think that characters out in TUIs is a worse issue (and in this case I'm afraid the font gets the blame because the characters are indeed too large).

Could you upload a test version with correct full blocks so I could check how it looks in my applications?

[tonsky]

@YaLTeR and everyone interested: please try those https://github.com/tonsky/FiraCode/tree/b32369cb03ad3c0fe43fd30fd19427169e9592dc/distr/otf

I removed the overlap on full blocks and the rest of Block elements since it’s often used in progress-bar etc. I left overlap in the Box Drawing block as those are rarely used on their own, I think it looks worse without the overlap and removing overlap would make text-based UIs look worse.

I slightly tuned UPM (2000->1950) so that Fira Code 13px would match pixel grid perfectly.

Let me know what you think.

[YaLTeR]

It's nice to see perfect alignment on full blocks! 👍

However all of the TUI overlaps are still present because they are caused by the box drawing characters being too long. :/

[tonsky]

However all of the TUI overlaps are still present because they are caused by the box drawing characters being too long. :/

Yes but you are not supposed to use them like this are you? If you want to end the line midway there are glyphs for that too, e.g. https://unicode-table.com/en/2575/

[YaLTeR]

Hmm, maybe you're right. I can't find anything that says that these lines are intended to "connect" to full blocks without overlap. So my only remaining argument is the presence of those kind-of visible overlaps with other lines.

[blahgeek]

Thanks for the good work. But in my personal opinion, the new | seems too tall in normal code. Now the || is way taller than &&, which seems inconsistent. Also, some related ligatures is inconsistent to this taller |, like |=

---

EDIT: I'm talking about the ASCII symbol | (U+007C) instead of the BOX DRAWINGS LIGHT VERTICAL │ (U+2502). In v2.0, the | (U+007C) becomes taller, which I think is a mistake.