Number 1 looks too much like an l letter

[LeoNeeson]

The "l" letter is fine, but the "1" number may still lead to confusion, since is similar to the lowercase letter "L" in many fonts. To me, the "1" number must be like this: http://i.imgur.com/pHeeYIJ.png

[chrissimpkins]

Can you let me know what pixel size you are working at and the platform you are using this on? Might be a hinting/instruction issue if the glyphs begin to look similar.

[LeoNeeson]

I'm using the normal display size at 72 PPI "DPI", using a Mac OS system. But this it's not exactly about resolution/system configuration, it's more about design. What I'm trying to explain, is that any newcomer to your font, "may" confuse the number "1" (of your font), with the lowercase letter "L" (in many other fonts). I'm not saying that the "l" and "1" are identical in your font.

But that it's up to you (and the community), since there are a lot of fonts to choose. If you are happy with the current "1" number, great. I've reported this, because IMHO this is a problem to me, but I don't mean it's a problem to everyone. It would be great to hear the opinion of other people to see if they agree on this or not. It's a design choice, not a bug report.

[willfroning]

I agree. When you see the "l" and "1" next to each other it's obvious which is which, but having a downward slope to the "nose" would more clearly define its identity.

[chrissimpkins]

@LeoNeeson Point well taken. I ask because I am working on the optimization of the TT instructions and wanted to see if there might be a way to optimize it as is. To my eye in that image, the stroke height on the 'l' vs. '1' (taller 'l' glyph) and the curved tail vs. flat bottom serif look distinct. The problem is that these nuances tend to disappear as we challenge the glyphs to fit the grid at smaller pixel sizes. Height differences generally disappear and curves may be rendered as flat in which case, it would look exactly like the 1. I will take a look into this in more detail.

Let's leave this open for more discussion.

[chrissimpkins]

Queued up to get started on this. Will post some design examples in this thread if you are willing to participate as we improve on the shape.

[LeoNeeson]

Okay, I'll be here to give my opinion.

[chrissimpkins]

I am going to push this issue back a bit. @burodepeper is analyzing a number of usability issues in the fonts and we are going to spend a bit more time on the evaluation of this glyph (and others) before we begin a new design. Our hope is to apply a more rigorous, objective approach to these usability issues and we have a number of tools in various stages of planning and development to assist with this. We will have a great deal more information about this once they are in place. We are actively discussing this in Slack and will bring the conversation about the 1 vs. l to this thread when we begin the development of a new glyph style. Will update here when more information is available and a proposed fix is available for your review.

[bkromhout]

Came here from #103 and will be watching for updates to this. The original issue I had was actually with i vs l, though I also agree with the 1 vs l discussion going on here.

I'll refrain from further comment until the new approach is revealed that is mentioned in the above comment, but for continuity will add that I feel that the i looks too similar to l due to the bottom of the glyph being nearly identical.

Also notable from 103 is that these issues intensify when I'm using my 1080p external monitor (vs. the 15" retina display in my MBP).

[burodepeper]

Hi everybody,

As @chrissimpkins mentioned, I'm working on analyzing these issues and improvements. In the mean time, it would be incredibly helpful if you could supply us with screenshots of situations where any of the issues mentioned above actually hindered you.

Let me put it in a different context. I am not only analyzing the abstract visual difference between two characters; I am also analyzing them within their context. For instance, the i in the word this is less 'important' than the i in var i = 0.

I am curious to any situation where you had to look twice at a character, just to be sure, or where any such confusion caused an actual bug that you had been hunting for hours. And let me be the first to say that Hack isn't perfect, because it was I (in the voice of Severus Snape) who failed to see the difference between a : and a ; in a simple piece of code in an environment without syntax highlighting, linting, or any useful error logging. And it is my goal to fix these issues in such contexts.

[tflo]

I “discovered” Hack just recently and the similarity of 1 to l (as used in other fonts) was exactly the first thing I stumbled upon. @LeoNeeson’s post describes the issue very well.

I admit that the problem has become less of an issue once my brain has adapted to the Hack glyphs, since the Hack-1 is definitely distinguishable from the Hack-l. But, for example, when coming back from another (not Hack-using) editor/program to my Hack-using editor there is still a moment of confusion.

I imagine a more downward slope could help.

– Tom

[chrissimpkins]

Slated for work in the next release. Keep an eye out for it! Will post info / images as work goes on.

[chrissimpkins]

First iteration of 1 vs. l modification of 1 glyph:

Large render of shape change

At small size

Shape vs. other numerals in set

[LeoNeeson]

Looks great, I like the new shape.

[haktrik]

Yes, this 1 in this design looks much better. 👍

[chrissimpkins]

@LeoNeeson @haktrik ty both for having a look. I will finish the other three sets and then build fonts that we can test at actual source code size to make sure that we have the angle correct. Will examine the hints as well to see if we need to modify anything with the change in shape. Will post here when I have a branch with the fonts available for download and testing.

Possible as we take these down to size in use that we may need to extend the length of the flag at the top of the glyph. Currently aligned with the slab width at the bottom and may look terrible at large sizes but extra length may better distinguish from l at small sizes. Let's see what pixels we pick up as is.

[chrissimpkins]

Here are the changes in all four sets as of 379b3ad

[chrissimpkins]

See pull request #347 for a full description of changes and link to the testing files that you can use to confirm that these design changes address this problem. Let's continue the conversation on the pull request thread for any necessary changes to the current state of the design. Once we have an acceptable set of designs, I will evaluate the instruction sets, update as necessary, and we will plan to include these changes in the v3.001 release.

[chrissimpkins]

Also designed alternate numeral one styles that include these upper stroke changes without the bottom slab. These are in the alt-hack repository and can be compiled into custom fonts if this works better for you.

https://github.com/source-foundry/alt-hack/tree/master/glyphs/u0031-noslab

Compile instructions available on the README for that repository.

[haktrik]

Thanks @chrissimpkins for rapid amendments of these glyphs. I've already tested on my IDE's and its works perfectly as I was expected. It's clearly visible even on small font sizes. One issue I have only with Jetbrain editor. But you probably saw already this issue. Someone reported similar:

It's strange output seemb be somehow offset character? When I'm pressed "1,2,3,4,5,6" I getting strange symbols. But when I've pressed '7' I'm getting 1, when 8 getting 2. But design of 1 itself look fine.

ps. Alternative without slab look also cool, I will try test it!
Great Job. Thanks

[chrissimpkins]

@haktrik thanks! Will you please add this information about incorrect JetBrains renders in that thread and confirm there that this is on Windows?

Thanks again.

[chrissimpkins]

these changes were merged into the dev branch in 9cb3c2d and will be released in v3.001

[chrissimpkins]

Thanks all for your suggestions and help with the review of the glyph changes!