[math-font-discuss] what is the status of new math font encodings (mathfont-0.59a)?

[Ulrik Vieth]

Joe Wells wrote:
> What is the status of the implementation of the new math font
> encodings (the package mathfont-0.59a)? 
 > Is it ready for use or is it deeply flawed?

 From my point of view (speaking as one of the original developers)
the project in its current form is certainly dead after being put
on hold for so many years.

However, this doesn't meant that the project was deeply flawed.
It was simply side-tracked and put on hold after EuroTeX 1998 when
a related project (i.e. the Unicode math effort) came in between.
After that work was finished, some years had passed and the people 
involved in the orignal development didn't have time to continue
the work or simply had moved on to other projects.


 > The final available version is 0.59a. ... What does this mean?

Version 0.59a of April 1998 (available from www.tug.org/twg/mfg) is
indeed the last version that was released. While I don't know of any
serious bugs that would prevent its use, it was far from being ready
for production use and was never intended to be at that time.

Moreover, that version is a bit outdated now, so if you try to run
the Makefile to generate the fonts, you'll probably run into a number
of trivial but time-consuming problems where you have to make some
minor adjustments to get things running with the current versions
of fontinst (1.928 instead of 1.335) shipped with TeX Live 2007.


As for the reasons why the project came to halt and was never revived,
there are a number of issues involved.

1. Change of project goals and scope

Originally, the goal of the project was to develop math font encodings
for (La)TeX (within the constraints of 16 families of 256 glypshs) and
to provide example implementations by means of reencoding and enhancing
exisiting font sets (e.g. CM, Euler, MathTime, Lucida).

After EuroTeX 1998, that goal was more or less set aside by the efforts
to bring math into Unicode. While the Unicode math effort wasn't a bad
idea by itself, it brought along with it a lot of baggage in the form
of a large number of additional symbols, making it much more work to
provide "complete" implementations of math fonts and nearly impossible
to encode all those symbols in the limitations and contraints of TeX.

In the end, the question of how to encode and implement all of Unicode
math in traditional TeX engines has remained unresolved so far.
(Likewise, the STIX fonts project (www.stixfonts.org) has been going
on for so many years, and nobody knows what to expect if there really
is a release within the next 30 days.)

2. People and time constraints

At the time when the new math fonts for TeX were developed (in 1997--98)
the two principal developers were working in a University environment,
where they could afford to divert some of their time on TeX projects.
By the time Unicode math was finished and it would have been time to
revive the work on TeX font encodings, a number of years had passed
and the people involved had moved on to other jobs or other projects
where they didn't have time to continue the work.

(AFAIK, Matthias Clasen has left the TeX world behind completely and
is now working on Gnome at Redhat.com.  Myself, I am primarily a Java
programmer who only uses TeX as a hobby and attends TeX conferences
as a kind of vacation.)

3. Technology changes

At the time of 1997--98, most people were still working in an evironment
of DVI and/or PostScript where using PK fonts generated by Metafont
to provide extra symbols was OK for use in a prototype implementation.
Nowadays, most people are working in an evironment of PDF where PK fonts
are totally unacceptable and everyone expects Type 1 or OpenType fonts.
As a consequence, most of the font work we did in 1997--98 would have to
be redone now in a slightly diffent way.

Of course, the most obvious choice would be to use MetaType1 (consisting
of MetaPost and some scripting code) to generate Type 1 fonts instead of
PK fonts, but once you start this way, you probably don't want to stop
with partial fonts containing only the building blocks for virtual fonts
and you'll have to invest more work to go all the way towards a complete
implementation of the new font encodings in MetaType1.

4. Choices of font sets

At the time of 1997--98, choices of math fonts were still very limited.
Apart from CM, Concrete, Euler there were only the commercial MathTime
and Lucida sets and maybe some hacks like mathptm or mathppl.

In the meantime, quite a few additional sets of math fonts have appeared
such as txfonts, pxfonts, mathpazo, fourier, mathdesign, MnSymbol, but 
also TM-Math, HV-Math, IF-Math, PA-Math, BA-Math, CH-Math by MicroPress
and MathTimePro by PC TeX, etc.

While it is good to have additonal choices, most of these new font sets
use their own versions of slightly extended encodings and sometimes
even their own sets of extra symbols. In view of these developments,
the repertoire of available symbols and the choices of which symbols to 
include in which of the new math font encodings may have to be revised,
if you want to arive at a encoding that suits the needs of everyone.
Again, this means more work to do if you want to restart the project.


 > Is there any plan for additional development?

While there is certainly a need for new math font encodings to go with
recent font developments such as Latin Modern or TeX Gyre, there are
currently no concrete plans or developments going on.

Probably the best chances of getting some results out of it would be
for the TeX user groups to sponsor the development of math fonts in
the context of Latin Modern or TeX Gyre (at least Termes and Pagella).

Before doing so, however, one would first have to decide and agree on
what to do and what we want.

Option 1: OpenType fonts, Unicode math, but XeTeX or LuaTeX only

If you want to make a bold move towards the future, one might choose
to go for OpenType directly. In that case, you can probably forget
about TeX encodings and include most of Unicode math in one big font.

In order to do so, however, you have to be prepared to throw out 
backwards compatibility and lock yourself into the most advanced
TeX engines such as XeTeX or LuaTeX, where you are free to push
the limits as far as you want (e.g. 256 families of 65536 glyphs).

Option 2: Type 1 fonts for all TeX engines, but only subsets of Unicode

On the other hand, if you want to preserve compatibilty with older
TeX engines, you have to work within the limits and constraints of TeX
(i.e. 16 families of 256 glyhs) and you end up in a similar situation
where we started in 1997--98.

In that case, you can forget about implementing all of Unicode math
and you'll have to make some choices to arrive at a reasonable subset
of glyphs that can be implemented in most available font sets.

In the past, such decisions were partially based on wish lists of
nice-to-have things and personal interests of some participants,
leading to some unfortunate choices, such as including symbols that
are unavailabe in most font sets.

If I had to do it again nowadays, I would strongly argue to base
such decisions on what is really available in various font sets.
Thus, the minimum set would be the common subsetof symbols found
in each of the available font sets, while the maximum set would be
the combined set of all teh symbols found in any of the font sets.


 > Thanks for any explanations you can provide!

If you have read until here, you will realize that the whole subject
is a difficult matter, which has a long history attached to it.
As for future developments, I really can't tell what (if anything)
will happen or what should be done about it.

Maybe the long expected release of STIX fonts (if it ever happens) could 
trigger new results, such as bringing Unicode math to XeTeX shortly.
Maybe the development of OpenType support in XeTeX and LuaTeX will 
trigger further developments of math fonts for Latin Modern or Tex Gyre.

Personally, I won't be able to do much work simply for lack of time,
but if anything happens in the area of math fonts for Latin Modern or
TeX Gyre, I am willing to support the development with feedback and
expertise from past developments.

Now, it all depends on other people to make a move or take a decision.
Otherwise, the project will remain unfinished as ever.

Greetings,
Ulrik Vieth