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

Alejandro Lopez-Valencia palopez@earthling.net
Mon, 20 Nov 2000 17:41:54 -0500

I probably reported the bugs too soon because I found a few more jewels. This
time, to be really sure, I compared the AFMs of MathTime, Adobe
Lucida and Lucida New Math.

       should be
oms.etx        texmext.enc
barex          vertextendsingle
bardblex       vertextendouble
angle*         angbracket*

all these changes broke oms.mtx, and I had to do some heavy editing and
comment out the references to ``bar'' I couldn't resolve to real glyphs.

Checking Adobe's UNICODE 2.1 to postscript names and Adobe's corporate use
block, it seems that the math encoding files were created to work with
Adobe  Symbol instead of CMEX/MathTime/Lucida's. Those Adobe Symbol names
should probably go in a renaming hack file (for mathptm and such)? I
haven't fiddled with oms and oml just yet, but they are probably a can of
worms too... I continued fiddling with omx last weekend and...

At 4:59 PM +0100 20/11/2000, Lars Hellström wrote:
>At 14.00 +0100 2000-11-18, Alejandro Lopez-Valencia wrote:
>>I have found a couple of bugs in the math etx and mtx files recently
>>uploaded to CTAN.
>>Comparing omx.etx and texmext.enc, there are three misnamed glyphs in
>Thanks! I've changed this now.
>>As well, mathex.mtx fails on line 110:
>OK, I've changed it to
>   \setint{textoperatorsize}{
>      \add{\height{product}}{\depth{product}}
>   }
>   \setint{textoperatorsize}{1000}
>   % Default taken from cmex10.

Will it work? (Have to test it yet :) My fix is probably wrong, but,
considering that there are only one glyph pair in the omx encoding, namely
/producttext and /productdisplay and it is a calculation for text math
glyphs, I changed the lines to:


Thus, what about:

   % Default taken from cmex10.

P. Alejandro López-Valencia            Ecologist, Conservation Biologist
                            4N36 74W05
     kenkon itteki                     Heaven and Earth at one stroke