Re: Too narrowly defined: DIVISION SIGN & COLON

From: Hans Aberg <haberg-1_at_telia.com>
Date: Wed, 11 Jul 2012 20:32:53 +0200

On 11 Jul 2012, at 19:30, Jukka K. Korpela wrote:

> 2012-07-11 19:33, Hans Aberg wrote:
>
>>> There is a “literal” mode in unicode-math package just for that, check
>>> its manual for more details.
>>
>> As for the ISO standards mentioned in section 5.2 "Bold style",
>
> I’m sorry, I’ve lost the context: section 5.2 of what?

Yes, you snipped it; I have put it back.

>> I think they call for the use of sans-serif fonts.
>
> The ISO standard on mathematical notations, ISO 80000-2, is very vague about fonts: “It is customary to use different sorts of letters for different sorts of entities. This makes formulas more readable and helps
> in setting up an appropriate context. There are no strict rules for the use of letter fonts which should, however, be explained if necessary.” (clause 3)

There was mentioned a standard for tensors for technical use specifically, but I do not recall which it was.

> The standard itself uses a sans-serif font throughout, as ISO standards in general. This is unfortunate for many reason. Sans-serif fonts are generally unsuitable for mathematical texts. Moreover, if your overall font is sans-serif, some essential distinctions are lost, since tensors and symbols for dimensions are conventionally rendered in sans-serif font as opposite to the tradition of using serif fonts for mathematics. This is one of the reasons for “mathematical sans-serif” characters in Unicode.

Originally, it was probably just different styles I think, as opposed to different (mathematical) styles, but somehow sans-serif for tensors became popular, and that was part of the motivation for adding mathematical sans-serif styles to Unicode.

A similar thing happened with the mono-space characters: in computing, style does not change semantics, in fact, some older books I have do not use monospace for computer code. But now that they added to Unicode, they could be used to leave the ASCII subset for serif letters.

> > In pure math, one uses serif fonts, also for tensors, which do not have any fixed notation.
>
> Pure math, applied math, and physics partly use conflicting conventions for some notations.

Right. And inconsistencies perhaps have increased, since professional typesetters do not do that job anymore.

> Standards are supposed to remove unnecessary and disturbing differences, at least in the long run. And ISO 80000-2 says: “Two arrows above the letter symbol can be used instead of bold face sans serif type to indicate a tensor of the second order.” (2-17.19) This implies that the normal, basic notation uses bold sans-serif for tensors.

Those are originally styles used in the absence of fonts, including handwriting.

> > Also, it is traditional to typeset variables in italics and constants in upright,
>
> There is considerable variation here. By ISO 80000-2, *mathematical* constants such as i, e, π, and γ are denoted by upright symbols, whereas *physical* constants such as c (speed of light in vacuum) are treated as denoting *quantities* and therefore italicized. It is however very common in mathematics (but not that much in physics) to italicize mathematical constants

In the past, it was uncommon to have different styles for Greek, so you would have to take whatever available. Constants like i, e, whatever would probably end up in italic, with upright reserved for names like "sin".

But it is now possible to distinguish between constants and variables systematically, now that the Unicode mathematical styles are available.

>> but this has not been strictly adhered to, perhaps due to the lack of fonts.
>
> I think the diversity is mostly due to traditions. Mathematicians tend to be very conservative in notational issues.

In the days before electronic typesetting, lack of suitable fonts is said to have been a problem due to the cost of having those fonts available. One might use a typewriter, with even a higher limited number of symbols, and do mark up by hand. Here is one example:
  http://books.google.se/books?id=KCOuGztKVgcC&printsec=frontcover&dq=alonzo+church&hl=en&sa=X&ei=Xcb9T-34MrL54QSZqJD5Bg&redir_esc=y#v=onepage&q=alonzo%20church&f=false

>> Unicode adds all variations: serif/sans serif, upright/italics.
>> In principle, one could use all styles side-by-side indicating semantically different objects.
>
> Yes, you could, but I think it’s not *normal* to make the distinctions at the character level. Rather, higher-level protocols are used to indicate italics, bolding, and font family. One obvious reason is that it is rather clumsy to *type* the mathematical italic, mathematical sans-serif, etc., characters and usually very easy to use font or style settings, markup, or style sheets for italics etc.

Yes, that is another problem: the lack of efficient input methods. But Unicode now supports those styles and variations at the character level, so they could be used.

> I was surprised at realizing that MS Word 2007 and newer, when processing formulas, internally converts normal characters to mathematical italic and relative. For example, in formula mode, when you type “x”, Word by default changes it to mathematical italic x. It does *not* used a normal “x” of the font it uses in formulas (Cambria Math)—that font lacks italic, and if you “italicize” it, you get fake italic, algorithmically slanted normal letter, which is very different from mathematical italic letters of the font.
>
> It’s interesting to see such usage—it’s probably the most common use of non-BMP characters that people encounter, even thought we are usually ignorant of what’s really happening here, and it *looks* like play with fonts only.

That is one possible input method, as an alternative to key maps: certain character sequences are converted to say Unicode characters while typing. It is possible to customize that in Mac OS X, but the problem is that it is very time consuming, and non-standard, just as developing your own key maps, which is also possible.

Hans
Received on Wed Jul 11 2012 - 13:34:54 CDT

This archive was generated by hypermail 2.2.0 : Wed Jul 11 2012 - 13:34:54 CDT