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

Re: radical thoughts

Ulrik Vieth writes:

 > I think the best solution might be to put one size into MXP and load
 > MXP in three sizes by default.  My impression is that apart from the
 > radicals it would allow to get more appropriate sizes of big operators
 > and big delimiters in scriptsize and scriptscriptsize formulas, e.g.
 > if you have something like
 > 
 >    e^{\sum_n x_n}   or   e^{i \left( k x - \omega t \right)}
 > 
 > (I'm not sure about the side effects on wide accents at the moment.)
 > 
 > A macro solution as presented by Matthias would then only required
 > in compatibility mode, if you insist on loading MXP at one size only.

you may as well be right and indeed if that is the way to go then
having a macro solution for the compatibility case is not too bad.

in addition however, you might want to have the radical in high
position in the other font as well as to make them suitable for
non-TeX usage.

 > Well, if we could assume e-TeX, the simplest solution would be to propose
 > revising the algorithm for the placement of radicals to be more like the
 > delimiters, i.e.

careful, there is a distinction between etex and NTS, not sure if
according to etex ideas this can be incorporated. but it is worth
thinking about

 > It would be interesting to check out if there are any math extension
 > fonts designed for TeX where the actual height of the radical glyphs
 > is any different from the default rule_thickness.  If not, we could
 > safely assume that the mechanism of deducing the rule height from 
 > the glyph metrics isn't really needed anyway.

i find this argument dangerous. all we have experienced so far is that
because Don made these kind of implicit assumptions we run into
problems because fonts other than cm do not necessarily obey
them. thus i would vote against an extension that builds in another
unproven assumption.

 > As mentioned above, loading MXP in three sizes might be the easisest
 > solution at the expense of sacrificing 100% compatibility.  It remains
 > to be seen if there are any side-effects speaking against this option.

yes i think checking for possible side effects and if not going for
this solution together with a macro based compat mode looks most
promising after this exchange of ideas.

cheers
frank