Hack: Dash of different sizes render badly

[jpotier]

I often have trouble properly visualizing the different types of dash (En dash, Em dash, Figure dash ; also known as short, half and long dash) in my terminal when editing Tex source in UTF8 or in a IRC conversation. In my mothertongue, these are used commonly, but are often overlooked since it is hard to type them using a conventional keyboard layout (qwerty, azerty, …) In bépo however (a french equivalent of dvorak), they are easily accessible and I use them often.

I realize that in a mono font, it is _hard_ to make them of different size. Would it be possible however to mark them so that:

1. they don't break the rendering (overstep on the neighboring character)
2. they would still be distinguishable from one another

I would propose that they should be crossed one or several times depending on their length:

1. - figure dash would be left as is (since it is very often used)
2. – en dash would be marked once
3. — em dash would be marked twice

Is this feasible?

This really is the very little bit of detail that is still cause for concern with this font ; I _love it_ and use it everyday and not only in my terminal. Enhancing dash representation would actually make this font the most accomplished of mono fonts :)

[chrissimpkins]

Thank you very much for the suggestion. I really appreciate your feedback. So that I understand your problem, would it be possible to push images of the dashes in TeX along with information on the font size that you are using and whether the size of the font appears to make a difference in the appearance of these glyphs? I will also need information on your platform if you don't mind. This will help me to understand the influence of hinting on the problem that you reported.

Let's see if we can find a good solution that addresses your issue.

[jpotier]

Here are two previews, one small, one big:

Both are rendered on Archlinux, font is 12pt in the first, obviously a lot bigger in the second, rendered by:

• freetype2-infinality 2.6-2, based on the configuration given by
• fontconfig-infinality 2.11.94-2

Actually… It looks pretty much OK ^^' I fear I may have been hasty in my first complaint. Sorry.

As to concern 2, there's still a possible confusion between en dash and em dash. The later is somewhat thinner than the former, but it varies with the rendering size.

An example using 8pt:

[chrissimpkins]

Thanks Jean. We can look at the width and height of the strokes. They should render with the same stroke height.

Can you clarify what you mean by "marked"?

[jpotier]

As the difference between en dash and em dash is not clear, I would propose to draw en dash differently, maybe giving it a serif aspect so that it refers to a segment instead of a straight line, thus implicitly showing that it is shorter than em dash.

With an image, en dash would be in the spirit of:

[chrissimpkins]

Can you provide a bit more detail on the use of these dashes in your TeX files? Are you using these in the body of the text or are they TeX specific tokens?

[jpotier]

They are used in the body of the text, since my tex files are utf-8 encoded and luatex is able to take them directly as input.

[chrissimpkins]

I see, so this is part of the document text that you are generating. I'm hesitant to use serifs on the dashes in a (largely) sans serif typeface; however, I think that we can work to make these fit the proper definitions of the respective glyphs. For these issues, I generally refer to the Bringhurst text and here is what he has to say:

• en dash - one half of an em in width
• em dash - one em in width

I will need to look at where we are with these measurements in the current design and we can make sure that we comply with the above guidelines. Based upon the screenshot above, it looks like we may have some work to do. I will add this to the work for an upcoming release. Will let you know here when there is something available for you to try.

[jpotier]

I'm at your disposal whenever you need testing then. Thanks!

[chrissimpkins]

Thank you!

[chrissimpkins]

We are adding a thorough hint evaluation to the v2.021 release and will look into this as part of the changes that we make then. Will post more info here when we have something available for testing.

[jwheare]

Just a note to confirm that en and em dashes appear identical to me at all sizes, regular/italic, 400/700 weight, using the extended web font hosted on jsdelivr.

Chrome 53.0.2785.113 (64-bit)
macOS 10.11.6 (15G1004) El Capitan
MacBook Pro (Retina, 13-inch, Early 2015) (built in monitor, at default and all resolution scales)
https://cdn.jsdelivr.net/font-hack/2.020/css/hack-extended.min.css

Screenshot taken with middle resolution scaling option, 14px, weight: normal, style: normal

Screenshot of xScope loupe at 800% zoom:

[chrissimpkins]

Adding this on to work for v3.001 release

[chrissimpkins]

I modified the em dash, en dash, and figure dash in all four variant sets as of https://github.com/source-foundry/Hack/commit/b092654b061c8296dd039fa52ba30368491249a1

I used Robert Bringhurst's typographic definition for each of these glyphs as follows:

• em dash - em width (i.e. full box)
• en dash - 0.5 * em width
• figure dash - average width of a numeral

You should be able to distinguish these in your text now. Builds that include these changes are available in the dev branch if you'd like to give them a try. They are versioned as Version 3.001; ff1219e-dev. These changes will be part of the upcoming v3.001 release.

https://github.com/source-foundry/Hack/tree/dev/build

Here are images that demonstrate the change in design for these glyphs:

em dash

en dash

figure dash

Let us know if this addresses the issue in your original issue report and thanks for taking the time to weigh in on this!