Hack: Hyphen and en dash

[tflo]

Something seems wrong with the hyphen and the en dash:

This is Hack on macOS 10.13.4:

IMO the en dash should be visibly larger than the hyphen, not reverse.

It’s the Hack release version (Version 3.003;[3114f1256]-release; ttfautohint (v1.7) -l 6 -r 50 -G 200 -x 10 -H 181 -D latn -f latn -m "Hack-Regular-TA.txt" -w G -W -t -X "")

For comparison, this is DejaVu Sans Mono, which looks more reasonable (hyphen and en dash):

– Tom

[jdw1996]

I agree that the en dash should probably be longer than the hyphen, but I also don't like how short the hyphen is in DejaVu Sans Mono. I'd be OK with the hyphen being a bit shorter than it is at the moment, but I can't think of a situation where I'm looking at an en dash (or an em dash) in a monospaced font. Out of curiosity, what is the use case where you noticed this?

[chrissimpkins]

This was addressed a few versions ago. Here is what we landed on: https://github.com/source-foundry/Hack/issues/178#issuecomment-350862403

Happy to re-evaluate if you feel that it needs to be modified further. I used Bringhurst's definitions for these glyphs to define the current widths.

[chrissimpkins]

And note that others had complaints that some of these look too similar in the DJVSM design... https://github.com/source-foundry/Hack/issues/178#issuecomment-247572689

I suppose it depends upon use cases. The goal at that time was to distinguish the different code points.

[tflo]

This was addressed a few versions ago. Here is what we landed on: #178 (comment)

I’ve seen that discussion, but something must have changed, because in the screenshot posted by @jwheare the hyphen is clearly shorter than the en dash. (The rest of the discussion is mainly about the length of the figure dash, a char that I’m not using.)

I’m aware of the benefit of a better visible, longish hyphen character, since in code you are not using any other dashes and thus making it look like an en dash seems like a good solution.

My situation is that I’m using Hack also for TeX (ConTeXt) with prose in German. In German both the en dash and the hyphen is used frequently (the en dash has —roughly— the same role as the em dash in US English), and so the inverted dimensions of the two chars are confusing.

On the other hand the same ConTeXt source usually also contains code (TeX and Lua).

So, my ideal solution goes in this direction:

• in any case the en dash must not be shorter than the hyphen
• hyphen should be (slightly) better visible than in DejaVu Mono

This screenshot is IBM Plex Mono, which seems like a not too bad solution to me:

– Tom

[jdw1996]

In LaTeX, at least, you can use two hyphens (--) to get an en dash (and three for an em dash). I understand if that doesn't work in the implementation of TeX you're using, or if you just prefer using Unicode characters, but otherwise it might help reduce ambiguity.

[tflo]

You can do that (--) also in ConTeXt, but, indeed, I prefer using “real” (UTF-8) chars. (Makes it easier to paste the text around, outside of TeX, and also reduces trouble when the source text goes to the translator. Many translators (or the software they are using?) have difficulties understanding the TeX-typic notations like --, ---, ~, etc.)

-- and friends are mainly a leftover from ISO-Latin days…

– Tom

PS/Edit:

I have to correct myself: I’m stll using (most of the times) ~ instead of U+00A0 (no-break space). But this is for reasons of visibility (in the proper sense of the word, since a no-break space is indistinguishable from a space, no matter what font you are using). [1] But the proper representation of hyphen versus en dash is a thing that is in range of a font.

But maybe I should really go back to using --? Thinking…
… or using another font, at least for TeX stuff…

[tflo]

Well, to sum it up, what I think is this:

• It is an absolute no-go to to make the hyphen (U+002D) longer than the en dash (U+2013), even for a monospaced font.
• It is important (since the main purpose of the font is code) to have a good visibility of the hyphen; DejaVu’s hyphen is pretty tiny, so, it must be something better visible, but _without_ gulping the en dash; or even inverting the dimensions.

– Tom

[l3u]

I recently started to use Hack and this issue hit me – I first thought, the way to input an en dash has been changed, but then I found this discussion.

The issue is at least still present in version 3.003:

Clearly, the Hyphen-Minus is longer than the En Dash – and it really should be vice versa. Would be nice if this could be fixed … it almost stops me from using Hack at all …

[chrissimpkins]

@l3u Thanks for the feedback Tobias (and Tom). Do you mind posting a sample body of text that you are working in so that I can view this how you are viewing it?

Here is where we are as of v3.003 (order = em dash, en dash, hyphen):

I am happy to revisit this issue and adjust the width of something (perhaps the hyphen, perhaps the en dash) to make these distinct and achieve both of your suggestions that the width of the hyphen should be shorter than the en dash. To my knowledge, en dash is not commonly used in source code and this may be the shape that changes to address this issue unless we find that there are other improvements in source code associated with decreased width of the hyphen glyph. Changing the hyphen definitely affects source. I will take a detailed look.

For my future reference: https://practicaltypography.com/hyphens-and-dashes.html

[chrissimpkins]

While we are at it, can we discuss vertical orientation for the en/em dashes too? May as well address that if changes are needed while we are working on these shapes!

[l3u]

Here's the clear text of the (KWrite) screenshot I posted above:

U+002D - Hyphen-Minus
U+2013 – En Dash

Surely, the en dash is not commonly used in source code, but I e. g. noticed this whilst working on a (German) rst file source where I use it. And also inside text-only emails.

I don't know what's typographically correct, but I think LaTeX is always correct ;-) So here's what LaTeX does:

The hyphen is a bit thicker and a bit below the en and the em dash, which are a bit thinner. So speaking of your image: the hyphen should be as wide as the en dash is now, the en dash should be as wide as the hyphen is now, the en and em dashes should be as high as the hyphen is now and the hyphen should be as low as the en and em dashes are now. Here we are ;-)

[chrissimpkins]

I built a set of fonts with changes in the regular set only that get us here (displayed as em - en - hyphen):

Attached as zip archive below and based on the v4.000 changes in https://github.com/source-foundry/Hack/pull/457 so you will see other shape changes that have happened since v3.003. Let me know what you think.

ttf.zip

[l3u]

This looks way better :-) I would still swap the vertical orientation (as LaTeX does) though.

[chrissimpkins]

I would still swap the vertical orientation (as LaTeX does) though.

Will give this a try, make the mods across sets and push a new set of fonts that you can use for now. These changes will make their way into the next release. Thanks again for the feedback here!

[l3u]

Nice :-) Thanks a lot for fixing this!

[tflo]

Luckily I came across this old thread while cleaning up my issue subscriptions. In the meantime I had abandoned Hack, mainly because of the faulty en dash.

Attached as zip archive below and based on the v4.000 changes in #457 so you will see other shape changes that have happened since v3.003. Let me know what you think.

This… is very nice and virtually perfect!

---

For comparison again the old and the new version:

---

And here some real-world prose:

_Confusing:_

_This works:_

---

IMO, the new solution is quite perfect in all criteria:

• En dash not shorter than hyphen (important for monospaced prose, for example when doing TeX)
• Hyphen has has better visibility than with Deja Vu (important for normal code)
• Bonus: em dash clearly distinguishable from en dash

I think, it’s even better than IBM Plex now!

Many thanks for the update!

– Tom