Regular weight letters are rendered slightly taller than their bold variants

[burodepeper]

See atom/atom#8620 for exact details.

[chrissimpkins]

1. Is this ttf or otf build? and what version?
2. Mind checking a set of regular glyphs immediately adjacent to bold glyphs in that editor (i.e. taking the gutter characters out of the equation)?

Similar issue reported in #32. Unclear what is causing your issue at the moment.

[burodepeper]

v2_010-ttf
I see that there is a 013 now, I'll give that a try tomorrow and check 2 with it.

On a side note, I'm on a mac, if I have the option, should I go for ttf or otf?

[chrissimpkins]

Not sure that it will fix this issue, but worth a try.

should I go for ttf or otf

You are trying to optimize cross-platform display for a syntax highlighter, correct? If so, use the ttf files and let's work off of those.

[burodepeper]

Cross-platform is not necessarily my aim (but a nice plus), but I take from your answer that otf would be the better choice in itself?

[chrissimpkins]

Otf will work for screen use on Mac, not as well for screen on Windows and some Linux distros.

[burodepeper]

Not sure if this is what you wanted, but I've snapshotted several things with v013. The top and bottom greens should be the same, and all three variations with bold characters produce the error.

[chrissimpkins]

Intend to start work on this over the  weekend.  Sorry for the delay. 

—
Chris

On Wed, Sep 9, 2015 at 2:56 AM, David van Gemeren
notifications@github.com wrote:

Not sure if this is what you wanted, but I've snapshotted several things with v013. The top and bottom greens should be the same, and all three variations with bold characters produce the error.

Reply to this email directly or view it on GitHub:
#95 (comment)

[burodepeper]

No problem at all.
Let me know if I can help in any way.

[chrissimpkins]

Are you seeing this at any text sizes other than 14px?

[burodepeper]

8px: yes
9px: yes
10px: no
11px: yes
12px: no
13px: no
14px: yes
15px: no
16px: no
17px: no
18px: no

[chrissimpkins]

that's helpful. looking at the hinting today

On Sep 16, 2015, at 2:15 AM, David van Gemeren notifications@github.com wrote:

8px: yes
9px: yes
10px: no
11px: yes
12px: no
13px: no
14px: yes
15px: no
16px: no
17px: no
18px: no

—
Reply to this email directly or view it on GitHub.

