[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: radical thoughts
- To: firstname.lastname@example.org
- Subject: Re: radical thoughts
- From: Frank Mittelbach <Frank.Mittelbach@Uni-Mainz.DE>
- Date: Fri, 23 Jan 1998 13:07:57 +0100
Matthias Clasen writes:
> I have thought about an uglyness in our current proposal for
> the extensible encoding MXP: The text/script/scriptscript
> ratio is fixed, since we include the small radicals. I have
> worked on some ideas how we could avoid this while still
> being able to load the extensible font in only one size.
i agree that such a fixed ratio is probably the worst solution. so i
think one has to review the reasoning that resulted in this decision.
one was (if i remember correctly) that we wanted to free mist fonts
from TeX math font specialities (ie characters below the baseline in
that case), the argument being that unless this happens nobody can
ever sensibly use such fonts with other software. correct?
so in that case one question to ask is, does this really matter?
i remember i think Berthold stating that in fact this isn't a
practical problem but maybe i remember that incorrectly.
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
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.
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.