Closed tflo closed 5 years ago
jdw1996
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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:
This screenshot is IBM Plex Mono, which seems like a not too bad solution to me:
– Tom
jdw1996
commented
6 years ago 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
commented
6 years ago 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…
[1]: And this in line with the explicite notation of the other space variants, like \,
tflo
commented
6 years ago Well, to sum it up, what I think is this:
– Tom
l3u
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago Here's the clear text of the (KWrite) screenshot I posted above:
U+002D - Hyphen-Minus
U+2013 – En DashSurely, 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
commented
5 years ago 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.
l3u
commented
5 years ago This looks way better :-) I would still swap the vertical orientation (as LaTeX does) though.
chrissimpkins
commented
5 years ago 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
commented
5 years ago Nice :-) Thanks a lot for fixing this!
tflo
commented
5 years ago 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:
I think, it’s even better than IBM Plex now!
Many thanks for the update!
– Tom
fkranhold
commented
1 month ago If I see it correctly, then this is still an issue with bold and italic:
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