Hyphen-minus and mathematical operators

Robin Mientjes

Hey y’all,

I’ve been helping somebody master a few fonts and I’ve run into a problem.
Normally I’ll design hyphen-minus (-, U+002D) to be a hyphen, and add a proper mathematical minus (−, U+2212) to align with the default numbers and mathematical operators. That works fine when I assume a capable typographer.
However, I can’t assume this for this particular client. Mainly, most people don’t have the minus on their keyboard (I do; I use Ukelele for custom keyboard layouts). Also, as long as hyphen-minus is doing both duties, most people will not think about it.

Considering that the hyphen-minus is a lot lower, slightly heavier, and shorter than the mathematical operators, how do I most elegantly handle this? I don’t know if I can even rely on calt. So: do I accept the difference, or is there a way to make this a bit more intelligent?

Kent Lew

I think generally you have to accept the difference. Trying to anticipate uses like this via {calt} is only likely to get you into trouble.

You might try to convince your client to use an endash instead of a hyphen for minus. It is accessible from most keyboard layouts, and it is also easier to design an endash that can do double duty as a minus since they both generally occur mostly in the context of numbers.

attar

I don’t know if I can even rely on calt.

Codepoints are codepoints. You shouldn't "fix" things that are on the keyboard layout. Many kbd layout don't have minus out there, nor smart quotes and so on. Office suites often have a replacement facility or otherwise they're looking at making a custom keyboard layout (which isn't hard to do in the first place, it's just that not many people do it).

Swapping between codepoints is often not a good idea because it's not going to be portable across the fonts – and that is precisely the reason why we use Unicode.

You might try to convince your client to use an endash instead of a hyphen for minus.

IMO we need to switch to keyboard layouts that are not direct mapping from typewriters. There is no reason why a minus sign should be a big deal in 2015. There is also no reason why this question should emerge at the type designer's level (it's about how you set up your computer, it's unrelated to a specific font).

Robin Mientjes

@Frode Bo Helland pointed me to Fresco, which uses a relatively high hyphen-minus, for this exact case. It’s interesting, and I think I’ll go for that solution.

As for why the type designer has to answer this, obviously it’s because computer setup is beyond most people, and fairly so. I have my own keyboard layout because I’m also a typographer. Most people are amazed to find the pilcrow on theirs.

attar

For these people I would just propose ready-to-install keyboard layout packages, personally.

Adam Twardoch

Team up with a company such as TouchType (who make SwiftKey) or one of the minor iOS/Android keyboard developers, design some novel keyboard layouts for OS X, Windows, iOS and Android for grown-ups (who are not yet infected by the emoji craze).

Have the software makers develop these and sell them. There’s some money to be made.

Nick Shinn

I manage to make identical glyphs for Minus and Endash in most weights of most of my typefaces.

And if they don’t want to be the same glyph or character width, at least they can be the same height and thickness, to align with + and =.

Andreas Stötzner

I’m not aware of the historical details of the introduction of “hyphen-minus”. However, the very term is rather idiotic. A hyphenis a hyphen and a minus is a minus. The hyphen tends to be short and ticker (sometimes even slightly oblique), the Minus is slim and longer. I’m with Mr. Shinn, pragmatically: give the minus and the endash the same glyph and width – and you’re (in most cases) out of the conundrum.

Chris Lozos

the trouble is vertical.  The hyphen needs to look good with lower case and the minus needs to be higher to work with figures.

attar

However, the very term is rather idiotic. A hyphenis a hyphen and a minus is a minus.

You’re missing the point: this character was added in Unicode for backwards-compatibility with ASCII which itself inherits from typewriters.

Unicode defines semantics. The hyphen-minus is “either an hyphen or a minus” per spec – there is a distinct codepoint, U+2010, for hyphen alone (+ another one for minus alone ofc) but it’s little-used in practise since people who differenciate just use hyphen-minus to only represent the hyphen given that it’s what’s on keyboards anyway.

Also not many fonts provide U+2010 (it just needs to be a duplicate of the hyphen-minus). I saw it in FF More and add it to my work since then.

