Case-sensitive forms of mathematical operators

agisaak's picture

Hi,

I have a font which has 'uppercase' and 'lowercase' versions of mathematical operators (differentiated by height -- similar to the treatment of hyphens, dashes, etc.). I'm trying to figure out how to best handle this in terms of OT features, and am debating between two approaches.

(A) I can treat the uppercase variants as basic and access the lowercase ones through some features (probably 'onum' and 'smcp').

(B) I can treat the lowercase variants as basic and access the uppercase ones through some features (probably 'case' and 'lnum').

Either way, either '2 + 2 = 4' or 'a + b = c' is going to look weird without some feature being applied. I'm wondering which approach is the better option. I'm leaning towards (B) simply because many people use the hyphen in lieu of a proper minus symbol and (B) would treat the two in a parallel fashion but am still going back and forth on the issue.

Note that this face isn't intended for mathematical use, and it contains a set of small figures but no true oldstyle figures. I'd rather leave the full-height figures as basic.

Thoughts?

oldnick's picture

Georgia is my default font for this forum and, for both your examples, its math operators look just fine with Georgia’s oldstyle figures. Perhaps you might learn from the Master…

HVB's picture

I've never seen a math text that changes operators depending on what kind of symbols are on either side of them. Which operator variant would you use in x + 8?

agisaak's picture

I think everyone here is correct that this was probably a bad idea. I'd originally thought that I should have these simply to parallel the fact that I have raised variants of dashes, middots, etc. for all caps settings, but of course equations aren't the sort of thing one normally applies all caps formatting to.

André

JamesT's picture

For my typeface, I have variants of the math symbols that are turned on when the full-height numerals are turned on. The old style numerals are the height of the small caps so, in situations such as x + 8 the difference doesn't seem like a problematic issue.

hrant's picture

I'm not sure it's a bad idea.

hhp

agisaak's picture

Actually, the lowercase variants work fine in mixed case situations (using case to refer also to full height vs. small figures as well as the more orthodox use) such as 3x + 8 = 14. If I went ahead with this using my option B then the 'uppercase' operators would be used only in situations where all caps formatting had been applied such as 'COBRAS+MONGEESE=TROUBLE!' giving the operators a more centered appearance, but the lc variants are still perfectly serviceable in situations like 2+2=4 (my earlier claim that they looked weird was overstated -- they simply aren't visually centered).

On the one hand, the use for such variants would likely arise rather seldomly. On the other hand, the effort involved in implementing them is rather minimal (a small handful of slightly raised glyph copies plus one line of code).

So now I find myself leaning back to including them, though I'm still not fully off the fence. All feedback has been appreciated.

André

quadibloc's picture

Given that hyphens are treated this way, I can't dismiss out of hand the idea of doing this with at least the most common mathematical operators in a typeface not intended for the setting of mathematics.

Given that in mathematical typesetting, variables are almost always lowercase (and italic) and numerals are almost always ranging (as opposed to oldstyle), it is true, as has already been noted here, that mathematical operators almost always have to be designed to a compromise position that looks good with any mixture of upper-case and lower-case.

Obviously, it would not be a good idea to have a font switch between oldstyle and ranging numerals depending on whether the letters of variables adjacent to them in an equation are uppercase or lowercase. Given that, one would almost be constrained to have to have three forms of mathematical operators, the compromise kind as well as the uppercase form and the lowercase form.

And then you have the problem that if not all the operators in a formula are of the same kind, one has their median line jumping up and down.

Even with all these dangers, the alternate forms of the operators might be useful where one has only very simple expressions, so the rule to encode in the font is perhaps to only use the uppercase form or the lowercase form if it is the only form called for in a single expression or even in a whole line of text - and otherwise use the compromise form.

With such a restriction on the use of the alternate forms, while it might be questioned if they're worth the bother, if one isn't typesetting mathematics, the majority of the time there will usually only be one operator or two used at a time. (And encoding such a rule has the bonus that the typeface won't break down if someone does use it to typeset mathematics - the dangerous feature just turns off gracefully.)

dezcom's picture

I use c2sc for this operation. I have a normal set that works with mixed case and caps and an smcp set that works with smallcaps. I also have a stylistic set which allows the user the choice to use the smallcaps operators with onum if they choose. With this setup, I also add smcp figures which are lining but at the smallcap height.

Syndicate content Syndicate content