Pre-3.0 fonts appear taller than 2.x at normal screen sizes

[jameslikeslinux]

I've compiled the latest fonts using make ttf on the dev-hints branch and find that the height of the text in my terminal appears taller than the current release version. For example:

v2.020:

v3.0@0d6a4a4:

(All screenshots are at size 9 with FreeType 2.8 and full hinting enabled, though this behavior occurs at other nearby sizes, like 8, 10, 11, and 12. It is not an issue at large sizes.)

This might be a taste thing, and you could say it's just something I'll have to get used to, except that I think one of Hack's greatest features, even if it is unintentional, is that it is metrically compatible with DejaVu Sans Mono, which has significantly more coverage. That allows me to use DejaVu as a fallback and it looks absolutely seamless:

v2.020:

But with the taller rendering on v3.0-pre, falling back to DejaVu looks really bad and obvious:

v3.0@0d6a4a4:

I was able to mostly restore the appearance of the pre-3.0 font to the v2.x appearance by disabling the automatic x-height adjustment in ttfautohint by passing it the -X '-' flag in build-ttf.sh (interestingly, setting -x 0 didn't do anything, but the note about the -X flag in the "Windows Compatibility" section of the ttfautohint documentation set me on the right track).

v3.0@disabled-x-height-increase:

Without ttfautohint messing with the x-heights, Hack and DejaVu blend together as I expect. There are still some differences between this and v2.x, namely:

1. The cap-height is still larger, even with the ttfautohint x-height adjustment disabled. This is noticeable in the screenshots in the upper left where it says 1: UTF-8.... In v2.x, that is centered on the line. In both the other screenshots, it does not appear centered because it is taller.

2. Some glyphs look different/worse without the automatic x-height setting. Namely, e. The eye in e in v2.020 is rendered very open. Presumably, the extra x-height that ttfautohint applies keeps it looking very open in the pre-3.0 builds too. But without the extra x-height in my tweaks to 3.0, it looks very small.

[chrissimpkins]

1) Confirming that your v2.020 is ttf and not otf build. It looks like there is some clipping at the top of the upper case U in the v2.020 that you are displaying and I believe that was something reported in our otf builds. See Unicode in top image.

2) What glyphs in DJVSM are you commonly requiring for fallbacks and what is your primary use scenario for Hack?

3) My initial impression is that the body of text that you display is clearer both at standard screen reading range and when I step back 5 feet from the screen with the new metrics. I think that the increased x-height greatly improves legibility of the glyphs at the size shown here. If you set aside the fallback font concern, do you feel that the metrics changes improve or detract from how source code is viewed on your screen? This has been our primary design objective here. Maybe capture a few examples of bodies of source code text in your editor with the two versions and we can discuss based upon what our primary design target has been.

This might be a taste thing, and you could say it's just something I'll have to get used to, except that I think one of Hack's greatest features, even if it is unintentional, is that it is metrically compatible with DejaVu Sans Mono

DejaVu Sans Mono and Hack are both forks of Bitstream Vera Sans Mono. They all use the same metrics. We have DJVSM glyphs in the Hack sets and you can expand a Hack fork with any of the glyphs from DJVSM (including the entire sets there if you are really in need of a broad range of glyphs), then rebuild.

We could consider supporting this issue for users who need the expanded glyph set range of DJVSM as a fallback by releasing unhinted ttf builds so that you can hint on your own? As you have demonstrated to yourself, this is a simple one liner and perhaps we add information to our documentation about how to achieve this with unhinted builds and create a separate build script that ends at the compilation step short of hinting. This likely would require a change in the manual hint adjustments that we add on the automated hinting provided by ttfautohint.

Thoughts?

[jameslikeslinux]

1. Confirmed I am testing with the TTF version. I even got Gentoo to switch over to TTF.

2. Nothing in particular, except as a systems administrator at a major university with:

> wc -l /etc/passwd
74332 /etc/passwd

over 70,000 users, it is not uncommon to encounter unusual character sets, and I need to be able to distinguish, for example, different Japanese filenames, even if I can't read them. I don't know of any monospace font that beats DejaVu in terms of coverage.

DJVSM has problems, of course. The '-' is too narrow. The '*' is small and unclear. The serifs are old-fashioned. That is why I was excited about Hack--to me, it fixed the problems I saw in DejaVu while being backwards compatible with it. Perhaps I misunderstood that goal.

