en-dash shorter than minus sign

[mvsfrasson]

Hi.
In LaTeX I use a lot of minus signs (-), en-dash (–) and em-dash (—). In length, minus < en-dash < em-dash.
In Hack font, awkwardly, en-dash < minus < em-dash. Please fix en-dash (enlarge it and make it easier to read) so that it has proper length order (minus < en-dash < em-dash).

Screenshot below.

Note: DejaVu Sans Mono also got it wrong (en-dash too long)

[mvsfrasson]

P.S.:
minus - is U+002D
en-dash – is U+2013
em-dash — is U+2014

More information:

• download lastest hack font 2 days ago directly from GitHub, zip file.
• all font variants are affected (see picture below)
• use it in Xubuntu (26.04), mainly in Emacs (30.2)

This screenshot was taken in libreoffice.

[mvsfrasson]

I took the initiative to see the files endash.glif in the glyph folders for the 4 variants.
They are xml with an easy-to-understand syntax as the chars are formed by just 4 points, so I did it. If someone wants to use them, feel free, I will be happy if they are used.

The summit of changes:

glyph width: 1233 (all variants)

BORDER SIZES	R	I	B	BI
hyphen	206	193..226	221	204..259
em-dash	0	-13..15	0	-23..26
en-dash actual	309	292..320	291	292..341
en-dash PROPOSED	103	86..114	111	86..135
difference	±206	±206	±180	±206

I edited the timestamps to the time I edited the files (2026-09-07 23:00:00 +0000). Someone can use proper timestamps.

Patch files attached.

endash-regular.patch
endash-italic.patch
endash-bold.patch
endash-bold-italic.patch

[radelqui]

This is actually by design in most monospaced fonts, and it's a tricky issue. In a monospace font every glyph occupies the same cell width, so the minus sign (U+002D) fills that cell in a way that can look wider than the en-dash (U+2013), which is traditionally designed narrower and then centered in the same cell. The result is that visual ordering gets flipped compared to proportional fonts.

If you want to fix this yourself in Hack, here's how. 1. Install FontForge (fontforge.org). 2. Open the Hack .ttf file. 3. Navigate to U+2013 (en-dash). 4. Select the glyph and scale it horizontally so it's noticeably wider than the hyphen-minus but still fits the mono cell. Something like 80-85% of the cell width usually looks right. 5. Optionally adjust U+2014 (em-dash) if needed. 6. Generate the modified font and install it.

Alternatively, you can switch to a monospaced font that already handles this better. JetBrains Mono and Iosevka both have en-dashes visually longer than the minus. You could also try Source Code Pro.

If you're working in LaTeX specifically, another workaround is defining a custom command like \newcommand{\ndash}{\rule[0.5ex]{0.7em}{0.5pt}} to get exactly the dash length you want regardless of the font.

What if every question like this got answered on the spot, and someone just handled the fix for you right there in your document? That's what ME Office AI does. Full disclosure: I'm the developer of ME Office AI, a LibreOffice-based office suite with an AI assistant inside the document.
https://apps.microsoft.com/detail/9PCV4RCJCFXV?cid=gh-meoffice

[mvsfrasson]

@radelqui, thanks for the reply.
The problem was LaTeX source code (in Emacs) looking awkward with source code chars with flipped length order.
If that flip has an explanation, ok.
But I need a proper length for minus, endash and emdash as I use them a lot in source code, and it annoys me get confused by mixing - with – as they look different in LaTeX source and in generated pdf by LaTeX. They should look similar both in source and pdf.

I just build locally the Hack font from source I modified. I had to edit some autohint files in postbuild_processing/tt-hinting/ giving errors (replacing uni00?? names with char names, like uni0025 -> percent). Now I have what I want locally.

If this issue is resolved by @radelqui explanation, it can be closed.

(@radelqui, congratulations for the ME Office AI 👍)