Mathematics
There are various different ways in which LATEX2HTML can handle
mathematical expressions and formulas:
- give a textual representation (“simple” math);
- make an image of the complete formula or expression;
- combination of textual representation and images of
sub-expressions;
- SGML-like representation built using abstract “entities”;
e.g. for the HTML-Math model, or for MathML.
Which is the most appropriate normally depends on the context,
or importance of the mathematics within the entire document.
What LATEX2HTML will produce depends upon
- the version of HTML requested;
- whether or not the special `math' extension has been loaded;
- whether the no_math command-line optionnomath
has been specified, or (equivalently) the $NO_SIMPLE_MATH
variablenomath has been set in an initialisation file.
The strategies used to translate math expressions are summarised
in the table belowTable mathconv3 for HTML 3.0+
and the subsequent tableTable mathconv2 for HTML 2.0.
Table:
Mathematics translation strategies,
for HTML versions 3.0 and 3.2,
using SUP and SUB tags
and TABLEs
`math' |
switch |
strategy adopted |
not loaded |
math |
textual representation where possible,
else image of whole expressions |
not loaded |
— |
always generates an image of the whole
expression/environment |
loaded |
— |
uses entities and MATH tags; e.g. for HTML-Math
(or MathML in future) |
loaded |
no_math |
textual representation where possible,
with images of sub-expressions |
|
The default behavior, with no command line options,
is to generate images for all math expressions, which makes
the appearance of all mathematical expressions consistent.
This is what was used when creating
this manual.
Since the HTML 2.0 standard does not include
superscripts and subscripts, via the SUP and SUB tags,
the options are more limited. In this case creating images of sub-expressions
is not so attractive, since virtually the whole expression would
consist of images in all but the simplest of cases.
Table:
Mathematics translation strategies,
for HTML version 2.0
`math' |
switch |
strategy adopted |
not loaded |
— |
textual representation where possible,
else image of whole expressions |
not loaded |
no_math |
always generates an image of
the whole expression or environment |
loaded |
— |
entities and MATH tags for HTML-Math |
loaded |
no_math |
always generates an image of the whole
expression or environment |
|
Here are some examples of mathematical expressions and environments
processed by LATEX2HTML using different strategies.
They are automatically numbered ...
(1)
... with some gratuitously ácçënted text in-between ...
|  |
|
| |
|  |
|
| (2) |
The latter example uses an eqnarray environment
and the nonumber command to suppress
the equation number on the upper line.
The default image format is Scalable Vector Graphics (SVG),
which looks crisp at all resolutions. If bitmap image
formats are used (PNG or GIF), various options are
available to control antialiasing and the resolution
of the images. These options are discussed in the
following sections.
For combinations of options that do not generate images for all
math expressions, it is possible to control image generation
at the level of individual expression.
By inserting an \htmlimage{}
command into a math,
equation or displaymath environment, a single image
will be created for the whole environment. For an eqnarray
environment, this will lead to having a single separate image
for each of the aligned portions.
The argument to htmlimage need not be empty, but may contain
information which is used to affect characteristics of the resulting
image. An example of how this is used is given belowex:aalias,
and a fuller discussion of the allowable options is given in
the next sectionSection imgcon.
Scale-factors for Mathematics.
For bitmap image formats (PNG or GIF, as opposed to SVG),
the scale factor controls the image resolution.
When a bitmap image
is made of a mathematical formula or expression,
it is generally made at a larger size
than is normally required on a printed page.
This is to compensate for the reduced resolution of a computer screen
compared with laser-print.
The amount of this scaling is given by the
value of a configuration variable $MATH_SCALE_FACTOR,
by default set to 1 in latex2html.config.
A further variable $DISP_SCALE_FACTOR is used with
`displayed math' equations and formulas.
This value multiplies the $MATH_SCALE_FACTOR
to give the actual scaling to be used.
The main purpose of this extra scaling is to allow some clarity in
super/subscripts etc.
Anti-aliased Images.
Here areFigure showseq:pics the same equations
as previouslyeq:demo, this time as images of the
complete contents of the equation environment,
and complete aligned parts of rows in an eqnarray.
For a comparison, the second group of images use anti-aliasing effects,
whereas the first image does not; a 600 dpi printing is probably necessary
to appreciate the difference in quality. Compare these images with those in
a later sectionSection printqual.
Figure:
Images of equation displays, at normal screen resolution
(3)
|
These images of the whole environment were created
using the htmlimage command, to suppress the extended parsing
that usually occurs when the `math' extension is loaded; viz.
\begin{equation}
\htmlimage{no_antialias}
\Phi_{l+1,m,n} = \Bigl(\Phi+h\frac{\partial\Phi}{\partial x} +
...
\end{equation}
%
\begin{eqnarray}
\htmlimage{}
\frac{\Phi_{l+1,m,n}-2\Phi_{l,m,n}+\Phi_{l-1,m,n}}{h^{2}} +
...
\end{eqnarray}
Further aspects of the options available when generating images
are discussed in the next sectionimgcon, in particular
with regard to the quality of printed imagesprintqual.
Another way to force an image to be created of a mathematical expression,
when global settings are not such as to do this anyway,
is via the mbox command having math delimiters within its argument.
Normally mbox is used to set a piece of ordinary text within a
mathematics environment. It is not usual to have math delimiters
$...$ or (...) within the argument of an mbox.
Whereas earlier versions of LATEX2HTML simply ignored the mbox
command (treating its argument as normal text),
the presence of such delimiters now results in an image being
generated of the entire contents of the mbox.
It is not necessary for there to be any actual mathematics inside
the mbox's contents;
e.g. \mbox{...some text...${}$}
will cause an image to be created of the given text.
The parbox[align]{
width}{
text}
command also generates an image of its contents,
except when used within a tabular environment, or other
similar table-making environment.
Here the important aspect is the width specified for the given
piece of text, and any special line-breaks or alignments that
this may imply. Hence to get the best effect, LATEX is used
to typeset the complete parbox, with its specified width,
alignment and contents, resulting in an image.
If you need HTML 2.0 compatible Web pages,
and have a document with a great many displayed equations,
then you might try using the heqn package.
Inclusion of the heqn.sty file has absolutely
no effect on the printed version of the article,
but it does change the way in which LATEX2HTML translates
displayed equations and equation arrays.
It causes the equation numbers of the equation
environment to be moved outside of the images themselves,
so that they become order-independent and hence recyclable.
Images that result from the eqnarray environment are also recyclable,
so long as their equation numbers remain unchanged from the previous run.
The nonumber command is recognised
in each line of the equation array, to suppress the equation number.
A side-effect of this approach is that equation numbers will
appear on the left side of the page.
The heqn package requires the html package.
Using HTML Version 3.2 the heqn package is quite redundant,
since equation numbers are placed in a separate TABLE cell
to the mathematical expressions themselves.
It is not required and should not be requested, since this will
override some of the improved functionality already available.
Subsections