Robin Mientjes

Sorry, @Andreas Stötzner. I wasn’t attempting to be an idiot. This is simply what the glyph is called and, as Chris and Adrien have already noted, there are plenty of problems with it. I’ve ended up with a solution, but it is a compromise.

Claudio Piccinini

Robin Mientjes said:

Sorry, @Andreas Stötzner. I wasn’t attempting to be an idiot. This is simply what the glyph is called and, as Chris and Adrien have already noted, there are plenty of problems with it. I’ve ended up with a solution, but it is a compromise.

I see this is an old discussion. However, how U+002D – if used as a minus – vertically aligns with the figures also depends on how intend it to do so, and on your default figures. Since I favor oldstyle figures, having the "hyphenminus" aligned with old style figures works for both letters and numbers.
The general solution I decided to adopt is to have a proper minus glyph (U+2212) — also considered I decided to make my Math symbols "universal" in fonts that are not specifically intended for Math — and to assign a double code point to the hyphenminus and hyphen glyphs (U+002D and U+2010) intended to be used mainly (but not necessarily only) as a hyphen.

John Savard

Kent Lew said:

You might try to convince your client to use an endash instead of a hyphen for minus. It is accessible from most keyboard layouts,

Accessible from most keyboard layouts?

Perhaps it's accessible from some international layouts. However, I doubt that it is most of them. Of course, since the Macintosh offers a full set of Alt glyphs in its U.S. keyboard, perhaps it might actually be accessible from most Macintosh keyboard layouts.

Robin Mientjes said:

Sorry, @Andreas Stötzner. I wasn’t attempting to be an idiot. This is simply what the glyph is called

I don't think that Andreas Stotzner was calling you an idiot. Instead, I think his opprobrium was aimed at the people at the Unicode Consortium that chose that name.

While I don't think we can modify our C compilers to use U+2212 for minus, or even × U+00D7 for addition and ÷ U+00F7 for division, I can appreciate his concern; after all, I hope they haven't called * "asterisk - multiplication sign". The fact that compiler writers had to make do with a character set largely based on the office typewriter... while it has set a precedent that compiler writers need to follow for compatibility, there's no need for typographers to redefine the contents of their typecase around it.

Robin Mientjes said:

I’ve been helping somebody master a few fonts and I’ve run into a problem.
Normally I’ll design hyphen-minus (-, U+002D) to be a hyphen, and add a proper mathematical minus (−, U+2212) to align with the default numbers and mathematical operators. That works fine when I assume a capable typographer.
However, I can’t assume this for this particular client. Mainly, most people don’t have the minus on their keyboard (I do; I use Ukelele for custom keyboard layouts). Also, as long as hyphen-minus is doing both duties, most people will not think about it.

Since it has been revealed in this thread that U+2010 exists also in Unicode, for a true hyphen which is only used as a hyphen, I think it's obvious how to deal with this situation. That is, if the situation is what I think I understand it to be: a typographically unsophisticated client has a need for a proper mathematical minus from a given font.

Draw a proper mathematical minus, and assign the shape to both U+2212 and the "hyphen-minus" at U+002D. Also draw the proper hyphen, but assign that shape to U+2010 only.

That way, a typographically unsophisticated client can use the - key to get a proper mathematical minus... and people who are typgraphically sophisticated, or who are using word processors (hey, if they can do "smart quotes", they ought to be able to turn - into U+2010) will get the hyphen when they need it.

John Hudson

Andreas:

I’m not aware of the historical details of the introduction of “hyphen-minus”.

I believe it originated in typewriters, where a single key was used for hyphen and for minus—which didn’t really matter, since most typewriter text was monospaced—, and whence to computer keyboards, to ASCII—where unifying hyphen and minus also saved space—, and from there into the first block of Unicode.

John Savard:

Draw a proper mathematical minus, and assign the shape to both U+2212 and the "hyphen-minus" at U+002D. Also draw the proper hyphen, but assign that shape to U+2010 only.

