Equation display styles and context-sensitive rendering

[Ludovic Courtès]

Hi,

In "The TeXbook" (Chapter 17), Knuth explains that mathematic
typesetting conventions can be summarized as 4 styles:

  1. display style (formulas displayed on lines by themselves);
  2. text style ("in-line" formulas, i.e., embedded in text);
  3. script style (formulas used as superscripts or subscripts);
  4. scriptscript style (second-order superscripts and subscripts).

Each style has its own font size and space between binary operators[*].
When a fraction is rendered in "display" style, then its numerator and
denominator should be rendered in "text" style; when a formula is in
text style, then its exponents should be in "script" style, and so on.
IOW, formula style is context-sensitive.

Currently, the `eq' package only implements a subset of these
conventions (see address@hidden', address@hidden', etc.).  It does not implement
in-line formulas (what address@hidden' does is not sufficient to implement 
in-line
formulas).  For instance, in a in-line fraction the numerator and
denominator should be typeset with a smaller font than when they appear
"displayed".  OTOH, a simple in-line addition, for instance, can be
typeset with the same font size as the rest of the text.

I believe that it is impossible to implement such rules in current Lout.
However, I think that little changes could make it possible.

address@hidden' et al. currently work by changing the `f', as well as the
user-defined `y' and `z' units so that sub-formulas inherit appropriate
size and spacing information.  address@hidden' and address@hidden' allow the
propagation of context-sensitive style information but (i) they are
specific (they can only hold lengths) and (ii) they are unsafe (several
packages may use them "concurrently", thereby leading to inconsistent
behavior).

I think we could relatively easily generalize the mechanism provided by
address@hidden', and also address@hidden', address@hidden', etc.---basically, 
what is
currently referred to as "style" or "environment".  The effect of Lout's
"style" is actually similar to "dynamically-scoped variables",
"parameter objects" and "fluids" found in Lisp dialects [0] (I think I
already mentioned that on this list).  By providing the more generic
abstraction of "parameter objects" (or whichever name you prefer), Lout
could allow the implementation of context-sensitive rendering.  What I
have in mind is something like this:

  # Create a new parameter object.
  def @CurrEqStyle { @MakeParameter }

  def @SomeFunc
  {
    @CurrEqStyle @Case {
      "inline" @Yield { ... }
      ...
    }
  }

  # Change the value of the parameter object.
  @CurrEqStyle @Parameterize value { "inline" } {
    # From now on, any invocation of address@hidden' will
    # evaluate as "inline".
    @SomeFunc
  }

Such parameter objects could hold any Lout object, not just lengths.
Using them is "safe" since packages can only access them if they can
access the symbol holding them (e.g., if address@hidden' is private
within address@hidden', then the address@hidden' package cannot access the 
address@hidden'
parameter object).

Incidentally, it would then be possible (although not necessarily
desirable) to implement address@hidden' and other style-related functions in
terms of parameter objects:

  def @CurrFont { @MakeParameter }

  def @Font left f right body {
    @CurrFont @Parameterize value { f } { body }
  }

I started looking at how parameter objects could be implemented but I
I'd need some guidance.  The main issue I am facing is the
implementation of address@hidden': First, its left parameter should not
be evaluated (i.e., address@hidden' should behave pretty much like a
macro), and second, I don't clearly understand how the `value' and
`body' arguments can be fetched (in `z08.c').  Perhaps we can discuss
this in further details if the approach seems valuable at all.

Thanks,
Ludovic.


[*] There are actually 8 styles because formulas appearing as the
    denominator of a fraction require exponents to be lowered a bit.
    Knuth refers to them as "cramped styles".

[0] http://srfi.schemers.org/srfi-39/srfi-39.html