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?

[haktrik]

@chrissimpkins , yes I think I can setup, but there is somewhere instruction for that? Thanks

[chrissimpkins]

@haktrik excellent! believe that this will be the first time that someone has tried to build with the new build tool chain on Windows (which in and of itself will be very helpful information). We are using a make build workflow. You have access to MinGW or Cygwin?

Build dependency install instructions and build instructions are here: https://github.com/source-foundry/Hack/blob/dev/docs/BUILD.md#automated-build-dependency-installation

[chrissimpkins]

The build tooling all currently lives in the dev branch of the repository. Can work in that branch which is current with all work at the moment.

[texhex]

@haktrik I tried to reproduce this problem on my two Windows 10 v1703 machines with Notepad++, but wasn't able to get the odd looking "1" here.

Could you please use Notepad++ and check if the rendering issue also appear there? This would help us to identify if this a general hinting error or somewhat related to Visual Studio/ VS Code. Thanks!

[haktrik]

@texhex Yes, indeed I still have same issue...
Here is screenshots:

At my case for Notepad++,VS2017 problem ocurr when switching font size from 11 to 10
11 look fine, but I preffer smaller font size.

Here how its look at latest VS Code

This screenshots I've took on windows 10 1703, 27" 1920x1080 and dpi 105%(if set 100% problem persist)
Same problem I'm experiencing on second work machine which is Lenovo P50, windows 7 and FHD screen.

Thanks!

[texhex]

@haktrik Thanks for the extra effort and strange that you can also see the issue in Notepad++ and in Windows 7, which destroys my initial idea that this might have something to do with font scaling. I have created new screenshots from my secondary machine and used the Magnifier tool. Maybe the issue is there but I'm just to blind to see it.

Let me check with the glyph masters and then get back to you.

[haktrik]

thanks @texhex. BTW, please take a look on other issue raised here:
#313
If you will look at screenshot, I think "1" have same "defect"

[chrissimpkins]

@haktrik thanks for linking this. The user in the thread that you linked is using a JetBrains editor and I can verify that they use a Java font renderer, believe across all platforms. Do you happen to have any JetBrains editors installed to see if a switch in the renderer modifies this issue on Win? Not certain what approach is being used in Visual Studio and Notepad ++.

[chrissimpkins]

This may just be a design issue and we are seeing a 'nose' due to pixel orientation of the very minimal angle off horizontal at smaller sizes. A change in the stem there may address it. We are going to be looking at the 1 v i v l too. Will wrap this into that work.

[haktrik]

Here screenshots from Raider of Jetbrains
12

13

14

15

Suprsingly when I set weight to bold at VS Code, "1" look bit better even on small size:

[chrissimpkins]

Thank you! We will experiment with this a bit to see if we can find an improvement that works here and for other issues with the 1 glyph.

Will be in touch when we have files available for testing. Thanks @texhex for looking into this too!

[haktrik]

thanks @chrissimpkins . Looking forward!

One more thing I have spotted.
Take a look at this screenshot: brackets not look symetric:

Maybe it somehow related with "1" rendering

[chrissimpkins]

I am going to consolidate the 1 glyph work down to a single IR thread over here:

#43

Please join us there for the conversation as we make changes. We will revise this glyph to address all of these issues in our next release. Initial iteration of design changes are posted in an image in that thread and I will push fonts that you can test once I complete the rest of the sets.

For the brackets/braces/parentheses issue, please feel free to weigh in over in this thread:

#120

@burodepeper will be working on all of these glyphs for an upcoming release. In addition to possible vertical alignment issues, there may be some changes to the shapes and horizontal spacing adjustments that we perform. Let's keep that discussion in that thread.

Thanks for reporting here. Join us in the other threads for these conversations.