# Re: More questions on low slots

• To: math-font-discuss@cogs.susx.ac.uk
• Subject: Re: More questions on low slots
• From: Michael John Downes <mjd@MATH.AMS.ORG>
• Date: Tue, 21 Oct 1997 11:07:30 -0400
• Sender: mjd@epsilon.ams.org

Frank Mittelbach wrote:

> >truetype comes to my mind when we speak about restrictions below 32
> ..
> >now you might think this is of no interest since we are doing TeX, but
> >this is not true as the commercial vendors are more likely to go with
> >such a setup of they can offer those fonts also for other software.

To which Hans Aberg replied:
>   If such restrictions apply, could one not have that in mind, making one
> set of dumb fonts which no char's below 32 for dumb software, and having a
> set of smart virtual fonts derived from these for the a little smarter TeX?

This proposal sounds right to me. For simple math symbols the natural
interface, if we ignore the limitations of existing software, is to have
a single font including *all* the "commonly used" symbols (including
Greek, Latin, slanted, upright, calligraphic, Fraktur, Hebrew,
blackboard bold letters; but not other weights like bold and ultra-bold)
and call them with something like

\mathchar CXXXX

where C is the math atom type and XXXX is a four-hex-digit position
within the One True Math Font Encoding. (Theoretically speaking more
than four hex digits could be advocated, but I think we could limp along
with a set of 65536 math symbols for a while.)

(This is not Unicode! This is a glyph encoding, not a character
encoding.)

Delimiters could be done more simply if the base size and the larger
sizes were always in the same font: there would be no need then to
specify two different character positions in the delimiter code, TeX

The current math font proposal, of course, is intended to work with TeX
3.x which means that it cannot ignore the TeX restrictions of 16 math
\fam's and 256 characters per font (total 4096 symbols). As I see it,
the current proposal is essentially an interface

\mathchar CXXX

with some care needed for kerning and next-larger constraints because
TeX partitions the 4096 symbols into 16 parts and doesn't do kerning
between symbols from different parts.

It would seem rather a mistake, however, to reduce further from 256 to
223 per math fam *at the TeX end* of the interface, when TeX only needs
to deal with a .tfm file and virtual font mechanisms are readily
available. I don't know if this is really what Matthias and Ulrik were
speaking of, probably I didn't completely understand.

Pragmatically speaking it may be necessary for the moment to have .pfb
files that leave slots 0-31 open, and put a hard space in slot 32, but
in the discussion of \skewchar etc this issue seems in danger of being
being mixed up with the TeX interface issue: I think it would be silly
for TeX to see in the .tfm file for a math symbol font that there is a
space in slot 32 when it is never going to be used as a math symbol; and
in the absence of other criteria the natural place for a skewchar would
seem to be position 0 or 255 (which is why I suggested 0 in the first
place).

Also I think Knuth's use of math mode for the letters of \sin and other
operator names is unfortunate. If the letters are to be combined into
word-like fragments they should be set in word mode', i.e., text mode.
This becomes more apparent when you try to write a hyphenated operator
name such as ess-sup and you find the hyphen turning into a minus sign.
Practically speaking the main reason that forced Knuth to set operator
names in math mode was no doubt to have them change size automatically
in subscripts. But it would not be such a hard task for TeX to do them
in text mode as well, if only TeX had a current math style' variable
that could be used to determine the necessary font size at a given point
(... that it does not have such a variable is due to the choice of
syntax for the generalized fraction commands {...\over...}, as may be