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

subencodings, spltting MX (was: Capital greek letters)

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.


Cheers, Ulrik.