[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.

[weslem]

Hi, I've experienced this same issue. I've captured this on an up-to-date x86_64 ArchLinux box using the TTF fonts.

• fontconfig settings: DPI=161, lcdfilter=lcddefault, rgba=rgb.
• terminal: st, using a font setting of Hack:size=10

Notice the cursor character renders correctly for some reason. I verified that the reverse-video cursor shows the correct alignment on all the affected characters. Similarly, bold-oblique characters appear correct:

[chrissimpkins]

@weslem thank you very much. I am assuming this is with FreeType? Are you using any modifications to FreeType?

[weslem]

Correct, the captures above are from an unmodified (to my knowledge) freetype2. The st terminal is a tiny program (one C file), and the font code doesn't appear that complicated to me: http://git.suckless.org/st/tree/st.c
I'm not familiar enough with font rendering quickly to identify any problems, however.

I can reproduce similar output with other freetype2 terminals rather easily. Here are some examples from my system:

xterm -fa Hack:size=12 -bg black -fg white -e \
    'for char in A F f H h T t x . _; do echo -e "${char}\033[1m${char}\033[0m${char}"; done; read'
uxterm -fa Hack:size=12 -bg black -fg white -e \
    'for char in A F f H h T t x . _; do echo -e "${char}\033[1m${char}\033[0m${char}"; done; read'
st -e sh -c 'for char in A F f H h T t x . _; do echo -e "${char}\033[1m${char}\033[0m${char}"; done; read'

urxvt, which does not link to freetype2, seems to work correctly:

urxvt -fn xft:Hack:size=12 -bg black -fg white -e \
    sh -c 'for char in A F f H h T t x . _; do echo -e "${char}\033[1m${char}\033[0m${char}"; done; read'

[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.

[burodepeper]

I had to do a clean re-install of Atom this morning. I switched back to the default theme (without bold letters in this example) and removed any personal styling, and this was the result:

Left: Menlo 14px
Right: Hack 14px

The line-height is set at 1.5 (so should be 21px), but all lines in the Hack example are rendered as 22px high. The lines are grouped in absolute positioned sets of six. That's why the seventh line is properly aligned again.

So the left of the image is everything completely set to default, and in the right half I've only changed the typeface to Hack. This is weird.

[chrissimpkins]

Sorry for the delay. I will try to have new builds with adjustments to the vertical metrics out this weekend. I think that this is coming from those settings but it is not clear to me which at the moment. We will need to play with some adjustments to see if we can figure this out.

[burodepeper]

No problem at all. I'm actually excited because (to me at least) it's such a weird issue.

[chrissimpkins]

New test build v2.014 available with new vertical metrics. I hope that this takes care of this issue. Please let me know how it works.

Files are available in #111

[burodepeper]

Initial visual quick glance looks great. Will do some proper in depth testing later today.

[chrissimpkins]

Excellent! Let me know.

[weslem]

I ran through the same tests I documented above. All the terminals look good to me now.

[chrissimpkins]

@weslem Excellent, thank you very much Matthew. That is helpful. I'm interested in both of your thoughts about the line spacing at this stage as well. I am planning to make the new vertical metrics our default on the release builds and this is significantly tighter than the previous release. We have another open issue report where we are discussing looser variants (and possibly tighter, but I think that this is where most who requested tighter line spacing want to be).

[burodepeper]

I only just noticed in my terminal that line-spacing had indeed changed. I am okay with this tightness. I have always been under the impression that I am to define the line-spacing in-app (ie, it hasn't changed anything for me in Atom for instance, since I have it set to 1.5 there), but you are talking about a default line-spacing when no other is defined?

About the other changes.

• Love the new tilde.
• I'd still prefer a 6-pointed centered asterisk, but this one suits the elegance of Hack better, in comparison to the more robust Menlo.
• I love how the dashes are horizontally really distinguishable, and I was wondering if it is by design that the underscore doesn't have this as well. At 14px I see that underscores are not completely connected, but I can't easily count them.

Besides my preferences, kudos!

[chrissimpkins]

Thanks for all of these comments.

but you are talking about a default line-spacing when no other is defined

Correct, this will make the line spacing tighter than the previous version by default across all platforms and editors. Users will need to manually adjust line spacing to return to the appearance of the last version.

I'd still prefer a 6-pointed centered asterisk, but this one suits the elegance of Hack better, in comparison to the more robust Menlo.

I am considering some alternate builds (Input style) and we could consider this change in one of these builds. The lowercase i and the zero seem to be polarizing glyphs as well. You can define alternative glyph forms via OpenType but most text editors don't support this feature at this stage.

I love how the dashes are horizontally really distinguishable, and I was wondering if it is by design that the underscore doesn't have this as well

This is a proposed change for the next release and did result in a change in the vertical orientation, centering, width, and height of the underscore. The width change is based upon a request in #97 . I agree with you. I like to see the spaces between the glyphs as well and did not want to go too far into the ligature range where it simply looks like a solid line. Feel free to join us over there to discuss this further. I can look at the hinting to see if we are losing a pixel or two between the glyphs at certain text sizes. This might lead to widening the space in the design or altering the hints (or both).

[burodepeper]

Cool, I'm coming over to #97.
Could you recommend software to look at the glyphs and stuff myself? I'm rather curious what it all looks like under the hoofd.

[chrissimpkins]

FontForge is excellent and libre/free. It uses the X Window system on OS X and looks terrible on Retina displays which is why I don't use it. It makes it really tough on the design side of things. It's great for scripting and low resolution viewing there and may look fine on Windows / Linux. I haven't tried it on these platforms.

I currently use Glyphs and FontLab Studio. RoboFont is another popular commercial alternative.

All of the above support scripting (generally in Python). I'd be happy to discuss my impressions of the paid applications off repository if you are interested before you sink money into software.

[weslem]

Overall, I like all the improvements I've seen. I've got the test build as my primary font today at work, and the new line spacing feels quite comfortable. I especially like the new tilde.

The changes don't quite address #104, however. The vertical line character really should not have any separation at all, and tmux splits still look wrong.

[chrissimpkins]

@weslem Thanks. I will take a look at this and see if we can address it in this release. There are a number of vertical character-to-character alignment issues outstanding that required a constant set of vertical metrics to address (box glyphs, line glyphs, etc).

[JesusMtnez]

Is it fixed?

[chrissimpkins]

@JesusMtnez should be. Mind giving the test build a try? It's available in #111 . Pushing this as a release over the weekend.

[JesusMtnez]

@chrissimpkins As you said, in 2_014 test build the issued is fixed. I'll be waiting for the stable release. Thank you!!

PS: I have tested it in Emacs and iTerm2

[chrissimpkins]

@JesusMtnez Great! Hope to have it out in the next day or so. Have a few small changes to add.

[chrissimpkins]

@JesusMtnez Any thoughts on the new line spacing?

[JesusMtnez]

@chrissimpkins I love it. I prefer it this way. Great job! 👍

[chrissimpkins]

@JesusMtnez excellent, good to hear that. That seems to be the consensus though there are some who wanted it even looser. Once I have all of the vertically aligned glyphs in proper position, we will likely build some wider variants.

[chrissimpkins]

These changes are now included in release v2.015. Thanks for the issue report David and thanks to all who helped with the testing of this issue here.