Baseline difference from other OSX applications

• iTerm2 version: Build 3.0.20160717-nightly
• OS version: 10.11.5

The baseline computation algorithm used by iTerm seems to be different from the one used by other OS X applications.

For example with the Source Code Pro font using regular font style at 12 point size, I noticed that the baseline is 2 pixels above the baseline computed by Safari (in general all Webkit based apps), TextEdit and Terminal.app

As a possible/alternative solution it would be cool adding an option to modify the baseline value manually. (just like vertical and horizontal spacing)

I took a quick look at how Terminal.app computes the baseline:

basically the computation is the same as the one used by iTerm if the font family is one of the "known" ones (the only one defined like this is Monaco), if not it also add 0.5 to the descending before subtracting it from the leading. It also uses CGContextSetTextPosition instead of CGContextSetTextMatrix. If I find some time I'll also take a look at the other apps implement it.

I find x86 floating point assembler hard to read, but I gather this is what you're saying:

CGFloat descender = fontIsMonaco ? floorf(self.font.descender) : floorf(self.font.descender) + 0.5;
CGFloat baselineOffset = -(floorf(font.leading) - descender);

I'd be surprised if setting the text position vs matrix would make any difference. Matrix is handy because it has to be done for fake italic, anyway.

Milestone changed to %Feature Complete 3.1

You almost got it:

CGFloat descender = fontIsMonaco ? self.font.descender : (self.font.descender + 0.5);
CGFloat baselineOffset = -(floorf(font.leading) - floorf(descender));

By applying this change to minimumBaselineOffset in my test I obtain exactly the same baseline between Terminal.app and iTerm

Fixed in commit 87c0d059

Status changed to closed

Hi, sorry to bother again but I just wanted to point out that the logic is the opposite as the one implemented in the commit, the extra offset is added if the font name is NOT Monaco. Actually this distinction is only done in Terminal. TextEdit just add 0.5 to every font on the descender. I'm sorry if I wasn't clear.

I don't see any mention of descender in TextEdit. Where did you find that? I believe this is the right thing to do—our descenders have always been a bit off—but I wish I could understand the logic behind this weird function.

Condition inverted in commit 86063909

You can check the implementation in the Appkit framework for the [NSTextView baselineDeltaForCharacterAtIndex:] method. It isn't the same logic as above (it doesn't just add 0.5), it's more complex, but the result are similar to the one obtained by the code above, so I think that Terminal just does an approximation of that logic, and includes special cases for some fonts (like Monaco). As for why this is the logic used, I have no idea, I personally think that this is a case of "it looks better by adding a small offset".

Thanks for doing all that digging. Now if you can figure out how to make text drawing faster in the master branch, I'll award you a gold star :-)

I'll try to take a look! Two things I noticed when looking at baseline where that Terminal app and also NSTextView both use the function CTFontDrawGlyphsWithAdvances instead of CTFontDrawGlyphs. That seems to be a private API, i couldn't find documentation on it around. Another difference is how you draw background, if I remember correctly Terminal just rect fills before drawing text, instead you draw it all before? I'm not sure that the reason for doing it (issue 3446) is still valid for the new rendering engine

I don't know why the use CTFontDrawGlyphsWithAdvances. I noticed that too. I use CTFontDrawGlyphsWithPositions, which has got to be pretty similar. I use two passes: one to draw all the backgrounds and then I draw all the text.

My notes on the performance issue and what I've tried are in the last comment here: https://gitlab.com/gnachman/iterm2/issues/4976#note_13479753

I don't think issue 3446 is rendering engine-specific; it's more of a font issue (that the glyphs are sometimes oversize relative to their wcwidth() size).

Oh ok, I was just speculating because I wasn't able to reproduce that issue in Terminal.app for example!

@cHoco1 Hrm, Terminal does issue #3446 (closed) for me:

Sadly U+23ce is still defined as narrow width in Unicode 9:

23B4..23DB;N     # So    [40] TOP SQUARE BRACKET..FUSE

@gnachman Strangely it looks exactly the same for me both in Terminal.app and iTerm (like in your screenshot). I'm using Sourcecode Pro as a font while testing!

I also wanted to note that with this baseline change the underline should probably get shifted too, since it looks really close to the text right now!

I fixed the underline issue in commit df7258cc

the underline issue was fixed in the commit you mentioned, but regressed for me in b13f7695 Can open a separate issue if you prefer

@cHoco1 I'm not 100% convinced it's right to do what I'm doing now—always use the baseline and underline offset for the ASCII font—but it does provide consistency when there is a mix. I'm open to better ideas.

Terminal is doing something funky because sometimes they have more or less underline offset than we do. I noticed they always use an integral thickness, which I think looks better. They use the ceiling of the font's underline thickness which looks absurd when the value is like 1.05 (e.g., Menlo 14pt). I went with MIN(1, round(font.underlineThickness)) which makes more sense and looks better IMO.

I really like the the thickness change!

I'm not entirely sure what would be the best way to compute the underline offset, but right now I don't think it is good, when I have some text containing underscores it is almost impossible to notice them I could take a look at what Terminal does, but I think that it just draws it at the bottom of the cell

@gnachman forgot to add that it looks better if I don't use the option Use different font for non-ASCII text, but still less clear than Terminal (for the underscore character)

@cHoco1 I found another algorithm for computing underline offset, and by combining that with allowing grid-aligned single pixel thick lines on retina displays I think it looks better. Commit d7df7622.

It actually looks worse than before for me, underscore and underline are basically on the same offset and on a non-retina display are indistinguishable. I also kinda preferred the ticker underline instead of one pixel ahah. Anyway the screenshot above is using Source Code Pro h:12 but looks the same also for Fira Code.

Maybe having underline at the same level as the underscore is correct, not sure, maybe I'm just used to how terminal does it

Here's how it renders in TextEdit

I think the key is that the underline breaks for descenders, including underscores.

Doing it "right" is extremely complex, so I have a hacky fix in commit 9b69658e. Looks good except in Inconsolata, where most of the underline is lost because it sits so high.