[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: math fonts (and all those glyphs)

Although I'm very welcoming discussions

   I'M  S O R R Y  TO SAY   % (that's a properly kerned upper case
                            %  with letter spacing as additional emphasis :-)

that I think this discussion right now is totally going into the wrong
direction. I know that Johannes and perhaps others think that there
are several shortcomings in Justin's work (or perhaps better say in
the combined effort of many people back then) and that there are many
symbols out there that should find a place in that encoding ... and
yes there are shortcoming and there might be glyphs missing and and


let me assure you that there have been design goals and a lot of
reasoning that went into that final proposal and that it was not a
"committee" result.

let me give you a view of the major goals (from the top of my head, a
better explanation can probably be found in Justin's epos although I
do admit that sometimes the pearls are difficult to find therein ---
this is not a criticism of Justin's work, it is simply an observation
and it is due to the fact that we spend 90% of his stay in Mainz on
working on the actual content and so there wasn't enough time to
actually polish the result) ... back to the goals:

 - 100% glyph compatibility with existing font usage: that means
   kerning needs to be preserved if existing to make it possible to,
   say, reproduce a paper written with CM math fonts or cm+AMS exactly
   as before if passed through LaTeX or AmSTeX (or plain TeX) but now
   using the new fonts

 - keep within kerning limitations of TeX: that means you have to
   combine those characters in a single font that are likely to be
   kerned --- an impossible task with TeX (as we are not in Omega) as
   in principle one might want to kern any symbol with any (other)
   symbol. Nevertheless there are important basics that one better
   does not violate

 - low usage of font families as that is a major restriction of TeX

 - on the other hand keep characters with similar design within a
   single font to make exchange of individual fonts (or font groups)
   possible, eg try to put geometric symbols together as well as
   putting similar textual characters together

 - finally: don't go overboard with finding all kind of new characters
   and symbols that one might want but which will result in the
   encoding set as a whole becoming yet another TeX only encoding

All or most of all the above and probably other stuff I forgot have
been achieved quite well with the final proposal perhaps with the
exception of the "finally" item. In other words if there is something
that one might to think of is taking stuff OUT not IN.

Why that?

very simple: because I hope that this encoding will be able to serve
the TeX community well and that means that we do get not only a
CM-based implementation of it but also an Euler implementation and a
Lucida math and a Mathtime and hopefully perhaps even more.

If we clutter that encoding with additional symbols that are not to be
found in professional fonts at all or very likely you can forget about
this aspect and this aspect on the long run is in my opinion the more
important one (otherwise we can live with what we do have right now
why change? and accept that if we try to use any other math fonts then
either we don't find any or it doesn't come in a compatible encoding
or ...)

[as an aside: this is also my major concern about the current
evolvement of the TS encoding that while it contains a lot of
interesting characters and gets more and more of them doesn't live up
to its promise as it again divides the world into TeX and the rest
only that the rest is a huge number of professional typefaces (and
their expert versions) so i think it would be much better to separate
TS into something that can be expected to be implemented by most
available fonts and a bigger encoding which would not and i'm
intending to go that path ... if anybody like to reply to that aside
please change the subject line to "TS encoding issues" ]

So no. I'm against taking the proposal apart before it is implemented
and implementing means not only producing a basic virtual font
implementation (don't get me wrong I'm really impressed of seeing
Matthias work and i'm very grateful for it) but it also means

 - implementing the kerning and the additional kerning stuff of the
   proposal (eg integral kerning etc etc)

 - implementing the needed macros

 - and unfortunately also somehow the missing glyphs

Open issues like how to arrange the symbols within one (!) encoding
(as this is not specified) clearly needs some decisions but I agree
with Matthias that some arbitrary solution in the first go would
do. Nevertheless applying certain principles here does no harm and all
those comments were well-taken.

However, once that is done and we are already quite close to that
point I think, we should get of the next hill and that is:

  take the euler math fonts and implement them as well

why? because only if we really are able to switch fonts on
demonstration (and apply the proposal to a different font family) we
can actually see how well it works. (in fact applying it to mathtime
and/or lucida would be also very helpful but in contrast to euler less
people would be able to actually play with it then so i think euler is
a better second solution and the commercial fonts only thereafter or
in addition)


i would return and open up the discussion and has started right now.
in fact a lot of those comments and suggestions today did came up
during the development of the proposal not only on the discussion list
but also in all those long nights here in Aston and elsewhere. So I
think I can safely claim that it is very likely that most of them have
been considered and for some reason or other have been rejected

not that i want this being understood as: "we don't care we know
better" it is only that I don't have much faith in wading through the
same discussions again without actually having something real to look
at and play with it and (get the arguments substantiated) and for this
i think it needs an implementation NOW and one for two sets of math
fonts as explained above.