Problems with "1" (U+0031) on small font sizes [Windows]

[haktrik]

Hi Hack font Team!
I've noticed that v3.0 is in progress, I'm wonder if any chance to update "1" glyph which look poor on small sizes. I'm ususally using font size <=10 on FullHD 27", however "1" look strange. When I'm increase size to 11, glyph look fine, but overall size of font is too big. Here is example

I would expect something like that:

This is only one issue which blocking me with fully enjoying this great font.
Thanks!

[chrissimpkins]

That is odd. It looks like your renderer is clipping the tops of the number glyphs for some reason. Seems to be happening on the 2 and 3 as well.

Can I ask you to provide the information in https://github.com/source-foundry/Hack/blob/master/CONTRIBUTING.md#issue-reporting so that we can look into this?

Similar issue reports:

• Number 1 looks too much like an l letter #43
• "1" glyph rendering on small sizes #249

legibility issues:

• https://github.com/source-foundry/legible/issues/1

[haktrik]

Font version is dev v3.0.
I took it from here:
https://github.com/source-foundry/Hack/tree/dev/build/ttf
Selected font is regular.
Font sizez which can spot problem: <=10
Example:
10pt.

11pt look better: (but then overall font size is too big for my needs)

Here is screen from VS Code, "1" as well has some rendering glitch.
Size 13(its diffrent sizes than visual studio)

"1" look fine when size >=15 (which again is to large for me)
My windows version (windows 10 1703)
Visual Studio 2017 latest 15.3.5
VS Code latest 1.16.1

[haktrik]

Here I'm adding for comparsion screen from DejaVu Sans Mono-which is very similar to hack. Selected size 10pt at vs2017

I have same issue, on all my machines(work station,laptop and office)

[chrissimpkins]

Thank you very much for adding the additional information and screenshots. Will take a look at the hinting at those sizes to confirm that there is not work that we need to do there. Can you confirm that there are no adjustments that we need to make.

Are the light grey lines in the images coming from the editor (e.g. some GUI display of selected line/current line) or did you draw those in? If they are being rendered in the editors, can you confirm that when you select a different line (and the lines are not rendered around the numbers) that you do not get an additional line of pixels back? It looks to me like an entire row of pixels is being removed from the top of all of those glyphs.

[haktrik]

Thanks for quick update Chris. This gray border is just default row selection marks from VS Code. Yes, its look like pixels row is cut from top. Since I'm using Hack, I've always can see this problem, version 2 or dev build 3.

[chrissimpkins]

Hmmm... sorry to hear that. Wonder if we need to modify the Windows metrics in some way. Will start by having a look at the hinting. We might be able to clean that up in a way to make it usable for now until there is a definitive repair for the issue.

[chrissimpkins]

Here is where we are in the design:

[chrissimpkins]

and here are the renders with hinting at sizes 8, 9, 10:

8:

9:

10:

[chrissimpkins]

Nothing at those sizes appears to have that "hook" appearance at the top of the one glyph.

@texhex are you seeing the same thing on Windows? (See OP)

[chrissimpkins]

Adding this from the ttfautohing documentation here so that we can look into it. We use this flag in the hinting with ttfautohint:

--windows-compatibility, -W

This option makes ttfautohint add two artificial blue zones, positioned at the usWinAscent and usWinDescent values (from the font’s OS/2 table). The idea is to help ttfautohint so that the hinted glyphs stay within this horizontal stripe since Windows clips everything falling outside.

There is a general problem with tight values for usWinAscent and usWinDescent; a good description is given in the Vertical Metrics How-To. Additionally, there is a special problem with tight values if used in combination with ttfautohint because the auto-hinter tends to slightly increase the vertical glyph dimensions at smaller sizes to improve legibility. This enlargement can make the heights and depths of glyphs exceed the range given by usWinAscent and usWinDescent.

If ttfautohint is part of the font creation tool chain, and the font designer can adjust those two values, a better solution instead of using option -W is to reserve some vertical space for ‘padding’: For the auto-hinter, the difference between a top or bottom outline point before and after hinting is less than 1px, thus a vertical padding of 2px is sufficient. Assuming a minimum hinting size of 6ppem, adding two pixels gives an increase factor of 8÷6 = 1.33. This is near to the default baseline-to-baseline distance used by TeX and other sophisticated text processing applications, namely 1.2×designsize, which gives satisfying results in most cases. It is also near to the factor 1.25 recommended in the abovementioned how-to. For example, if the vertical extension of the largest glyph is 2000 units (assuming that it approximately represents the designsize), the sum of usWinAscent and usWinDescent could be 1.25×2000 = 2500.

In case ttfautohint is used as an auto-hinting tool for fonts that can be no longer modified to change the metrics, option -W in combination with ‘-X "-"’ to suppress any vertical enlargement should prevent almost all clipping.

Will need to look at these vertical metrics values and can attempt some modifications of the hinting approach to see if we fix this.

[chrissimpkins]

@haktrik are you available to set up a local development environment so that we can test some different build configurations in order to see if we can find a fix for this issue?