No. Don’t do that. In most text, hyphen is far more common than minus, and hyphen is input from keyboards as U+002D, which is also the character inserted at linebreaks in automated hyphenation. The /hyphen/ glyph, which maps to U+002D, should be a hyphen, and the /minus/ glyph, which maps to U+2212, should be the minus. Adobe’s AGFLN gets it right:

002D;hyphen;HYPHEN-MINUS
2212;minus;MINUS SIGN

Claudio Piccinini

John Hudson said:

No. Don’t do that. In most text, hyphen is far more common than minus, and hyphen is input from keyboards as U+002D, which is also the character inserted at linebreaks in automated hyphenation. The /hyphen/ glyph, which maps to U+002D, should be a hyphen, and the /minus/ glyph, which maps to U+2212, should be the minus. Adobe’s AGFLN gets it right:

002D;hyphen;HYPHEN-MINUS
2212;minus;MINUS SIGN

That’s precisely why I adopted the solution I mentioned in my previous comment: most general users might not realize there is a specific minus glyph (with codepoint) and thus will use the hyphenminus. So, while I add the minus U+2212 in the same fashion of other math operators, considered most people will use the hyphen for both, I try to make the hyphenminus U+002D flexible enough.
One could always make a contextual substitution with U+2010 and design a specific or alternate hyphen for this.
For example, since De Vinne has a unusual hyphen, I designed U+2010 as a proper "hyphenminus" in case someone looks for a conventional hyphen. U+2212 is balanced in design with other math operators.

Claudio Piccinini

I also have an alternate form for the De Vinne hyphen, but that is in a stylistic set.
There is a codepoint for the double hypen in historical fashion, so I think in the case of De Vinne I will assign three codepoints to the same glyph.
https://codepoints.net/U+2E40

Florian Pircher

There is also U+2011 NON-BREAKING HYPHEN, a hyphen that should not be broken at the end of a line. I encode the /hyphen glyph with U+002D, U+2010, and U+2011.

Claudio Piccinini said:

There is a codepoint for the double hypen in historical fashion, so I think in the case of De Vinne I will assign three codepoints to the same glyph.

I would recommend against encoding the double‑hyphen with the same codepoint as the single hyphen. When a text explicitly requests a double‑hyphen, then showing a normal hyphen is the wrong thing to do (even if it is available as an alternative via some feature). If you want to triple encode the hyphen glyph, use my approach.

Claudio Piccinini

Florian Pircher said:

I would recommend against encoding the double‑hyphen with the same codepoint as the single hyphen. When a text explicitly requests a double‑hyphen, then showing a normal hyphen is the wrong thing to do (even if it is available as an alternative via some feature). If you want to triple encode the hyphen glyph, use my approach.

Hi Florian. Thanks, but I will do so just because De Vinne standard's hyphen is indeed a double hyphen. That’s why I provide the U+2010 as an alternative. See below.
The third is a period stylistic variant that I have found and might not have been part of the actual lead De Vinne, maybe from another period face. But I like it so I am including it as an even more decorative version. The last line shows my monoline Math operators, including minus.

John Hudson

Claudio:

That’s precisely why I adopted the solution I mentioned in my previous comment: most general users might not realize there is a specific minus glyph (with codepoint) and thus will use the hyphenminus. So, while I add the minus U+2212 in the same fashion of other math operators, considered most people will use the hyphen for both, I try to make the hyphenminus U+002D flexible enough.

I understand the thinking, but because of the rôle of U+002D in automated hyphenation, I think it is best to think of that character as hyphen in terms of design: it should be identical to U+2010 and U+2011, and the dual identity with minus treated as a legacy consideration only. Yes, this means that users need to be aware of U+2212 and options for inputting it in text. That isn’t something that can be solved at the font level.

Claudio Piccinini

John Hudson said:

Claudio:

That’s precisely why I adopted the solution I mentioned in my previous comment: most general users might not realize there is a specific minus glyph (with codepoint) and thus will use the hyphenminus. So, while I add the minus U+2212 in the same fashion of other math operators, considered most people will use the hyphen for both, I try to make the hyphenminus U+002D flexible enough.

