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

Re: preliminary EuroTeX paper for review

Ulrik wrote --

> > \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?

Oh, I wouldn't know about that:-) ... but, to quote the author of the
standard reference work on \TeX{} whenever I claim that some arcane
fact does not appear there: `surely it is clear from this extract'!
This extract is from fntguide, see last sentence:

  |\DeclareSymbolFontAlphabet| \arg{math-alph} \arg{sym-font-name}

  Allows the previously declared symbol font \m{sym-font-name} to be
  also the math alphabet \m{id} (in all math versions).

  This declaration should be used in preference to
  |\DeclareMathAlphabet| and |\SetMathAlphabet| when a math alphabet is
  the same as a symbol font; this is because it makes better use of the
  limited number (only 16) of \TeX's math groups.

This is the only mention I could find of groups(=math families), apart
from plugs for TUG!

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

But then the automagic spacing built into the math-list handling would
not happen.

> After all, the slash is a \mathord for exactly
> the same reason.

Not quite: it is an ord because it was not classically set with
space around as was classically used around +, -, \times but, because
it lacks this space and is asymetrical in shape, it needs kerning
(with almost every ord, and any bin that might becoame an ord).

> (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?)

Looking at the code suggests that it would be straightforward to
extend the kerning behaviour after an ord to: bin, rel, open, close,
punct and maybe op; so you should make this an etex request if it would
help your system.