3. Again, this is likely to be a thing of taste, and you're the designer, but from my point of view, I have at least 13 years of history coding in Bitstream Vera and then DejaVu and now Hack, and they've all mostly had the same overall shapes. Short and round. For example, this screenshot of mine from 2005 with Bitstream Vera Sans Mono:

Short, almost perfectly round 'o's and 'p's and 'g's. That shortness to me makes the glyphs seem wider than they are and that emphasizes the monospace quality of the code. It provides for breathing room between the lines. For example, Hack up to v2.020, maintains these qualities:

You can see that Hack up until now has preserved the same overall shapes and spacing as the Bitstream Vera font I used in 2005, and that is very comforting to me. It's airy and relaxing to read.

By comparison, the new x-height of the pre-3.0 builds looks congested, and because the glyphs appear taller (with oblong 'o's and 'p's and 'g's), it looks more like a standard proportional font. It's crowded and stressful to read.

The change is jarring and unexpected.

[jameslikeslinux]

I just want to make one more comment in favor of the old (I'd say "normal") hinting behavior:

In v2.020, it was always possible to achieve what the pre-3.0 version looks like at runtime in FreeType by enabling the "slight" hinting property. I believe distros like Ubuntu have this on by default, and I can speak for Plasma to say that there are user friendly GUIs for making the change:

v2.020 with "slight" hinting:

It looks tall like the pre-3.0 builds do, and just as sharp. But when that style of hinting is hardcoded into the bytecode, it takes away my ability to configure it at runtime how I like.

[chrissimpkins]

ttfautohint hints use the vertical instruction sets (at least a very close approximation) of the FreeType autohinter. I don't have a great deal of knowledge about the hinting style configurations in FreeType, but here is what the documentation says about the 'slight' hinting setting (you are correct, this is default on Ubuntu):

Setting ‘slight’ hinting usually leads to FT_LOAD_TARGET_LIGHT. This mode implied the auto-hinter before and has now been changed to mean “Use native vertical-grid-only-snapping if driver and font supports it and vertical-grid-only auto-hinter otherwise”.

Unclear to me what this means on the Gentoo distro. My best guess is that slight is showing you the FreeType autohinter in action and that the ttfautohint settings are now in line with FreeType autohinter default vertical hint settings as of our most recent changes. This addresses your comment:

(I'd say "normal") hinting behavior

If I am interpreting 'slight' hinting correctly (and if it is in fact using the FreeType autohinter on Gentoo, not a distro specific hinting approach) I suspect that we are actually at what is "normal/default" vertical autohinting for FreeType (and were not with previous releases). I'd be interested in how DJVSM renders with slight hinting setting on. Does this cause those fonts to render in the same fashion (taller + greater x-height) when you let FreeType use default autohinting algorithms?

Here is the link if you'd like more information on FreeType specific rendering issues: https://www.freetype.org/freetype2/docs/text-rendering-general.html

Let's leave it open and see if anyone else comments. We also need to evaluate on other platforms, including other Linux distros with their default settings. Having said that, it is impossible to optimize for every possible platform x renderer x application combination.

My initial suggestions to address your specific issue are:

1) we could release unhinted fonts that users can hint however they like on their own so that they work in their specific combination of the above factors that influence renders 2) we can create a build script that allows users to compile ttf fonts that are not hinted so that they can build from source and access them at the pre-hinted stage for modifications of the hinting process in place 3) you can fork and maintain a DJVSM metrics consistent fork of Hack intended for those on Linux platforms who have similar concerns. We would be very supportive of this and I would be happy to pitch in however I can to help you get our tooling working for you (if needed). The change in licensing and new build toolchain are intended to support very simple fork + modify + build approaches for anyone who wants to maintain downstream modifications that target specific needs (very much including needs that are aesthetic differences of opinion from our own - we have received a number of suggestions along those lines). This is one of my primary goals with this major release. I want others to fork Hack, make changes, and release good things that target specific issues (e.g. expanded glyph sets, different glyph variants, ligatures for source code, platform specific rendering, aesthetic changes). We very much want this project to be viewed as a solid upstream base glyph set for source code (and to some degree terminal use, though source code rendering is our primary design priority) rendering that can be used by downstreams to target anything that they want. Downstreams can merge any upstream changes that they like, and none of those that they don't as further changes come along. I have learned over the years that we will never make everyone happy across all of the combinations of factors that infleunce rendering - see your own outstanding PR =) (and use cases). 4) You could develop and maintain a Gentoo redistribution package for Hack that builds from source and hints however you would like for Gentoo's default configurations. We have individuals on a number of Linux distros who are doing this. The new license will allow you to call these fonts "Hack" irrespective of the design decisions that you make following the source build as we are removing the reserved font name with the new license as of v3.0. We view these redistribution packages very much as forks and defer to the package maintainers to deal with issues that come up with their redistribution approaches (this means though always happy to pitch in on our end we will point issue reports for packages to the package maintainer, not triage and troubleshoot here).

