Hack: Powerline symbols are incorrect

[iirelu]

Under Hack:

Under a font with proper powerline symbols (in this case Fantasque Sans):

Note how Hack's symbols don't properly fill the entire height of the character, whilst Fantasque's ones do.

[chrissimpkins]

Thank you! I have been looking for feedback from Powerline users. @corelon and I worked on the Powerline glyph alignment and it seemed to have proper vertical alignment on OS X but we haven't looked into this on other OS. Can you let me know what platform you are on?

[chrissimpkins]

Looks like the sidebearings (horizontal alignment) are a bit off in your images as well...

[amfl]

I am also experiencing this on Windows with PuTTY.

[chrissimpkins]

Thanks @amfl . queued up!

[chrissimpkins]

Here is the alignment of the Powerline glyphs in Hack (with 'Ac1' added for comparison):

_For the horizontal positioning issues_:
The arrow heads are at the edge of the em box. I think we need feedback from the Powerline developers about the dimensions that they are using to position the rectangular colored areas. Those seem to push into adjacent Powerline glyphs.

_For the vertical positioning issues_:
This is a simple fix. We just need to nudge the arrow heads up. The problem is that the images from Windows posted by @amfl and OSX by @theckman (#30) are much closer to the midline and will likely be pushed too high with the changes needed to align the glyphs on your system.

I think that this will be a bit of trial and error...

[kejadlen]

I'm seeing this issue on OS X as well:

Would be glad to help out by debugging/testing if you need it.

[theckman]

I'd be more than happy to help out here. It looks like my system, for some reason, has padding around the top and bottom of the text to make the color equal on both sides. You can see this in people's screenshots. Their text is closer to the bottom of the boxes than the top.

Where is everyone using powerline? What shell / terminal application? I'm using this repo (https://github.com/jeremyFreeAgent/oh-my-zsh-powerline-theme) at 561c0009e2adf14e49977b98f22a9115f3e87a09. It is worth noting that my vim setup looks pretty much the same as my zsh one.

Edit: I just pulled my theme down to the version available on master with no change.

[jezeniel]

I am experiencing the same problem stated above. I use termite for my terminal emulation on manjaro linux.

[shosca]

Same alignment issue in Win10 + msys2 mintty

[Binarytales]

I'd love to help out with testing this issue and any fixes you may have.

Here is Hack at 14px on the Terminal.app OSX 10.10.4 on a Retina display:

And here it is on the same system but this time in iTerm2:

Unfortunately, you can see that they treating the vertical positioning differently.

If you need any other screenshots, different font sizes, more zoomed in, screenshots with an on screen rule or anything else I am more than happy to do that.

[justinta]

I'm seeing the same thing, however, I'm not using powerline outside of Vim. I've created a custom tmux theme using powerline glyphs and I'm using Agnoster theme from oh-my-zsh.

With Hack:

Using Literation Sans Mono Powerline:

Agnoster oh-my-zsh theme:

Vim Powerline:

Thanks for your work on this. Let me know if I can help you test this at all or you need more info.

[chrissimpkins]

First iteration of the Powerline glyph alignment changes (PL1).

Replace the Hack regular set with this one and continue to use the name 'Hack' to define the font.

Download test ttf

Positions

Branch arrow (U+E0A0)

• top left (279, 1783)
• bottom left (279, -267)

LN glyph (U+E0A1)

• top (290, 1783)
• bottom (290, -270)

R solid arrow head (U+E0B0)

• top corner (290, 1783)
• bottom corner (290, -270)

R narrow stroke arrow head (U+E0B1)

• top corner (283, 1731)
• bottom corner (283, -322)

L solid arrow head (U+E0B2)

• top corner (936, 1783)
• bottom corner (936, -270)

L narrow stroke arrow head (U+E0B3)

• top corner (937, 1731)
• bottom corner (937, -322)

[shosca]

Screenshot with test font win10 + msys2 mintty

and gnome-terminal on archlinux

[chrissimpkins]

@shosca getting close vertically. The glyph sizes are too small on your system. It looks like the arrowheads need to be larger. Let's see a few more examples and we can try again.

[eriol]

gVim on Debian Stretch with test font

[amfl]

PuTTY on Windows 8 with test font

[alerque]

I came here to file this same issue report. I am an Arch Linux user currently using Liberation Mono for Powerline. In that font and many others that I patched using the available font patch tools, the powerline arrow glyphs are always 100% of the line height. I don't understand why this should be a matter of trial and error and adjusting. Running the font patcher does a bunch of math on the existing font metrics to find the proper height and width for these glyphs. Can you not backport those metrics into the base font files?

[Binarytales]

Here is Terminal.app top and iTerm2 bottom. OSX 10.10.4.

Font size 14px:

And again here at font size 48px. Not something most people would ever use but iTerm2 is acting very strange and I thought maybe this "zoomed" in view might help with debugging. Let me know if this is helpful and I'll remember to always do this in future.

Font size 48px;

[chrissimpkins]

@alerque Are you referring to the official script released on the Powerline repository? I looked into this a few months ago and my recollection is that I came across an issue report thread that pushed me to avoid the script. My sense was that this script is no longer in general use because it failed to appropriately import the glyphs in attempts by a number of others.

Am I mistaken? Can you provide more detail on the metrics that it provides? My goal is to adjust the Powerline glyphs to the Hack metrics and maintain them in the general release rather than generate a separate patched build.

[kejadlen]

Terminal.app on 10.10.5 with a font size of 10:

[Xenopathic]

Similar results with xfce4-terminal. First 2.010:

Then the version in development as of now (PL1):

Loving the font by the way!

[m42e]

The test font on Windows 7, mintty, cygwin:

[chrissimpkins]

Not something most people would ever use but iTerm2 is acting very strange and I thought maybe this "zoomed" in view might help with debugging

@Binarytales what do you mean by 'strange'?

[chrissimpkins]

Test build 2 is available (PL2) with changes in the horizontal spacing of the solid arrowheads and increase in size of the solid arrowheads. Let me know what you think. Thanks for all of the screenshots. These have been very helpful.

Download Link
Hack-Regular-PL2.ttf

[m42e]

Better, but not perfect :)

Thank you for the font, it is a real improvement for my eyes :+1:

The shell promt works nicely, but in vim there seems to be a very small gap.

[kejadlen]

Getting pretty close:

[chrissimpkins]

Looks like @m42e renders larger than @kejadlen for some reason.

[m42e]

I'm on Windows, using mintty. Does fonts behave different on win/mac/unix ?

[chrissimpkins]

@m42e unfortunately yes... and not only that, they can have cross-application differences in rendering on the same platform.

[bchretien]

Hack-Regular-PL2.ttf on Arch Linux with size 12:

• with Termite:

• in console vim (still in Termite):

[chrissimpkins]

@m42e In the images posted above @Binarytales, @Xenopathic, @bchretien and @eriol are pretty close to your rendered height. @kejadlen & @amfl seem to render smaller glyphs relative to the colored text box c/w you

[chrissimpkins]

Test build 3 with another 5% increase in the size of the solid arrowhead glyphs, no horizontal or vertical metrics adjustments.

Download Link
Hack-Regular-PL3.ttf

[chrissimpkins]

I am seeing a line between the arrowhead and the box. Does that show up in other patched fonts (i.e. is it an outline around the text box) or am I still a bit off in the horizontal dimension?

[kejadlen]

Reaches the bottom now, but not the top:

[kejadlen]

@chrissimpkins Would this be easier in a channel of some sort? IRC, Gitter, Slack?

[m42e]

I maximized the font size. Here are the results.WIN7, mintty.

[shosca]

With PL3 Win10 msys2 mintty size 10 the top looks off by a hair

size 11 looks like the vertical middle alignment is off

size 9 and 12 is perfect

[Xenopathic]

Off by a fraction here too. Using size 12 font.

[Binarytales]

@chrissimpkins By strange I mean when I bump the font size up to 48pts in iTerm2 the Powerline icons render really tiny at like 8pts. Seems that's almost certainly an application bug though an not an issue in the font.

[shosca]

gnome-terminal + PL3 testing with sizes 9 to 16:

http://imgur.com/a/2zgwt

win10 msys2 mintty + PL3 testing with sizes 9, 10, 11, 12, 14, 16

http://imgur.com/a/DbFiZ

[chrissimpkins]

thanks all for posting the images. what is your thought on the horizontal alignment. Is it supposed to be flush against the rectangular box or is there normally a line between the glyphs. My sidebearing is now 0 on the side adjacent to that box which means I will need to push into the prior glyph. Does any text ever render close to that edge?

[Binarytales]

My expectation is that the separator arrows always sit flush with the background of the previous character.

[amfl]

Starting to look pretty good.

PuTTY on Windows 8, 18pt

PL2:

PL3:

Also, PL3 if I change PuTTY from ClearType to Antialiased:

[chrissimpkins]

OK that is helpful. Thank you.

On Sep 3, 2015, at 9:29 AM, Jon Linklater-Johnson [email protected] wrote:

My expectation is that the separator arrows always sit flush with the background of the preview character.

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

[chrissimpkins]

Here's hoping that we have it with this one. Slight increase in height of the closed arrowheads, went to negative sidebearings to eliminate the fine line that shows between the closed arrowheads and the rectangular text box. PL4 build

Download Link

Hack-Regular-PL4.ttf

[kejadlen]

Strangely enough, the height and y-position of the arrowheads seem to change in Terminal.app depending on the size of the font I use...

[chrissimpkins]

@kejadlen Is this at the same text size as the one above with the comment

Reaches the bottom now, but not the top:

[kejadlen]

All my screenshots are in Terminal.app at size 10. 

[chrissimpkins]

@kejadlen Not sure why this is rendering with such a difference in height relative to the rectangular box on OS X vs. other platforms. Let's see how the Linux and Windows shots look with this build.

[carloabelli]

PL4 looking pretty good to me. Using Terminator on Arch Linux:

10 pt:

48 pt:

[chrissimpkins]

@cabellicar123 :+1:

[carloabelli]

Impossible to notice especially at small font sizes, but if you zoom in heavily on the 48 picture there is a slight blue haze for the pixel above and below the very base of the arrow:

