(even more!) BUGS: 1.9.15's omx.etx and mathex.mtx

Lars Hellström Lars.Hellstrom@math.umu.se
Thu, 23 Nov 2000 12:07:28 -0500

At 17.45 +0100 2000-11-21, schlegel@vossnet.de wrote:
>The original mathex was made to substitute characters from Symbol (in a
>setup for Times with "free" fonts). Therefore one finds some strangers

At least the first set of strangers Alejandro reported do not occur in
Symbol, so these were internal inventions in the fontinst project.

>I don't think there is a "correct" name: there are different schemes
>- MathTime/BSR cm fonts
>- Bakoma
>- original CM has no naming defined
>- Adobe Lucida fonts
>- Symbol font names

Since the metrics for CM fonts (Type 1 or not) should be taken from the
TFMs we probably will not have a problem with these no matter which glyph
names we use. The problem is with fonts whose metrics are given by AFMs.

>The question is if fontinst should at all follow a specific scheme
>implemented in one font set. This could have the advantage to avoid
>faked characters. On the other side it could lead to confusion about the
>difference of the names which a vendor specific encoding supplies and
>the identifier Fontinst uses for its character remapping.
>I suggest either to choose a strict definition or follow a strategy of
>minimal modification of a working scheme...

>BTW, the inconsistency in the braces seems to be important to be

It turns out there is an explanation for the braceleftmid and bracerightmid
oddities: as large delimiters they aren't midparts of braces, but single
and double vertical arrows without arrowheads. fontmath.ltx says:
\DeclareMathDelimiter{\arrowvert}    % arrow without arrowheads
\DeclareMathDelimiter{\Arrowvert}    % double arrow without arrowheads

"3C and "3D are the slots for braceleftmid and bracerightmid respectively.

There are two types of problems that are caused by having different names
for the same glyph. The obvious is that fontinst may fail to find (and
therefore not use) glyphs that present in the fonts, but a less obvious
problem (which can occur if the map file writer is used) is that a driver
might be asked to print a glyph that is not present in the font (because
its name is wrong).

In the ETXs I uploaded to CTAN I had assigned the encoding names
TeXMathItalicEncoding, TeXMathSymbolEncoding, and TeXMathExtensionEncoding
to the oml, oms, and omx encodings respectively, but as the glyph names are
not the same as in texmital.enc, texmsym.enc, and texmext.enc respectively
a user might get problems with this. I must either ensure that the glyph
names are identical in both files or make sure the encoding names will not
be the same (the latter is much simpler).

What we would need to be able to resolve this problem is some kind of
survey of the current sources of math glyphs---which glyphs are available
from which sources and what names are they given? Does anyone know if such
a survey exists?