[Linux, OS X, Windows] Bold baseline differs from Regular baseline

[ptomato]

Perhaps best illustrated by a screenshot:

(those are two different windows side by side, Sublime Text and Gnome Terminal)

The baseline of Bold text is one pixel higher than that of Regular text. This happens at 8, 9, and 10 point, and does not happen with Bold Italic.

It also probably has to do with the font rendering stack on Gnome because I've seen it on Debian 8.1 (Gnome desktop) but not on Mac OSX 10.10.

[chrissimpkins]

Looking into this. Let me check the actual positions in the font editor and play in a few text editors. I haven't noticed this and (thought that) I confirmed that all sets were properly aligned to the baseline. Thanks for reporting it.

[ghost23]

This also happens on sublime on windows.

[johnfraney]

I'm also finding this in gnome-terminal and terminator (Arch Linux, 4.1.6-1 x86_64, Gnome Shell 3.16.3). >=11 pt looks as expected.

[chrissimpkins]

I can confirm that the glyph position is properly oriented on the baseline in the bold and regular sets. Can you confirm that you are using the ttf and not the otf files (both Windows and Linux users)?

[pmoroney]

I have this issue and I am using the web font from the CDN with the Secure Shell extension for Chrome on my Chromebook Pixel at size 9. Here is a screenshot. You can see that the bold fonts are a different size and hang down over the command bar in Vim. Let me know if there is anything I can do to help test.

Edit: It seems this was caused by screen, once I set the term value in my .screenrc file, it all works

[ptomato]

I'm using the TTF files on Linux.

[ghost23]

yes, using ttf on Windows.

[johnfraney]

TTF here, too.

[fernandaparisi]

Using TTF on Mac OSx 10.10.4, found the same issue using Sublime text 2:

[chrissimpkins]

@ptomato what editor are you using on OS X 10.10? I thought that this was going to be a hinting issue until @fernandaparisi reported this on OS X. Let me dig into the vertical metrics. The problem may lie there.

It doesn't show up on my system (OS X 10.10.5) in Sublime Text 3. Here are images at 12px and 8px. I tested 10px and can confirm that I am not seeing it there either.

[fernandaparisi]

@chrissimpkins I was using 14px for size. Tried 12px and 10px and the line height difference was gone.

12px

10px

[chrissimpkins]

@fernandaparisi hmmm... I am stumped. OK let me give this a bit of thought. Thanks for sharing this. That is helpful.

[ptomato]

@chrissimpkins I'm using Sublime Text 3 on OSX 10.10.5, but with the OTF, not TTF, fonts. I did not previously see the problem there because until I read @fernandaparisi's message above, I had not tried 14pt. (Thanks @fernandaparisi!) I can confirm that I also have the problem at 14pt size.

[chrissimpkins]

I can confirm that the bold set is aligned to the baseline. The baseline is shaded in the images below and I confirmed that the characters are positioned at 0 units (i.e. right on the baseline) where there are no bowls that overhang. The latter is an intentional design issue to make these curved lower areas of the glyphs appear to align on the baseline. If you don't provide this overhang, they appear too high relative to other glyphs.

Here are the bold upper case:

And the bold lower case:

Let's check one thing before I dig into the hints. Do you mind setting the bold characters in your editor to only those that do not have an overhang past the baseline. Use only glyphs like the Ff, Hh, or Tt. I'd like to confirm that this isn't causing these to snap up by a pixel for some reason.

[ptomato]

@chrissimpkins Here's a screenshot of what that looks like (OSX 10.10, Sublime Text 3, OTF fonts at 14pt size); the baseline is still different between the bold and regular characters.

[chrissimpkins]

OK that's great. Just a thought. Let me look at the hinting at those larger point sizes. To confirm this goes away below 14px too?

[ptomato]

@chrissimpkins That's right, below 14px everything is normal. For comparison here's the same text at 32px:

[chrissimpkins]

Thanks for the new image. Will update when I have more information.

[chrissimpkins]

So I checked the hints with the freetype grid viewer and this does not appear to be the source of the problem. Here are the hinted freetype2 renders on the grid at 8pt and 18pt. I looked at all text sizes from 6 - 32pt in both the regular and bold set. The bold glyphs never get nudged off of the baseline.

Regular

Bold

Let me look at the vertical metrics tonight. I may generate a few test builds with different vertical metrics if you are willing to try them.

[chrissimpkins]

New test build with updated vertical metrics is now available in #111. Please give these builds a try and let me know what you are seeing on your platforms. I think (hope) that this should take care of this problem.

Thanks

[ptomato]

Yes, that build seems to fix things for me; I tried on OS X / Sublime Text 3 and Fedora Linux / Sublime Text 3 and Terminal (Gnome desktop). Thanks for fixing!

[ghost23]

Tested on Windows 10, Sublime 3, works. Nice!

[chrissimpkins]

@ptomato @ghost23 Excellent, good to hear. How do the line height changes render on Linux and Win 10? Any thoughts about the tighter spacing? I'd be interested in hearing whether you feel that this is an improvement.

[fernandaparisi]

@chrissimpkins I still got the baseline difference on OS X, using Sublime Text 2, at 14px, ttf version.

But on Text Edit, using rich text mode, it seems OK:

Also on Terminal:

Maybe the issue is with Sublime Text autocomplete tooltip?
I manually removed the previous font version and installed the new test build.
If you need me to run any additional tests, let me know.

[chrissimpkins]

@fernandaparisi did Sublime Text happen to stay open between font installs? it seems to cache font files for me (in version 3 series). If so, will you close and reopen it to see if that works?

[fernandaparisi]

@chrissimpkins It was closed. I'll need to restart my computer soon, and I'll run the test again.

[fernandaparisi]

@chrissimpkins ha, a good old restart was all it needed :)

[chrissimpkins]

@fernandaparisi Excellent! Thank you very much for testing it Fernanda. Glad to hear that this addressed it.

Thanks to all of you for your help with this. I believe that this was the first report of this problem and it was causing a number of subtle associated issues. I will leave this thread open until we push it with the next release build.

[chrissimpkins]

@fernandaparisi Is that a cloud in your PS1 by the way? Icon font?

[fernandaparisi]

@chrissimpkins it's from an oh-my-zshell theme called Cloud - https://github.com/robbyrussell/oh-my-zsh/wiki/themes#cloud

I don't know how they pulled off the cloud icon, tho :)

[chrissimpkins]

It looks like they are using a Unicode symbol character (U+2601, ☁).

It must be from a fallback font. Thanks!

[chrissimpkins]

These changes are now included in the v2.015 release. Thanks to all for your contributions with this issue report and all of the testing that you performed on this issue. This led to a change that affected a large number of users. I greatly appreciate all of your help.