Not sure if thats normal (I'm no font expert) but I tried looking for it on Inconsolata-g for Powerline and saw nothing:

Don't want to spoil the good news but thought I should mention it none the less.

[Xenopathic]

I see a slight overhang not on the bottom, but on the top of the symbol. Also, It seems to me that the whole symbol is slightly too high. The horizontal black line is exactly in the middle of the prompt line, and the powerline symbol is ever so slightly offset upwards:

[chrissimpkins]

@cabellicar123 @Xenopathic This looks like an antialiasing issue. Are you able to confirm without antialiasing and with one px size up and down using antialiasing? We may be as good as we're going to get on your systems. If we push it down at the current text size I am guessing that we are going to see the same issue on the opposite end.

[chrissimpkins]

Not sure if thats normal (I'm no font expert) but I tried looking for it on Inconsolata-g for Powerline and saw nothing

@cabellicar123 possible that it is rendering just on the too tall size on your system. The problem is that OS X is still rendering it too small... (see @kejadlen image above)

[depressiveRobot]

@chrissimpkins Unfortunately, still not fixed...

Hack Regular 14pt:

Source Code Pro Powerline Regular 14pt:

Hack Regular 14 pt + Source Code Pro Powerline Regular for non-ASCII

As you can see, Source Code Pro vertical alignment is slightly higher.

OS X 10.10.5
iTerm2 Build 2.9.20150905-nightly (iTerm3)
Hack v2.0.12

[eriol]

@chrissimpkins, many thanks for addressing this so fast!

My test for Hack v2.0.12 Release Candidate:

Size 10:

Size 13:

Size 48:

Size 96:

It look pretty good to me, but you will notice that at size 96 there is a small gap at the bottom.

Same environment as before: gViM on Debian Stretch.

Thanks for your work!

[chrissimpkins]

The new release version (v2.013) includes the Powerline glyph changes that are current to this point. I will also push these builds to the Powerline fonts repository.

I am leaving this thread open to continue fine tuning work on Linux/Windows and address the difference in rendering that is occurring on OS X.

Thanks to all of you for all of the testing and input to date. This has been extremely helpful.

[alerque]

The new v2.013 (OTF on Linux in Termite) is looking much better. I do still have some nagging sizing and alignment concerns. I'm not sure how much of these are my preferences and how much are representative of expectations, but here are a couple things that catch my eye.

Like the fellow in #86, I think the branch symbol is too weak. Not only is it light and narrow (problems that a bolder weight might solve), it also isn't full height. A lot of powerline fonts have this as a full height glyph much like the arrows that reach to the edge of the line height. For use in powerline I think I prefer that rendering.

Another glyph I am used to seeing full height is ❯. Is there a specific reason it's only a partial height glyph in Hack? I'm torn on which way I actually like this, but given most other fonts (including whatever I'm seeing here on Github) render it full height it seems like that might be the better option.

The star and square glyphs ✱ and ◼ don't match vertically. The square is quite a bit lower.

Here is a screen shot of my prompt that illustrates all the above.

Hack 12pt:

Liberation Mono 12pt:

I would say Hack has the upper hand here in general, but the square at least should be centered and the weight and height of the branch and arrow glyphs could probably use a boost.

[theckman]

The latest version looks strange to me at 10pt on OS X:

[gglanzani]

I can confirm with @theckman, also for 12pts.

[chrissimpkins]

@gglanzani also on OS X?

[gglanzani]

@chrissimpkins Yes, El Capitain + iTerm

[rmbreak]

Hack TTF v2.013 on arch with roxterm. 12pt font. The < arrow looks a little funky. It doesn't appear to be seated flush against the glyph to the right of it.

Meant to edit previous comment but ended up deleting.

[jmccance]

Installed v2.013 and restarted iTerm 2. Right-facing > looks too high.

This is at 13pt.

[chrissimpkins]

I will look through the new images tonight. Thanks for posting all of these.

[chrissimpkins]

@alerque

Another glyph I am used to seeing full height is ❯. Is there a specific reason it's only a partial height glyph in Hack?

No reason, we can change this.

The star and square glyphs ✱ and ◼ don't match vertically. The square is quite a bit lower.

These are not part of the standard Powerline glyph set that are mapped to the Unicode private use area. Do you know what unicode characters these are?

[chrissimpkins]

Summary of Powerline Issues that are Current for v2.013 as of 9/9/15

OS X - solid arrow heads continue to render with less height than other platforms. Terminal.app displays too high, iTerm2 displays too low...

Arch Linux with Terminator - OK

Arch Linux with roxterm - left facing solid arrowhead displays gap with the rectangular colored text box

Debian with gVim - reasonable, slight gap at the bottom of the solid arrow heads

Windows with Putty - reasonable, slight gap at the bottom of the solid arrow heads

Requests for Powerline Symbols

Increased weight for the branch glyph

Requests for Non-Powerline Symbols Used in Powerline

Modify vertical position of filled square and asterisk (need Unicode characters for these)

Discussion

Based upon @kejadlen recommendation, would anyone be interested in moving this discussion to Slack? Easier there?

[Irubataru]

Another chime in

OS: Arch Linux
Terminal: urxvt
Font: Hack v2.013 OTF 14pt with aa and hinting

[rmbreak]

Took some more samples on ttf-hack 2.013.

OS: Arch Linux
DE: GNOME 3
Font lib: Freetype2 2.6-1

terminator. 12pt. aa.

terminator. 12pt. noaa.

roxterm. 12pt. hintfull. aa.

roxterm. 12pt. hintfull. noaa.

roxterm. 12pt. nohint. aa.

roxterm. 12pt. nohint. noaa.

With hinting and anti aliasing disabled, alignment looks perfect. It looks like hinting is pushing the glyphs upwards slightly and anti aliasing isn't blending the < arrow properly. I wasn't sure how to tweak hinting on terminator. I was able to tweak hinting and anti aliasing on roxterm with gnome-tweak-tool.

[chrissimpkins]

I think that I am going to take Caleb's (@alerque) recommendation and use the Powerline patch script to see if we can find the "recommended" metrics that are used when patched fonts are created with this tool. This will be working under the assumption that this three year old script still generates valid metrics which we will need to confirm. I don't see anything more current and assume that these metrics have not changed because it appears that patched fonts are still being created with the tool.

It would be helpful to see what metrics it calculates and print these to standard out for discussion here rather than create a new patched font. If any Pythonistas want to dive in and work on it this week feel free, otherwise I will plan to do it this weekend. On initial glance at the script it looks like you will need to install fontforge to use it.

The original vim-powerline script is located here: https://github.com/Lokaltog/vim-powerline/blob/develop/fontpatcher/fontpatcher

The information that we will need to review includes the metrics that are calculated in the blocks that begin here:

https://github.com/Lokaltog/vim-powerline/blob/develop/fontpatcher/fontpatcher#L157

and extend to the overlap metrics that are at this point:

https://github.com/Lokaltog/vim-powerline/blob/develop/fontpatcher/fontpatcher#L206

It looks like the script comments may include some potentially useful documentation about how Powerline renders these glyphs relative to other parts of the Powerline UI. These may provide some hints that will help us with the issues that are coming up here.

[chrissimpkins]

I introduced tighter vertical metrics (and hopefully more consistent across platforms) in the v2.014 test build. Be interested in where we are with the Powerline glyphs in this build. This may have eliminated the progress that we've made to date, but I hope that it addresses some of the differences in height and vertical alignments that we are seeing here. Please let me know what you are seeing in Powerline, what your thoughts are on the line spacing, and then I will dig in to the Powerline patch script to try to get these right once and for all.

Files available in #111

Thanks

[carloabelli]

Arch with the most recent build:

Seems to be sitting a tad bit too high now. Let's see if the script fixes that.

[theckman]

I've added a comment to #111 that shows my experience with the changes in v2.0.14. The glyphs look strange:

• https://github.com/chrissimpkins/Hack/issues/111#issuecomment-141877991

[amfl]

v2.014 test build on Windows 8 in PuTTY, with ClearType antialiasing

Size 10

Size 11

Size 12

Size 20

Size 48

[chrissimpkins]

Thanks for all of these new tests. I generated a patched version of the v2.014 regular set build using the Powerline patching script and the current font metrics in the regular set. Do you mind having a look at this to see whether this fixes your issues on each platform? It looks like Powerline uses some monkeypatching of the font to make these display properly. I suspect that this is why we are seeing the glyphs too high on one platform and too low on others.

Once we have confirmation about this test patched build, we can try to add these metrics to the main release build.

The patch script renames the font to "Hack for Powerline" and I believe that this is how you need to specify this in your editor settings. Platform specific patched Powerline font install details here.

Download

Hack Regular for Powerline

[kejadlen]

It looks a bit too low here:

Here's Source Code Pro for Powerline:

[jmccance]

Thanks for working on this! Here's how it's looking for me right now on OS X 10.11 (15A282a) in iTerm 2.1.1.

Font settings:

And for an extra headache, here's what it looks like in Terminal.

Terminal font settings:

[chrissimpkins]

@kejadlen That is unpatched v2.014 or the Powerline script patched version?

[chrissimpkins]

@jmccance Joel, are any other patched fonts displaying properly for you?

[jmccance]

Hm, good point. The answer is no, not really. I normally use DejaVu Sans Mono for Powerline with the font settings shown below.

Note that I have the Non-ASCII Font settings at a smaller size. If I set both to 13pt, DejaVu Sans Mono for Powerline looks like this in iTerm 2:

Perhaps my issue is just iTerm's fault. : /

[Xenopathic]

I see pretty much the same as with the other test build:

Here is the Powerline version (top), compared to Droid Sans Mono for Powerline (bottom) at size 12:

So Hack is still a little off the top, but other fonts also go outside the line (but they are better vertically centered).

[depressiveRobot]

Same for me as for @jmccance with Hack for Powerline.

[theckman]

I'm still seeing the issue I mentioned here: https://github.com/chrissimpkins/Hack/issues/33#issuecomment-141878136 -- the top of the arrow is above the rest of the line.

[chrissimpkins]

Thanks all. Started work on the patch script to clarify dimensions.

[kejadlen]

@chrissimpkins That was with the Powerline script patched version.

[chrissimpkins]

@kejadlen thanks. Will update when I have some metrics from the script.

[tpict]

I seem to get a single pixel fringe between the characters which I assume is something to do with horizontal alignment. Hack size 11 in Termite on Arch with Infinality:

At a larger size (36) it looks better but you can see vertical misalignment in the right arrow. The patched and unpatched versions of v2.014 look identical to me

[chrissimpkins]

@motdef pushing a new release this weekend and will get back on these glyphs. The script to look at the Powerline glyph alignment (from powerline patch script) is nearly complete so we will have some data to work with.

[theckman]

@chrissimpkins I'm still having glyph issues on OS X in iTerm2 with v2.0.18, but I've come up with a bit of a quick/hacky fix:

Here are the font settings in iTerm2:

But if I change the vertical spacing just a hair it looks much better:

[stefan-kern]

@chrissimpkins is this still a work in progress? im using the agnoster theme for fisherman on the fish shell inside terminator on ubuntu, and the right arrow () is too small vertically. if i can help, let me know.

[chrissimpkins]

@stefan-kern What text size are you using? Happy to address this again but we found that we were all over the place with alignments on the various platforms X editors so it was difficult to find a single alignment that works for all. May need separate builds to really get this right.

[stefan-kern]

@chrissimpkins it seems to be font size independent, i tried 11-16 and also 11.1 - 11.9 in .1 increments.
sad that its kind of random, it worked fine for me when i used it with oh-my-fish agnoster on an archlinux setup. having an offset like this makes my eyes twitch from time to time.

[theckman]

My comment above still applies for me (https://github.com/chrissimpkins/Hack/issues/33#issuecomment-153996530).

[chrissimpkins]

There is a new tool available that allows you to easily modify the line spacing in the Hack fonts. While it may be a longshot, given Tim’s (@theckman) comment in https://github.com/chrissimpkins/Hack/issues/33#issuecomment-153996530, it may be worth minor platform specific adjustments to the line spacing to see if this improves the orientation of the glyphs in your configurations.

Tool is available here:

https://github.com/source-foundry/font-line

Let me know if this seems to help and what line spacing adjustment was necessary in your platform / editor combination. I am doing a bit of experimentation with these cross-platform vertical metrics issues to see if we can improve the consistency.

[chrissimpkins]

@theckman : if you are available to test the line spacing issue that you reported on OS X, will you try the following command in font-line:

$ font-line percent 20 Hack-Regular.ttf Hack-Italic.ttf Hack-Bold.ttf Hack-BoldItalic.ttf

It looks like this will modify the hhea values slightly and I am wondering if this is playing a role on OS X since you saw the change with the iTerm2 line spacing adjustment. Unfortunately the line spacing metrics that are used in platform X source code editor combinations is not terribly well documented. If anyone would like to look into this issue in more detail I could use a hand, particularly on Linux + Windows platforms. I've developed a new vertical spacing test "font" (just full UPM blocks with extensions above / below in 50 unit increments) to test the metrics that are involved in vertical spacing issues across platforms in source code editors. Somewhat of a diversion from this thread topic, but may be involved in the problems that we have seen here.

[polarathene]

While looking into these issues myself, I had the Hack font set for my terminal font at the time and ended up manually adjusting the glyphs myself on OSX with GlyphsApp. I noticed how the glyph rendering will break at different font sizes, I assume hinting can help here but I'm not familiar in how to go about that.

font-line -> fontpatcher?
Would be great though if there is a reliable way to automate the patching by providing some config if needed and using the font metrics from that font-line tool :) If someone is going to look at altering the fontpatcher tool, I came across this comment which explains how the tool makes some assumptions to patch a font and how it can be unreliable with fonts like Source Code Pro. Perhaps font-line could be used to improve the data fontpatcher needs and use the bounding-box info of glyphs to get the average/common metrics to use instead of the largest. Could probably improve that further by only sourcing that data from a specific range of glyphs(avoiding PUA where icon glyphs may exist with differing metrics).

iTerm2 Hack @ 12pt + vertical spacing increase
I used the settings that @theckman used with Hack @ 12pt and slight increase to vertical spacing. Very small vertical offset. The glyph doesn't properly span the vertical height of the line BG, very tiny bit off from touching the bottom and little more from the top. The adjustment also doesn't seem to help at 14pt, the glyph is centered but noticeable gaps from top/bottom.

Compared to Sauce Code Pro
I checked out Sauce Code Pro(Although the one I had also patched on font-awesome for some reason), one of the powerline patched fonts and it breaks the same way, it looks like @theckman had without vertical spacing changed when at 13pt, rather than 12pt. Again, barely noticeable but like mentioned above with Hack, the glyph was not properly connected to the top/bottom of the vertical BG colour edge. Probably fine for most of us though :P

What causes the font size differences?
Again I don't know much about font design, though I've read the em size you develop the font in can affect how it renders at different font sizes? Hack is at 2048 while Sauce Code Pro was at 1000. I thought I was onto something when I changed from 1000 to 2048 and got Sauce Code Pro rendering best at 11 instead of 13 which was quite different, but doing the same with the font at it's original 1000 value resulted in the same effect... so I guess my font tool (GlyphsApp) messed with something like hinting.

Testing / Automation
There might be something out there already, but packaging a test environment into a Vagrant VM, Packer Image(for VM use) or Docker container might be handy. I assume there is some automation tool out there that would let you open various terminal apps change the font sizes and take screenshots with x/y/width/height cropping. It's easier to test fonts across browsers with SauceLabs and CSS tools, but i guess that's irrelevant for what it'd look like on the terminal.

Is it worth the effort though if rendering will vary so much, even when only font size changes? If that cannot be avoided, perhaps it's better to just provide an environment to handle automating patching with config like suggested earlier per user.

[chrissimpkins]

@polarathene Thanks for all of this information Brennan. Sorry for the delay in getting back to you.

If someone is going to look at altering the fontpatcher tool

Interested in digging into this issue with me? It would be great to create a strategy that works for us here.

Re: different font sizes and spacing issues. I am at a loss. We have gone round and round and this seems to be extremely platform and application (editor) dependent. Changes that are seen as too high on one platform will display too low on another. I think that what we really need is for someone to dig into the Powerline code to determine how they are rendering the UI. This may lead to platform specific solutions / workarounds. Unfortunately, eyeballing and glyph size adjustments doesn't seem to address this in a cross-platform manner.

Testing / Automation

Would love to hear more about this idea. Are you aware of a way to do this? If so, let's give it a shot. Sounds like a great idea, one that I have not considered in the past.

Is it worth the effort though if rendering will vary so much, even when only font size changes?

The Powerline glyphs are very popular and I agree with you that the development of a cross platform solution will be of significant help to many users of our fonts. To take a broader view, if we understand this issue we could develop and distribute a tool that would allow other font development teams (and/or users of those fonts) to implement the Powerline glyph patch in a way that works for everyone. Perhaps we could pull some of the Powerline developers into the conversation to address this issue. It seems that their patch script is from some time ago. They may be able to point to a solution in a much more rapid fashion than we could discover through exploration of their source.

[polarathene]

@chrissimpkins

Interested in digging into this issue with me? It would be great to create a strategy that works for us here.

I'd only be good for throwing ideas around at the moment as I'm quite busy. In a few weeks time I may be able to commit some time towards it, I'll ping you if I start anything :)

I am at a loss. We have gone round and round and this seems to be extremely platform and application (editor) dependent.

I imagine a part of that is due to the glyphs using the full line height to align with the background colour. Another part platform wise is probably font rendering engines, OSX and Windows handle this quite differently, Windows shifts the blue/red channels around just a little bit, I can't recall what OSX does. It may still vary a bit with Windows 7 and up as they have settings wizard to adjust the font rendering. Linux has no fixed way at rendering from what I understand and can emulate OSX or Windows rendering engines. I'm not sure how terminal applications come into play here, perhaps how they handle line height/background colours for fonts, I've heard some will crop glyphs that extend beyond their bounds whereas others do not.

Unfortunately, eyeballing and glyph size adjustments doesn't seem to address this in a cross-platform manner.

Are you at least able to get consistent alignment for the font at any size? I'm not familiar with font hinting but would assume this would help around that issue.

I think that what we really need is for someone to dig into the Powerline code to determine how they are rendering the UI.

I'm using Powerlevel9k which is a ZSH theme, it doesn't use the python Powerline lib at all, it's likely a smaller codebase and has the same rendering problems from what I can tell.

Are you aware of a way to do this? If so, let's give it a shot.

I'm aware of where to get started, plenty of notes on the subject but I've not found time to practice it yet. There's a good chance in the next month or two I may be doing so at work at which point I could put something together for this too :)

Perhaps we could pull some of the Powerline developers into the conversation to address this issue.

Worth a try :) One of the developers already expressed it being a problem to support proper rendering across the board.

I'd say you'll probably have to distribute a tool or multiple variants of a font to get the best results. Many terminal emulators support a 2nd font for rendering glyphs like Powerlines, if that works you'd be able to have Hack-Powerline-OSX.otf for example only containing these glyphs to work with any of the weights/styles of the core Hack font. Linux users are able to use the fallback strategy which requires no font patching either, no idea if they'd still need the glyphs catered towards their platform or companion font though.

[chrissimpkins]

Are you at least able to get consistent alignment for the font at any size

No nothing consistent across all platforms at any given size unfortunately.

I'd say you'll probably have to distribute a tool or multiple variants of a font to get the best results

I would be very interested in the development of a tool that performs font adjustments (if necessary) and proper alignment of the Powerline symbols in a platform specific way. I am much less excited about the manual development of multiple font variants to address this issue. If we can script this in some fashion, that is something that we can keep on the radar but any vertical metrics changes alter alignments of glyph sets that require line to line alignments (e.g. box drawing and block element glyphs). This is not as straightforward as it would appear at first glance. If users were willing to accept subsets of the full Hack glyph set that do not include these glyphs, perhaps this is an approach that would work.

In a few weeks time I may be able to commit some time towards it, I'll ping you if I start anything

There's a good chance in the next month or two I may be doing so at work at which point I could put something together for this too

Sounds great. Let me know and I will set aside some time as well.

[polarathene]

No nothing consistent across all platforms at any given size unfortunately.

I meant on a single platform/terminal.

This is not as straightforward as it would appear at first glance.

I'm aware :) I spent a lot of time figuring out how to manually adjust the glyphs myself and it only works properly at one font size on iTerm2.

Let me know and I will set aside some time as well.

Will do.

[chrissimpkins]

it only works properly at one font size on iTerm2

I think that this is the problem. There is likely not a glyph shape based solution that will work cross platform. I think that this will need to be a tool that modifies the glyphs in a platform dependent way.

[polarathene]

@chrissimpkins That's not what I'm asking. With your experience with fonts I'd assume you are familiar with how hinting works(I am not). Ignoring cross platform support, with a specific OS and terminal, does hinting fix the issue I had when manually fixing the glyph where it only worked for a specific font size?

If the finished tool can output the glyphs as a companion font to the main font or as a patched variant. Would it likely be Hack-Powerline-[OS]-[Terminal] or will it need to be more specific tailored to font sizes as well? If the latter I guess each user may have to run the tooling themselves which is unfortunate.

[chrissimpkins]

You can think of hinting as a set of instructions that provide the renderer with guidance on the expected pixel configuration at every text size. Many typefaces these days use automated hinting approaches that are based upon common/average font metrics. It is possible to manually modify these instruction sets in cases where the autohinter does not achieve the desired effect for specific glyphs or sub-glyph components. Modification of the hints used on the Powerline glyphs could (and likely would) address these slight vertical deviations in a platform/renderer/editor specific manner on platforms that respect the native hints that are used in the fonts. Here are a handful of the problems with a hinting approach:

1. OS X ignores native hinting in fonts
2. Many Linux distros have default FontConfig settings that ignore native hinting
3. TTF instruction sets (hints) and OTF hints are different and each requires a very different manual approach.
4. It is unclear to me how the Powerline (and variant) UI is being rendered and what our goal metrics are at any font size.

I'd be happy to give it a go in the TTF files if there is interest. For the Linux users out there, it would mean a slight modification to your FontConfig settings so that Hack fonts use full hinting if you are not currently using this setting (and as a side note, I recommend that you try this for all fonts that are manually hinted for the screen or you may be viewing subpar renders of your faces). OS X users will be out of luck as this should not influence their viewing experience.

We may be able to eyeball something that is better than what we currently have across some of the more commonly used combinations. If the hinting approach works in the TTF builds, the manual hints could be scripted with shell scripts in an editor/renderer specific way so that modifications to the glyphs would not be necessary. This would allow users to grab the script that addresses their particular combination, hint the fonts themselves, and use them.

If we still have any interest in testing among those following this thread who fall in the above category, let me know and we can give it a shot.

[polarathene]

@chrissimpkins Ah ok, so hinting isn't likely to help on OSX :(

As far as rendering goes, from what I understand the segments are using background colour which uses the full line height, and then after this you will get a powerline glyph such as the arrows as a character using a foreground colour like any other text. The background colour for that glyph will be the next powerline segment colour or the default bg colour if there are no more segments.

I'll get back to you on this when I can find the time to put something together :)

[aruhier]

Hello,
I have updated the Hack fonts on powerline repo to sync with the 2.20 release: https://github.com/powerline/fonts/pull/172

It's actually rendering great:

After that, I saw that Hack includes by default the Powerline glyphs, so I don't need to patch it. As I use ArchLinux, I modified the pkgbuild for powerline-fonts-git to not install the patched Hack fonts, and I use the package ttf-hack instead (version 2.20). Now I get some problems with spaces in arrows:

I'm using urxvt, and the screenshot has been done in neovim, with vim-airline.

Maybe you should take a look about how the symbols are in the patched Hack fonts I uploaded?

[chrissimpkins]

@Anthony25 Thank you very much for this information Anthony. How did you patch the Hack fonts? Was this with the patch script that Powerline releases?

Would it be possible for others in this thread to give the patched versions in Anthony’s PR a try to confirm that this is working across platforms & editors? If we can verify that I simply haven’t hit the correct set of shapes / metrics then we have a very simple fix and I can use the metrics in your patched versions. I sense that we have an issue with the way different renderers interpret the metrics in fonts and that this could be a platform specific problem. We’ve seen examples where alignments are very different (and in opposite vertical directions) across different platforms. This indicates to me that the solution may not be this simple, but I am all for it if it is and we will definitely implement it if that is the case.

[aruhier]

@chrissimpkins Yeah, I used their fontpatcher: https://github.com/powerline/fontpatcher
To be honest, their script is quite buggy, so you need to comment lines 117 and 118 to avoid a crash, but the generated font works for me.

[stefan-kern]

thanks anthony, i checked with the fonts from your pull request. it looks really nice now, lines up perfectly!

[chrissimpkins]

@stefan-kern Thanks Stefan, mind including your platform and editor?

[aruhier]

@chrissimpkins By the way, I asked to powerline if Hack should not be removed of their repo, as they don't sync it with your releases, and you already include the powerline glyphs anyway.

[Irubataru]

Just want to chime in and say that the fonts in the pull request also lines up correctly on my setup

archlinux, urxvt(v9.22), vim (v7.4 p1689)

[stefan-kern]

my setup (same as up above earlier): ubuntu 14.04 / fish shell / fisherman / agnostertheme / font size 12

[chrissimpkins]

Hack should not be removed of their repo

I submitted versions to them initially and it took a great deal of time for the PR’s to be accepted so I stopped. This isn’t a criticism, I understand this well. It just wasn’t serving our release schedule. I think it is useful to include them there. Many find that site when they are looking for new fonts with Powerline glyphs and I would like to maintain our sets as part of their releases even if older versions of the fonts.

[chrissimpkins]

@iirelu Thank you Anna!

@stefan-kern Thank you Stefan!

It sounds like we may have an approach for Linux/FreeType. Have either of you modified your default font-config settings on your platforms?

[aruhier]

@chrissimpkins Ok, I get it. Sorry if it looks like I by-passed you, that's really not my goal ;)

[chrissimpkins]

@Anthony25 Absolutely no problem at all. That decision is up to the Powerline developers and the community of users. It's not mine to make.

[polarathene]

I'll test this at work today with iTerm2 on OSX :) _fingers crossed_

[polarathene]

@chrissimpkins

11pt:

12pt:

13pt:

14pt:

None are perfectly aligned but they're only off by a minor amount, barely noticeable from a distance on a retina screen.

12pt prior to @Anthony25 PR:

12pt fix I did with GlyphsApp:

My fix for the 12pt only works on 12pt(I don't know font design well enough to know if there is a way to fix that), it was done through many manual tweaks until it looked right. At other sizes it breaks similar to original and PR.

I'm using a zsh theme called Powerline9k, not the python Powerline lib. I don't think the methods to render the glyphs would be too different, but there is a slight chance it's not the same.

[aruhier]

Could it be because I didn't patch the fonts with font-line? I mean I took the ttf of your last release, but the glyphs replaced by the Powerline script are not, are they?

Edit: my question wasn't clear. I meant: do the glyphs replaced by powerline need to be patched with font-line?

[chrissimpkins]

@polarathene Thanks for posting these Brennan. The new patched version looks good on OS X. Would the shapes/metrics in the patched version be acceptable based upon your view on the screen c/w the patch that you implemented?

[chrissimpkins]

@Anthony25

do the glyphs replaced by powerline need to be patched with font-line

No not at all. font-line modifies the default line spacing in the font. It is not a patching tool. We have discussed a tool that will patch new glyphs into the font but it hasn't been developed yet. As I understand the Powerline font patching script, there is a comparison of the metrics in the target font and the released Powerline glyph set. The Powerline glyphs are appropriately scaled and merged into the target fonts. There should not be any line spacing adjustments with that script and that is both intentional and a good thing.

[polarathene]

@chrissimpkins Just saw these pictures at home on my non retina screen(external laptop screen on linux). They appear blurry and you cannot clearly see the differences too well(Clicking them for fullsize helps).

On OSX I'm sure the PR patch is fine :) Not as many users would be as nitpicky as I am with the tiny (couple of pixels) vertical offsets. 14pt is really the only one that would bother me(right prompt specifically, left prompt looks fine). That may just be due to kerning(I think that is the term), similar to other cases where instead of pushed to the right it was pushed to the left causing a gap.

I can always send over my modified version for 12pt if it'd be of any help.

[chrissimpkins]

@polarathene Thanks Brennan. I think that we are good with these comments. I really appreciate your feedback.

[chrissimpkins]

Anyone else in the thread have comments on how the patched version looks in their Powerline or Powerline variant?

[eoli3n]

System : Archlinux
Aur package : ttf-hack-powerline-git
.Xresources : https://github.com/eoli3n/dotfiles/blob/master/.Xresources.d/rxvt-unicode

I xrdb .Xresources and updated font cache

[nharward]

On the issue of symbols appearing as too short (Linux): in my case it turned out that my high-density screen on a newer laptop was causing fonts not to display properly, as fontconfig appears to not pick up DPI correctly from the X server. Putting this in $HOME/.config/fontconfig/conf.d/10-hidpi.conf resolved the issue and now it looks great:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

<fontconfig>

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

</fontconfig>

Replace the 276 with the correct DPI of your display. Kudos to all the fine folks behind powerline and the fonts that make it look great.

[nullne]

I am wondering why there is a red block and yellow line on my status line?

This is mine:

This is normal:

[aruhier]

My pull request has finally been merged into powerline-fonts: https://github.com/powerline/fonts/pull/172

It should fix the weird rendering.

Edit: well, not entirely fix it, according to @polarathene screenshots, but it largely improves it on <=1080p displays.

[chrissimpkins]

PR in https://github.com/chrissimpkins/Hack/pull/234 that is aimed at Linux and Win Powerline glyph users. Would greatly appreciate your feedback on the test font files there to confirm that there is an improvement in rendering that addresses these issues on those platforms and doesn't create significant new issues on those or OS X.

Thanks!

[rage311]

I tested the HackTest4 attachment from PR #234 and it has fixed the issue for me entirely -- both with the agnoster theme in zsh and the powerline (airline, really) in vim.

My system:
Arch Linux
rxvt-unicode 9.22
freetype 2.8

.Xresources file:

URxvt.font:         xft:Hack Test 4:pixelsize=12:antialias=true
URxvt.letterSpace:  -2

!-- Xft settings -- !
Xft.dpi:        96
Xft.antialias:  true
Xft.rgba:       rgb
Xft.hinting:    true
Xft.hintstyle:  hintslight
Xft.lcdfilter:  lcddefault
Xft.autohint:   0

Please let me know if I can provide any other relevant information. Thanks for this font, too. I'm a big fan of it.

[chrissimpkins]

👍 👍 👍

@rage311 thank you! This PR will be merged in the v3.0 release.

cc: @iamjamestl see https://github.com/chrissimpkins/Hack/issues/33#issuecomment-313724919

Thanks for this font, too. I'm a big fan of it.

Our pleasure!

[chrissimpkins]

We are planning to merge the changes from @iamjamestl in #234 as part of an upcoming release. Once he has rebased his modified glyph source on our new source code (part of the v3.0 release transition) I will build files with our new build tool chain and notify all here so that you can give them a try. @iamjamestl has performed a great deal of testing on Linux. It would be very helpful to have feedback from OS X and Windows users of Powerline/Powerline style terminal UI's that use these glyphs as we prepare for the release.

Will notify here when they are available for anyone who is willing to help with testing. Thanks in advance! And thanks to @iamjametl for the extremely detailed attempt in #234 to fix these problematic glyphs! The images that he posted there look fantastic. Hope these changes work for all.

[chrissimpkins]

New development build files with @iamjamestl Powerline glyph changes are now available in the dev branch.

Desktop files are available on the path build/ttf and web font files are available on the path build/web.

The current build files are labeled Version 3.000; 1e373f5-dev

These changes should significantly improve rendering of Powerline glyphs on Linux and Windows platforms. Please let us know if you have any problems. These changes will be released as part of our upcoming version 3.0 release.