[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: radical thoughts
- To: Frank.Mittelbach@Uni-Mainz.DE
- Subject: Re: radical thoughts
- From: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
- Date: Fri, 23 Jan 1998 15:31:21 +0100
- Cc: math-font-discuss@cogs.susx.ac.uk
Frank.Mittelbach:
> so possible solutions that one needs to weight against each other:
> - a macro solution like the one suggested by Matthias
> - live with the fixed ratio
> - put the glyph back into one of the other encodings with the result
> that this encoding then is TeX specific
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.
As for imcompatibilities, we had some changes before in the transition
of LaTeX 2.09 -> 2e with cmmib[5-9] and cmbsy[5-9] suddenly becoming
available where we only had one size, i.e. cmmib10 and cmbsy10 before.
> another possible solution that i offer (without having thought it
> through) is the following:
> - put it into one of the other encodings but have the actual glyph in
> the physical font raised into a normal position (so that it really
> can be used by other programs if they wish to).
> Then implement it in TeX by either providing a TeX specific font
> variant in which it is lowered (if it is a virtual one that should
> pose no problems if it is a real font that would mean ...) or, for
> example, by having an additional font dimen going with the math
> fonts that specifies how to position the radical. i would presume
> that this would allow for a much simpler macro solution.
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.
- deduce the thickness of the rule to put on top of the square root
from the default rule_thickness (\fontdimen8) instead of taking it
from the nominal height of the radical glyph
- center big radicals with respect to their total height and depth,
exactly as it is done for big delimiters.
This would solve the problem of making fonts TeX-specifc by requiring
unusual glyphs once and for all.
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.
As far as I can tell, the equivalence of the default rule_thickness
and the height of the radicals is always satisfied by design in
cmex and cmsy (although I don't understand why the rule_thickness
is bigger in cmsy/cmex7 than it cmsy/cmex10).
In MathTime, MTEX seems to be a little inconsistent (values ranging
from 0.4pt and 0.46pt while the default rule_thickness is 0.046pt),
In the Mathematica fonts, several glyph metrics were unusable anyway
as they included some whitespace above the top rule as part of the
nominal glyph height, which had to be canceled out in the mtx files.
In both cases, I don't think that the differences are intentional.
> However, perhaps the best solution is to actually put it back into an
> encoding that is loaded always in three sizes. I'm not so keen on the
> macro solution as it looks to me as if we work hard trying to solve
> something via complex (and thus error prone) macros which should work
> automatically, ie should be specified by the font.
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.
Cheers, Ulrik.