ASCII box drawing character(s) not full height

[alerque]

Using the OTF font on Linux I don't have a problem, but on OS-X using the OTF fonts screws up my vim and tmux splits. These are drawn using the U+2502 vertical line (│) character. This character should be the full height of the line, but using the default line height settings in both Terminal and iTerm it comes up short. It's not unless I compress the line height to ~80% of default that the line connects.

Again it works fine on Linux using default line heights.

[chrissimpkins]

Thanks Caleb. These vertically aligned glyphs definitely need some attention. I am working on some other issues with the vertical metrics which may lead to minor vertical spacing changes and want to sort that issue out before I work on these issues but will definitely address this. Interesting that it isn't a problem on Linux. What Linux distro is that?

[alerque]

I'm running a very up to date ArchLinux box, and that is Termite (a VTE3-ng based terminal).

[chrissimpkins]

got it thanks. The reason for the comment above is that any change to the overall vertical metrics of the fonts will scrap changes to the alignment of specific glyphs that we make here. I will definitely address this. Hope to have these vertical metrics issues sorted out over the course of this week.

[chrissimpkins]

arch is running FreeType? any modifications (eg. Infinality)?

[alerque]

Yes, freetype 2.6, harfbuzz 1.0.3, and graphite 1.3.2. No no infinality or other mods that I know of.

[chrissimpkins]

Please give the ttf builds with brand new vertical metrics a shot. Available in #111

These vertical metrics changes (if acceptable once we have some input) will be included in the otf builds as of the next release.

[chrissimpkins]

This is what I am seeing for U+2502. It is well outside of the bounding box so we may have the vertical spacing just above the level where these connect in the current v2.014 test build (as @weslem confirmed).

Will work on the glyph to see if we can address this.

[weslem]

If it helps, here's the current rendering of the test build captured from my system in st with Hack:size=10:antialias=true:

[chrissimpkins]

@weslem do you happen to have DejaVu Sans Mono installed to check where it is with their metrics as well? I didn't (intentionally) change this glyph and the vertical metrics should be close to their set as of the v2.014 changes.

[chrissimpkins]

@weslem and thanks!

[weslem]

Sorry, I somehow missed your request. Here's some captures with 2.015:

xterm -fa 'Hack:size=12' -bg black -fg white -e \
  'for x in {0..10}; do echo xX│Xx; done; read'`

xterm -fa 'DejaVu Sans Mono:size=12' -bg black -fg white -e \
  'for x in {0..10}; do echo xX│Xx; done; read'

[chrissimpkins]

Interesting, not sure why they differ. I will take a look at the DejaVu glyph. Thanks for posting this.

[weslem]

I took a look at this on some of my other machines. All of them have connected box-line characters, as well as a shared "dotfile" configuration repo between them, making the differences easier to find.

The only configuration difference I found is that the quirky machine has a 101 DPI monitor. X had trouble identifying the DPI, and kept setting it to 96 regardless of any change I made to Xorg.conf, so I had to manually set it in my fontconfig. It ends up with a weird configuration where X still thinks it's 96 dpi:

> xdpyinfo | grep dots
  resolution:    96x96 dots per inch

But fontconfig thinks it's 101 DPI:

 <match target="pattern">
   <edit name="dpi" mode="assign">
     <double>101</double>
   </edit>
 </match>

Given the complexity of Linux, I have no confidence that this is the only difference, but it seemed suspicious to me.

[chrissimpkins]

Oh that's interesting. Are they showing as aligned in the Hack set on the other machines?

[weslem]

I'm not sure what you mean when you ask, "showing as aligned." The vertical line box chars definitely connect, but I haven't done any deeper investigation.

I have manually set the DPI to 96 in fonts.conf, with no visible improvement in vertical alignment. Removing my manual DPI setting completely produces a minuscule text size (surprising me, given that xdpyinfo says X has the 96 DPI setting), but it still has an empty pixel between the lines of characters.

To round out my diagnostics, I've looked into library versions on the machines. The bad machine is on Ubuntu, my two good machines are Ubuntu and an Archlinux box. Both ubuntu machines have the 2.11.0-ubuntu4.1 amd64 version of fontconfig.

I'll follow-up with a post from that machine with some more screen grabs that show slight differences in rendering. It looks like the "good" Ubuntu machine may still have some slight offset that is hard to see due to antialiasing.

[weslem]

On the "good" ubuntu machine, xterm seems to render things perfectly:

xterm -fa 'Hack:size=12' -bg black -fg white -e \
  'for x in {0..10}; do echo xX│Xx; done; read'

But the st shell from which I normally operate, with an alpha-blended background, shows slight gaps filled in with antialiasing even for the same Hack:size=12 font string:

[chrissimpkins]

We are going to include these changes in v2.020. Currently working on the block element glyphs for v2.019.

[chrissimpkins]

v2.020 DEV012616 build files are available for testing:

Hack-Regular-DEV.ttf

Hack-Italic-DEV.ttf

Hack-Bold-DEV.ttf

Hack-BoldItalic-DEV.ttf

[weslem]

I still produce strange renderings on my high-DPI monitor. I made a number of renderings with both 2.019 and the DEV012616 version using this script:

for size in {8..14};
  do xterm -geometry 5x11 -fa "Hack:size=$size" -bg black -fg white -e \
    "echo ${size}pt; for x in {0..8}; 
      do echo xX│Xx;
     done;
    import /tmp/2_20_DEV-size${size}.png";
done

Point size 12 looks good, but does show slight differences around the vertical bar meeting points:

Point size 11 is visibly different, with a clear gap in both versions. The v2.020 DEV012616 version seems to have a smaller gap, however:

I'm the only one that continues to comment on this spacing issue. Unless others observe it as well, it seems like it shouldn't be a priority.

[chrissimpkins]

Thanks Matthew (@weslem). I really appreciate your feedback.

Unless others observe it as well, it seems like it shouldn't be a priority.

We have several open issue reports associated with vertical spacing in the box drawing glyph set. It was work that needed to be done after I adjusted the line spacing. It looks like we are getting close. At this point I think that we are entering the domain of hinting issues and I am not prepared to manually modify the hinting across all of these glyphs right now.

Thanks again.

[chrissimpkins]

It's a pretty big set of glyphs and here is where we are overall at 12px:

[chrissimpkins]

These fixes (our best attempt at them) were included in the v2.020 release. Now available. Thanks to all for your help with this issue.