[chrissimpkins]

cc @burodepeper here to see if he has additional comments/thoughts

[jameslikeslinux]

DejaVu exhibits the same behavior in response to slight and full hinting as did previous versions of Hack:

DejaVu full hinting:

DejaVu slight hinting:

I'm totally with you that it is impossible to satisfy everyone, especially when it comes to hinting, which is entirely about making decisions on how to compromise the vector glyph to fit a pixel grid. Both "slight" and "full" hinting at these screen sizes are not ideal representations of the typeface, but that's why I like to have the choice.

In any case, I already maintain my own ebuild at https://github.com/iamjamestl/portage-nest/blob/master/media-fonts/hack/hack-2.020-r9999.ebuild so as long as it is easy to configure the ttfautohinter behavior at build time, I can get what I want. Other users may not be so lucky.

Some day we'll all have 300 dpi screens and none of this will matter :)

[chrissimpkins]

Some day we'll all have 300 dpi screens and none of this will matter

👍 👍 👍 the sooner the better!!!!

so as long as it is easy to configure the ttfautohinter behavior at build time

As of now, hinting begins at this line of the build script: https://github.com/source-foundry/Hack/blob/dev-build-scripts/build-ttf.sh#L171

Simple modification to whatever ttfautohint settings you like. Note each of the four variants are hinted with individual commands so you need to replicate the change for each.

[chrissimpkins]

As a side note, adjustment of the ttfautohinting defaults may lead to the need to modify the manual hinting adjustments in the control instructions files... Our manual hinting adjustments (for issues where ttfautohint doesn't get it quite right) are composed with the current hinting settings for ttfautohint.

[chrissimpkins]

Here is an example of v2.x Hack on OS X:

This is what I view daily which is probably why I see your pre-v3.0 render as "normal" :)

Renderers...

[burodepeper]

My two cents are that the v3.0 example in OP is what Hack is "supposed" to look like, but I definitely understand the unsettling feeling of a typeface suddenly feeling off. I must admit that I've more or less skimmed through the entire thread, but if clear build instructions with different types of hinting solve the problem, I think that should be enough, especially given the relative familiarity of the userbase with such processes. @chrissimpkins We do need to be sure that the build process is as smooth as possible, but I'm sure you'll have your thoughts on that already.

[jameslikeslinux]

I got some shots of 2.020 and my pre-3.0 build on Windows 10 and find them to look identical:

2.020 on Windows 10:

pre-3.0 on Windows 10:

I would agree that the new "taller" rendering under FreeType more closely matches the Windows and MacOS rendering, so I guess I should just try to start getting used to it now. Sorry to make a big fuss about it.

[jameslikeslinux]

With 'slight' hinting enabled, the pre-3.0 build of Hack and DJVSM blend together just as they did before:

It feels a little wrong to have to change the hinting setting for my whole desktop just to get two fonts in the same family to look right together when I didn't before, but given that a) I understand the problem, b) I know how to workaround it, and c) you the designers prefer the new rendering, I'll close this issue. I think if others start to notice this same issue, I'll volunteer to make it a build-time option.

[chrissimpkins]

@iamjamestl

so I guess I should just try to start getting used to it now. Sorry to make a big fuss about it.

It's a simple fix if you want to modify it!

Sorry to make a big fuss about it.

No worries at all. We want it to look good everywhere to everyone. It's a frustration for us too. Happy to help you get to the look that you like if there is something that we can simplify.

I'll close this issue. I think if others start to notice this same issue, I'll volunteer to make it a build-time option.

Let me know if you need us to make any modifications here to support this. Happy to release pre-hinted builds or make a new build script if that helps.

@burodepeper

We do need to be sure that the build process is as smooth as possible

completely agree with this comment :+1: