The TeXFOTBuilder was initially written by David Megginson, but is
now maintained by Sebastian Rahtz. In a development sponsored by
Novare International (to whom many thanks!), Kathleen Marszalek
drastically improved the table support.
The job of the backend is to map DSSSL flow-objects into generic TeX
macro calls. Atomic flow objects appear as single
\insertOBJECT{} macro calls, while non-atomic
flow objects appear as nested pairs of
\OBJECT{}..\endOBJECT{}
macro calls.
The \insertOBJECT and
\OBJECT calls receive a single argument,
which is a list of definitions for inherited and non-inherited
characteristics (see below). For example, the following DSSSL
handler:
It is important to note that any characters with values
>255 will appear as \Character{value} macro
calls ie.
\Character{1024}
In addition to nearly all of the flow-object classes currently
supported by Jade, the TeXFOTBuilder generates two pseudo flow-object
macro calls:
\FOT{version}
\endFOT{}
These are guaranteed to appear at the very beginning and very end
of the .tex output file, and give your macros a chance to grab control
at both points. The argument to \FOT is the version of
the TeX markup generated by the Jade backend (currently 2). Macro
packages should check this for compatibility.
The output .tex file is not ready to be passed
directly through TeX or LaTeX -- instead, it is necessary to
have TeX macro definitions for all of the flow-object macros, and to
set default values for the characteristics. The macros can
use of TeX primitives, plain TeX, LaTeX, or any other format
which is convenient.
The SETTINGS argument to the flow-object macros will
contain a series of \def statements for both inherited and
non-inherited characteristics. These will appear only when the
characteristic's value differs from the standard default (in the case
of non-inherited characteristics) or from the current value (in the
case of inherited characteristics). Since these statements appear as
an argument, they will not take effect until you reference the
parameter explicitly.
The characteristics in the following table are inherited -- you
should set these to their default values only once, at the beginning
of the parse (but they should always revert to their previous values
after a flow-object has finished):
The characteristics in the following table are not inherited -- you
should set these to their default values at the beginning of
every relevant flow-object, before evaluating the
SETTINGS argument: