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

**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.

- Prev by Date:
**Re: radical thoughts** - Next by Date:
**Re: radical thoughts** - Prev by thread:
**Re: radical thoughts** - Next by thread:
**Re: radical thoughts** - Index(es):