I understand the thinking, but because of the rôle of U+002D in automated hyphenation, I think it is best to think of that character as hyphen in terms of design: it should be identical to U+2010 and U+2011, and the dual identity with minus treated as a legacy consideration only. Yes, this means that users need to be aware of U+2212 and options for inputting it in text. That isn’t something that can be solved at the font level.

I agree, of course. I just implied that where it’s not something capable to substantially alter the design, to keep in mind the user more surface usage and fashioning it as a "possible minus" can do no wrong. Of course it does not work with a specific case like De Vinne, and that’s why I designed the U+2010 and the minus of course goes with the Math operators design.

John Savard

John Hudson said:

No. Don’t do that. In most text, hyphen is far more common than minus, and hyphen is input from keyboards as U+002D, which is also the character inserted at linebreaks in automated hyphenation.

I certainly wasn't advocating it as a general practice.

It seemed like the solution to what appeared to be the original poster's specific issue:

a font was being designed for one particular client, and that client was unsophisticated, and needed access to a usable mathematical minus sign.

An alternative way of addressing that issue would be to let - be a hyphen, and put the mathematical minus sign at the code point of, say, ~, a little-used character: by "unsophisticated", I am assuming absolutely no access to any code points for printable characters other than the basic ASCII 94.

Of course that kind of thing is bad practice, but situations exist where there is no alternative; designing the font according to good general practice would mean the end user simply could not use it. That's a failure: the first thing a tool must do is the job it's intended for.

Of course, educating the user, preparing a custom keyboard layout, or having applicable software upgraded, if those alternatives exist, would be preferable.

For general practice, I would tend to suggest this:

Design a character that is usable as both a hyphen and a minus sign for U+002D.

If, ideally, the hyphen character should differ from that, and not be usable as a minus sign, for the particular typeface, then put the proper hyphen as U+2010, and put an ideal minus sign at U+2212.

Aaron Muir Hamilton

Personally, after a lifetime of reading mathematical expressions in ASCII, the "proper" minus looks wrong.

Michael Rafailyk

I'm wondering why the calt for math is a bad idea?
@John Hudson It could be solved without replacing codepoints.

  @num = [zero one two three four five six seven eight nine];

  sub @num hyphen' @num by hyphen.minus;
  sub @num x' @num by x.multiply;
  sub @num space hyphen' space @num by hyphen.minus;
  sub @num space x' space @num by x.multiply;

This way the hyphen codepoint remains hyphen but looks like a minus (between a numbers), and the letter x remains x but looks like a multiply. I would like to hear the pros and cons of this approach.

John Savard

Michael Rafailyk said:

This way the hyphen codepoint remains hyphen but looks like a minus (between a numbers), and the letter x remains x but looks like a multiply. I would like to hear the pros and cons of this approach.

I can think of one huge con immediately. What happens when you want to multiply x by something?

In FORTRAN and BASIC, not only is the hyphen used for minus, but the asterisk is used for multiplication and the slash for divide. Because APL used the slash and backslash for other things, a DEC preprocessor for letting people use APL from ASCII terminals without the APL character set used % for divide; this was later used for the J language as well.

However, I don't recommend that anyone try to use a language alternate to turn ordinary characters into APL with a font.

John Hudson

It could be solved without replacing codepoints.

Should that be a goal? As a general practice, one doesn’t want to represent one character with the glyph of another character. In the case of U+002D, there is built-in ambiguity, but there is also a clear way to avoid that ambiguity, which is to use U+2212 MINUS for the minus sign. I can just about see the case for calt for display of U+002D as a minus sign, given the built-in ambiguity, with the caveat that it probably isn’t very reliable in getting the minus sign appearance everywhere one might want it, considering things like variables and delimiters in equations. But using glyph processing to display an unambiguous character like x as a multiplication sign is a really bad idea, especially since x is a common variable in equations.

Michael Rafailyk

@John Savard and @John Hudson thank you for the explanations, now I see a bunch of problems that are trailing behind these manipulations. Certainly, it is not possible to cover all the situations that may be encountered.

Should that be a goal?

Of course not, I just mean this way the original codepoint is preserved, which is preferable when changing the font.