Joerg Knappen: > I am thinking of a new subencoding MA (Math Alphabetic) which is in fact > OMA plus lowercase greek letters plus completed uppercase greek letters > plus some letterlike symbols (\dbar coming to my mind as an obvious > candidate for this, \partial and \Nabla, too. This list not complete.). > Then we could have a differently organised group of fonts: > Current situation Justin's Proposal alternative proposal > OT1 (cmr) T1 (?) MC1 * > OML (cmmi) MC MC2 > OMS (cmsy) MSP MSP > OMX (cmex) MX MX ** > U (all other) MS1 MS1 > MS2 MS2 > MA is subset of both MC1 and MC2, where MC1 contains math roman and MC2 > math italic. Further fonts (without symbols, but purely MA encoded) can > provide math text italic, math sans serif and math typewriter on demand. If the MA subencoding would include both sets of greek alphabets (upright and italics), you would effectively arrive at the same situation as having extra MC-encoded fonts for all math alphabets, regardless of whether or not one of them (upright roman) would be used in \fam0 as the operator font or not. > * T1 for math roman is not explicitly stated in Justin's proposal, as far > as I can see. IIRC, it was definitely mentioned somewhere that the operator font would be T1 encoded. It it wasn't in Justin's report, it must have been in Alan's workshop summary that was circulated on m-f-d, before it was submitted for publication in the Aston proceedings (TB 14#3). I don't think there was ever an intention to allow using arbitrary characters with diacritics for use in math operators. Rather, it is more likely that T1 was quoted just for convenience, as one would have that anyway as the default text font. If that was indeed the reason, any font with ASCII letters in their usual positions would do just as well, including OT(n), T(n), 8a, 8r, etc. > ** MX may need splitting in tow parts. In this case, separating the > vertically extensible things from the horizontally extensibles ones looks > preferable to me. I'd agree with that in principle. However, as for whether or not splitting MX, we shouldn't forget the design goal of providing plain compatibility with 4 families and AMS compatbilitiy with 6 families. To achieve this, I'd suggest a somewhat different strategy, namely: (a) having only one MX font for compatibility that restricts the big delimiters to the usual range of sizes and the wide accents to perhaps 8 different widths, while also providing big operators (including some new ones). (b) having an alternate MX1 + MX2 font set that provides additional sizes of big delimiters and wide accents, organized in the most reasonable way without any compatibility constraints, e.g. having big ops + wide accents in one font and delimiters in the other. This alternate MX1 + MX2 set would be activated by an optional package if the author or publisher so desires, somewhat along the lines of optionally loading the "exscale" package. Opinions? Cheers, Ulrik.