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

Re: preliminary EuroTeX paper for review


> This paragraph seems to me to be misleading:

>   Plain \TeX{} and \LaTeX{}~2.09 occupy a number of additional
>   math families for extra math alphabets such as text italic,
>   bold, typewriter, or sans~serif, which may be of interest in
>   typesetting computer programs, but are relatively rare in
>   mathematics.  In \LaTeXe{} these math families are no longer
>   needed since the switching between math alphabets is implemented
>   differently.

> \LaTeXe{} does use math families to implement \mathbf \mathsf \mathtt
> (ie things declared with \DeclareMathAlphabet) but they are allocated
> dynamically, thus each uses up one math family only if it is
> used in a document.

Sorry, I confess that I never actually looked at the internals of 
the NFSS code, so I must have misunderstood it.  Perhaps the LaTeX2e
documentation was misleading and gave a wrong impression?

> More generally, I have worked with systems that use bold and sans
> serif alphabets, and even bold sans serif.  I certainly do not think
> one can call the use of \mathbf rare, which is what seems to me to be
> implied by this paragraph read as a whole.

Oops.  Perhaps I meant to say "some of which are relatively rare",
e.g. typewriter or text italics.

> Something unimportant but vaguely related to this.  In a different
> context the paper mentions `sans glyphs' for the MC encoding: I have
> never been able to imagine what a sans serif version of many of these
> glyphs could possibly look like but I guess that is just my limited
> imagination!

Well, I have seen some physics texts using lowercase Greek letters for
tensors, which should be set in bold sans serif oblique according to
the official rules.  Presumably such a version of lowercase Greek
should be designed using a uniform stroke thickness and omitting the
hooks or serifs, but designing a bold sans oblique version clearly
distinguishable from bold italics lowercase Greek will not easy.

> The names newmath.sty and oldmath.sty sound to me like amsmath.sty.
> Perhaps newsymb.sty and oldsymb.sty, which sound like amssymb.sty,
> would be less likely to confuse (me, at least:-)?

I'll leave that to Matthias.  We can still change it later.

> The rest are not directly comments that affect the content of the paper:

>> For most of the code,
>> preparing a Plain \TeX{} version simply means rewriting
>> \cs{DeclareMathSymbol} statements as straight-forward
>> \cs{mathchardef} or \cs{mathcode} assignments.

> Or (easier?? and better?) set up a plain-compatible def of
> \cs{DeclareMathSymbol} and input the same file.

Sure, having a Plain TeX implementation of NFSS2 as a basis would
make things easier, but if we haven't got that, the translation
should nevertheless be straight-forward.

>> In addition to the slash (`$/$'), and those punctuation marks
>> that were included in the {\OML} encoding for kerning reasons,
>> the {\MC} encoding will also contain the basic-size delimiters
>> (parentheses, square brackets, curly braces, angle brackets).

> As I understand them, the rules in App G imply that, with the normal
> set-up, there will never be any kerns between an opening or closing
> delimiter and the glyph that follows it, whatever the font says about
> kerning the relevant slots.

True, but if you really insist on kerning the delimiters with the
letters, you could still redefine the opening or closing parens as
ordinary symbols.  After all, the slash is a \mathord for exactly 
the same reason.  (Yet another possibility might be e-TeX or NTS.
Wouldn't it make sense to allow kerning between opening + ordinary
or between ordinary + closing, if you could change the rules?)

>> it loses the ability to
>> have kerning between the upright and italic Greek letters.

> Not a great loss?

Well, MathTime does have that.  Mathematica as well (considering
that the default set is upright capitals and italic lowercase).
Depends on whether you consider it important.

Cheers, Ulrik.