Firacode: 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! :+1:

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.