[Next] [Up] [Previous]
Next: How define-text-object works Up: Recognizing high-level document Previous: Constructing the quasi-prefix

Macros introduce new object types

  The previous sections described our document model and the techniques used to construct high-level representations given documents that conform to this model. The TeX macro facility [Knu86][Knu84] allows the definition of new markup commands, making La)TeX extensible. Macros permit the author to abstract away layout details when writing the document. To give an example, the command \kronecker is not present in La)TeX. An author can extend La)TeX by defining

[LVerbatim613]

and then write

[LVerbatim618]

The definition for \kronecker has extended the markup language. LaTeX [Lam86] itself is a good example of how TeX macros can be used to implement a language for encoding document structure.

The presence of user-defined macros in documents presents an interesting challenge for a system like AsTeR . Our goal is to handle books and technical documents written in La)TeX, so recognizing the extended logical structure introduced by the definition of new macros is therefore essential. In general, macro expansion can perform any arbitrary computation permitted by the TeX language. Hence, it is impossible to directly translate the macro expansion into an audio rendering. The TeX primitives are visual layout operators, and translating a TeX macro directly into an audio rendering rule would imply a one-to-one mapping between the visual and audio rendering.

As explained in s:aster-motivation, visual renderings are attuned to a two-dimensional display, and audio renderings need to be attuned to the features of an auditory display. Further, expanding a TeX macro loses structural information; when all macros in a document have been expanded, only the visual layout remains.

The first step in solving this problem is to represent user-defined macros in our high-level document model. Producing audio renderings of such instances will then be equivalent to rendering any other object present in the model.

Macro definitions introduce new object types. Thus, defining \kronecker is equivalent to adding object kronecker to the set of objects present in the document model. A macro definition in La)TeX has two parts; the first part declares the macro and its number of arguments; the second part specifies how instances of this macro call are to be displayed. Translating this to the object-oriented model, the first part of the macro introduces a new object type; the second part is a rendering rule for instances of this object.

We first describe how the recognizer is extended to handle instances of the new object introduced by a macro definition. We specify the following information about the new macro and the associated object type:

Macro name:
The name of the macro.
Number of arguments:
The number of arguments taken by this macro.
Processing function:
Name of a processing function that parses instances of this macro call. This function is synthesized automatically.
Object name:
Name of the new object type introduced by this macro. Calls to this macro appearing in the document will be converted to instances of this object type.
Precedence:
If the new object is an operator, its precedence is declared in terms of one of the existing operators. See t:precedence for the precedence table.
Super classes:
Super classes of this new object. The new object will inherit the behavior of its super classes. Thus, since \kronecker will be used as a binary operator, we can declare it as such.
Arguments are called:
Contextual names for the arguments of this macro. For example, the left-hand side of an inference is called its premise, the right-hand side its conclusion. If \inference is defined as a macro with two arguments, then we can supply these contextual names to define-text-object. Such information is used to generate sophisticated audio renderings.

This information is supplied by calling Lisp macro define-text-object. We illustrate this in the case of \kronecker in fig:define-kronecker. The Lisp macro itself will be described in s:define-text-object.

 

 [thesisfigure641]


: Extending the recognizer to handle user-defined macros.

Note that our recognizer has more information about the new macro than TeX. This is consistent with the fact that our internal representation is richer than the TeX representation, as described in s:quasi-prefix.

To summarize, we model a macro as:

A call to the macro in the document creates an object of the type introduced by that macro.

To continue with the example of kronecker, given

[LVerbatim652]

LISPIFY converts it to

[LVerbatim655]

LISPIFY marks the La)TeX macro instance as a a control sequence (cs). The recursive descent recognizer performs the following steps on encountering calls to macro \kronecker:

Function kronecker-expand constructs an instance of object kronecker. At this point, this instance of object kronecker has its children set to null. The input list is thus converted to a list containing three math objects shown below.

[displaymath5480]

In the above list, only the types of the objects are shown. This list is now processed by function inf-to-pre to produce the quasi-prefix form. Since class kronecker is a subclass of binary-operator with the same precedence as multiplication, the result is a tree with kronecker as the root and with two children, one each corresponding to [tex2html_wrap5492] and [tex2html_wrap5494].

In the above, [tex2html_wrap5496] and [tex2html_wrap5498] may be arbitrarily complex pieces of La)TeX markup; the recursive nature of the recognition algorithm will set the children of object kronecker to the operands in their processed form. For example, we can now build an internal representation for the following equation:

[displaymath5481]

which would be written in La)TeX as

[LVerbatim683]





[Next] [Up] [Previous]
Next: How define-text-object works Up: Recognizing high-level document Previous: Constructing the quasi-prefix



TV Raman
Thu Mar 9 20:10:41 EST 1995