\input texinfo
@c %**start of header
@setfilename liblouisutdml.info
@include version.texi
@settitle Liblouisutdml User's and Programmer's Manual

@dircategory Misc
@direntry
* Liblouisutdml: (liblouisutdml). An xml to Braille Translation Library.
@end direntry

@finalout

@defindex semantic
@defindex style

@c Macro definitions

@c setting.
@macro setting{name, args}
@tindex \name\
@item \name\ \args\
@end macro

@macro settingref{name}
@code{\name\} setting (@pxref{\name\ setting,\name\,@code{\name\}})
@end macro

@c semantic action.
@macro semanticAction{name, args}
@semanticindex \name\
@anchor{\name\ semantic}
@item \name\ \args\
@end macro

@macro semanticref{name}
@code{\name\} semantic action (@pxref{\name\ semantic,\name\,@code{\name\}})
@end macro

@copying
This manual is for liblouisutdml (version @value{VERSION},
@value{UPDATED}), an xml to Braille Translation Library.

This file may contain code borrowed from the Linux screenreader
@acronym{BRLTTY}, Copyright @copyright{} 1999-2009 by the
@acronym{BRLTTY} Team.

@noindent
Copyright @copyright{} 2004-2009 ViewPlus Technologies, Inc.
@uref{www.viewplus.com} and Copyright @copyright{} 2006,2009
Abilitiessoft, Inc. @uref{www.abilitiessoft.org}.

@quotation
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser (or library) General Public License
(LGPL) as published by the Free Software Foundation; either version 3,
or (at your option) any later version.

This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser (or Library) General Public License LGPL for more details.

You should have received a copy of the GNU Lesser (or Library) General
Public License (LGPL) along with this program; see the file COPYING.
If not, write to the Free Software Foundation, 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301, USA.
@end quotation
@end copying

@titlepage
@title Liblouisutdml User's and Programmer's Manual

@subtitle Release @value{VERSION}
@author by John J. Boyer

@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@c Output the table of contents at the beginning.
@contents

@ifnottex
@node Top
@top Liblouisutdml User's and Programmer's Manual

@insertcopying
@end ifnottex

@menu
* Introduction::
* Transcribing Documents::
* Customization Configuring liblouisutdml::
* Connecting with the xml Document::
* Special Features::
* Special Formats::
* Implementing Braille Mathematics Codes::
* Programming with liblouisutdml::
* Example files::
* Configuration Settings Index::
* Semantic Action Index::
* Style Index::
* Function Index::
* Program Index::
* Concept Index::

@detailmenu
 --- The Detailed Node Listing ---

Transcribing Documents

* Transcribing XML files with file2brl::
* Transcribing Text Documents::
* Transcribing Poorly Formatted Documents::
* Transcribing html Documents::

Customization: Configuring liblouisutdml

* outputFormat::
* translation::
* xml::
* style::

Connecting with the xml Document - Semantic-Action Files

* Semantic Actions Overview::
* Semantic Actions in detail::
* Pseudo-actions::
* Using XPath Expressions::
* Using Macros::

Pseudo-actions

* include::
* newentries::
* namespaces::

Special Features

* Table of contents::
* Back-translation::
* Reformatting::
* Interlining::
* Browser-Friendly Output::
* CDATA Sections::
* End notes::

End notes

* Use of Endnotes::
* Output::
* Configuration::
* Styles::
* Semantic Actions::
* Example::

Special Formats

* Tables::
* Reserving Space for Graphics::
* Displayed Text::
* Displayed Mathematics::
* Spatial Layouts in Mathematics::
* Arithmetic Examples::
* Poetry::
* Dividing a Book Into Volumes::

Programming with liblouisutdml

* License::
* Overview::
* Files and Paths::
* lbu_version::
* lbu_initialize::
* lbu_translateString::
* lbu_translateFile::
* lbu_translateTextFile::
* lbu_backTranslateFile::
* lbu_free::

@end detailmenu
@end menu

@node Introduction
@chapter Introduction

liblouisutdml is a software component which can be incorporated into
software packages to provide the capability of translating any file in
the computer lingua franca xml format or plain text into properly
transcribed
braille. This includes translation into grade two, if desired,
mathematical codes, etc. It also includes formatting according to a
style sheet which can be modified by the user. The first
program into which liblouisutdml has been incorporated is
@command{file2brl}. This program will translate an xml or text file
into an embosser-ready braille file. It is not necessary to know xml,
because MSWord and other word processors can export files in this
format. If the word processor has been used correctly
@command{file2brl} will produce an excellent braille file.

Users who want to generate Braille using @command{file2brl} will be
interested in @ref{Transcribing XML files with file2brl}. Those who
wish to change the output generated by liblouisutdml should read
@ref{Customization Configuring liblouisutdml}. If you encounter a type
of xml file with which liblouisutdml is not familiar you can learn how
to tell it how to process that file by reading @ref{Connecting with
the xml Document}. If you wish to implement a new braille mathematics
code read @ref{Implementing Braille Mathematics Codes}. Finally,
computer programmers who wish to use liblouisutdml in their software can
find the information they need in @ref{Programming with liblouisutdml}.

You will also find it advantageous to be acquainted with the companion
library liblouis, which is a braille translator and back-translator
(@pxref{Top, , Overview, liblouis, Liblouis User's and Programmer's
Manual}).

@node Transcribing Documents
@chapter Transcribing Documents

@menu
* Transcribing XML files with file2brl::
* Transcribing Text Documents::
* Transcribing Poorly Formatted Documents::
* Transcribing html Documents::
@end menu

@node Transcribing XML files with file2brl
@section Transcribing XML files with file2brl
@pindex file2brl

At the moment, actual transcription with liblouisutdml is done with the
command-line (or console) program @command{file2brl}. The line to type
is:

@example
file2brl [OPTIONS] [-f config-file] [infile] [outfile]
@end example

The brackets indicate that something is optional. You will see that
nothing is required except the program name itself, @command{file2brl}.
The various optional parts control how the program will behave, as
follows:

@table @option

@item -h
@itemx --help
This option causes @command{file2brl} to print a help message
describing usage and exit.

@item -v
@itemx --version
This option causes @command{file2brl} to display the version
information and exit.

@item -f configfile
@itemx --config-file configfile
This specifies the configuration file which tells @command{file2brl}
how to do the transcription. (It may be a list of file names separated
by commas.) This file specifies such things as the number of cells per
line, the number of lines per page, The translation tables to be used,
how paragraphs and headings are to be formatted, etc. If this part of
the command line is omitted, @command{file2brl} assumes that the
configuration file is named @file{preferences.cfg}. If the
configuration file name contains a pathname @command{file2brl} will
consider this as a path on which to look for files that it needs
(@pxref{Files and Paths}). If no pathname is given the standard paths
are searched and finally the current directory. To make
@command{file2brl} search the current directory first, precede the
file name with @code{./}.

@item -b
@itemx --backward
back-translate. The input file must be a braille file, such as
@file{.brf}. The output file is a back-translation of this file. It
may be in either plain-text or xhtml (html), according to the setting
of @code{backFormat} in the @code{outputFormat} section of the
configuration file. Html files will contain page numbers and emphasis.
To get good html, the liblouis table must have the entry @samp{space
\e 1b} so that it will pass through escape characters. The
@file{html.sem} file must also contain the line @samp{pagenum
pagenum}. Text output files simply have a blank line between
paragraphs. Encoding of text files is controlled by the
@code{outputEncoding} setting. Html files are always in UTF-8.

@item -r
@itemx --reformat
Reformat. The input file must be a braille file, such as @file{.brf}.
The output is a braille file formatted according to the configuration
file. It is advisable to set backFormat to html, since this will
preserve print page numbers and emphasis. This option can be useful
for changing the line length and page length of a braille file, for
example, from 40 to 32 cells. It is also an excellent way to check the
accuracy of liblouis tables. The original page numbers at the tops and
bottoms of pages are discarded, and new ones are generated.

@item -T
@item  --text
Consider the document to be a text file, even if it is xml or html.

@item -t
@itemx --html
The document is an h(t)ml file, not xhtml. This option is useful with
files downloaded from the Web in source form. Without it, the program
will first try to parse the file as an xml document, producing lots of
error messages. It will then try the html parser. With this option, it
goes directly to the html parser. See also the @code{formatFor}
configuration (@pxref{formatFor setting}) file setting, which enables
you to format the braille output for viewing in a browser.

@item -p
@itemx --poorly-formatted
Poorly formatted input translation. Infile is any text file such as may
have been obtained by extracting the text in a pdf file. The input
file may also be an xml or html file which is so poorly formatted that
better braille can be obtained by ignoring the formatting.
@command{file2brl} tries to guess paragraph breaks. The output is
generally reasonably formatted, that is, with reasonable paragraph
breaks.

@item -P
@itemx --paragraph-line
Treat each block of text ending in a newline as a paragraph. If there
are two newline characters a blank line will be inserted before the
next paragraph.

@item -Csetting=value
@itemx --config-setting setting=value
This option enables you to specify configuration settings on the
command line instead of changing the configuration file. You can use
as many @option{-C} options as you wish. Any settings can be specified
except those having to do with styles. @xref{Configuration Settings
Index}, for a list of available settings. These must be specified in
configuration files. The settings may be in any order. They override
any settings in @file{liblouisutdml.ini} or in the configuration file used
by @command{file2brl}.

@item -w
@itemx --writeable-path
This option enables you to specify where the log file and other
temporary files will be written.

@item -l
@itemx --log-file
This option will cause @command{file2brl} and liblouisutdml to print
error messages to @file{file2brl.log} instead of stderr. The file will
be in the current directory. This option is particularly useful if
@command{file2brl} is called by a GUI script or Web application.

@item infile
This is the name of the input file containing the material to be
transcribed. The file may be either an xml file or a text file. The
@option{-b}, @option{-r} and @option{-p} options discussed above
provide for other types of files and processing. Typical xml files are
those provided by @uref{www.bookshare.org} or those derived from a
word processor by saving in xml format. If a text file is used,
paragraphs and headings should be separated by blank lines. In such a
file there is no way to distinguish between paragraphs and headings,
so they will all be formatted as paragraphs, as specified by the
configuration file. However, if you want a blank line in the braille
transcription, use two consecutive blank lines in the text file.

@item outfile
This is the name of the output file. It will be transcribed as
specified by the configuration file and the @option{-C} configuration
settings.
The following paragraphs provide more information on both the input
and output files.

@end table

@command{file2brl} is set up so that it can be used in a "pipe". To do
this, omit both infile and outfile. Input is then taken from the
standard input unit.

The first file name encountered (a word not preceded by a minus sign)
is taken to be the input file and the second to be the output file. If
you wish input to be taken from stdin and still want to specify an
output file, use one minus sign (@samp{-}) for the input file.

If only the program name is typed @command{file2brl} assumes that the
configuration file is @file{preferences.cfg}, input is from the
standard input unit, and output is to the standard output unit.

@node Transcribing Text Documents
@section Transcribing Text Documents

See the previous section on using @command{file2brl}. This program
recognizes text files automatically and transcribes them according to
the information in the configuration files. Paragraphs must be
separated with a blank line. If you want a blank line in the output use
two blank lines.

@node Transcribing Poorly Formatted Documents
@section Transcribing Poorly Formatted Documents

@example
file2brl -p infile outfile
@end example

Some text documents, such as those derived from pdf files, and even
some xml and html documents, are so poorly formatted that you can get
better braille by ignoring whatever markup they contain. The
@option{-p} option of @command{file2brl} does this. It ignores xml or
html markup and uses heuristics to find the beginning of paragraphs.
Its choices are usually good. Note that it does not work with rtf
files.

@node Transcribing html Documents
@section Transcribing html Documents

@example
file2brl -t infile outfile
@end example

The @option{-t} option prevents @command{file2brl} from trying to
transcribe infile as an xml document. This will produce a lot of error
messages. @command{file2brl} will then try the html parser. Note that
xhtml documents are actually xml.

@node Customization Configuring liblouisutdml
@chapter Customization: Configuring liblouisutdml

The operation of liblouisutdml is controlled by two types of files:
semantic-action files and configuration files. The former are
discussed in the section Connecting with the xml Document -
Semantic-action Files (@pxref{Connecting with the xml Document,
Connecting with the xml Document - Semantic-Action Files, Connecting
with the xml Document - Semantic-Action Files }). The latter are
discussed in this section. A third type of file, braille translation
tables, is discussed in the liblouis documentation (@pxref{Top, ,
Overview, liblouis, Liblouis User's and Programmer's Manual}).

Another section of the present document which may be of interest is
Implementing Braille Mathematical Codes (@pxref{Implementing Braille
Mathematics Codes}).

Besides files, liblouisutdml can also be controlled by configuration
strings, which are character strings in memory containing configuration
settings separated by end-of-line characters. Such strings can be
generated by the @option{-C} option on the @command{file2brl} command
line, by the @code{configstring} and @code{configtweak} semantic
actions, or by passing a string to the @code{lbu_initialize} function.

The information below applies to @command{file2brl} as much as to
liblouisutdml.

Before discussing configuration files in detail it is worth noting
that the application program has access to the information in the
configuration files by calling the liblouisutdml function
@code{lbu_initialize}. This function returns a pointer to a data
structure containing the configuration information. The calling program
must include the header file @code{louisutdml.h}. You do not need to call
@code{lbu_initialize} unless you need the facilities which it provides.

A configuration file specification may contain more than one file
name, separated by commas. liblouisutdml will process these files in
sequence, merging the information they contain. The first file name
may also contain a path. liblouisutdml will search for the files it
needs first on this path. To make it search first the current
directory precede the first file name with @code{./}. After the path,
if any, has been evaluated, but before reading any of the files,
liblouisutdml reads in a file called @file{liblouisutdml.ini}. This
file can contain any configuration settings, but it usually contains
only the minimum ones for liblouisutdml to operate properly. You may
alter the values in the distribution @file{liblouisutdml.ini}, but you
should not delete any settings. Do not specify
@file{liblouisutdml.ini} as your configuration file. This will lead to
error messages and program termination. If a configuration file read
in later contains a particular setting name, the value specified
simply replaces the one specified in @file{liblouisutdml.ini} or any
previously read configuration file.

Originally, configuration files contained four main sections,
@code{outputFormat}, @code{translation}, @code{xml} and @code{style}.
The section names, except for @code{style} are now optional. In
addition, a configuration file can contain an include entry. This
causes the file named on that line to be read in at the point where
the line occurs. The sections need not follow each other in any
particular order, nor is the order of settings within each section
important. The section names, except for @code{style} are optional. In
this document and in the @file{liblouisutdml.ini} file, where section
and setting names consist of more than one word, the first letter of
each word following the initial one is capitalized. This is merely for
readability. The case of the letters in these names is ignored by the
program. Section and setting names may not contain spaces.

In addition to @file{liblouisutdml.ini} the distribution also contains
a number of configuration files. The most important of these is
@file{preferences.cfg}, which contains all possible settings and a
"default" value for each. You should use this file as a reference.
It is the file read by the @command{file2brl} command-line interface
program if no configuration file is given.

Here, then, is an explanation of each section and setting in the
@file{preferences.cfg} file. When you look at this file you will see
that the section names start at the left margin, while the settings
are indented one tab stop. This is done for readability, it has no
effect on the meaning of the lines. You will also see lines beginning
with a number sign (@samp{#}), which are comments. Blank lines can
also be used anywhere in a configuration file. In general, a section
name is a single word or combination of unspaced words. However, each
style has a section of its own, so the word @samp{style} is followed
by a space then by the name of the style. Setting lines begin with the
name of the setting, followed by at least one space or tab, followed
by the value of the setting. A few settings have two values.

@menu
* outputFormat::
* translation::
* xml::
* style::
@end menu

@node outputFormat
@section outputFormat

This section specifies the format of the output file (or string).

@table @code

@setting{cellsPerLine, 40}
The number of cells in a braille line.

@setting{linesPerPage, 25}
The number of lines on a braille page

@setting{interpoint, no}
Whether or not the output will be used to produce interpoint braille.
This affects the placement of page numbers and may affect other things
in the future. The only two values recognized are @samp{yes} and
@samp{no}.

@setting{lineEnd, \\r\\n}
This specifies the control characters to be placed at the end of each
output line. These characters vary from one intended use of the output
to another. Most embossers require the carriage-return and line-feed
combination specified above. However, a braille display may work best
with just one or the other. Any valid control characters can be
specified.

@setting{pageEnd, \\f}
The control Character to be given at the end of a page. Here it is a
forms-feed character, but it can be something else if deeded.

@setting{fileEnd, ^z}
The control character to be placed at the end of the file, here a
control-z.

@setting{printPages, yes}
Whether or not to show print page numbers if they are given in the xml
input. The two valid values are @samp{yes} and @samp{no}.

@setting{braillePages, yes}
Whether or not to format the output into pages. Here the value is
@samp{yes}, for use with an embosser. However the user of a braille
display may wish to specify @samp{no}, so as not to be bothered with
page numbers and forms feed characters. If no is specified the lines
will still be of the length given in @code{cellsPerLine}, but the
value of @code{linesPerPage} will be ignored.

@setting{paragraphs, yes}
Whether or not to format the output into paragraphs, using appropriate
styles. If @samp{no} is specified, what would be a paragraph is output
simply as one long line. Applications that wish to do their own
formatting may specify @samp{no}.

@setting{beginningPageNumber, 1}
This is the number to be placed on the first Braille page if
@code{braillePages} is yes. This is useful when producing multiple
Braille volumes.

@setting{printPageNumberAt, top}
If print page numbers are given in the xml input file they will be
placed at the top of each braille page in the right-hand corner. If
@code{pageSeparator} is set to @samp{yes}, a page separator line will
also be produced on the Braille page where the print page break
actually occurs. You may also specify @samp{bottom} for this setting.

@setting{braillePageNumberAt, bottom}
The braille page number will be placed in the bottom right-hand corner
of each page. If @code{interpoint yes} has been specified only odd
pages will receive page numbers. You may also specify @samp{top} for
this setting. If print page numbers and Braille page numbers are both
placed at the top or bottom, they are rendered next to each other with
a space in between.

@anchor{continuePages setting}
@setting{continuePages, yes}
Print page numbers can be prefixed with a letter (a, b, c, etc.) on
continued pages. The two valid values are @samp{yes} and @samp{no}.

@anchor{pageSeparator setting}
@setting{pageSeparator, yes}
A page separator line (or page break indicator), a line of unspaced
Braille dots 36, will be placed wherever a print page break occurs. No
page separator lines are placed on the first or last line of a Braille
page, and no page separator lines are shown when the new print page
coincides with a new Braille page.

@setting{pageSeparatorNumber, yes}
Show a page number at the far right margin of a page separator line.
No space is left between the separator line and the first symbol of
the page number.

@setting{ignoreEmptyPages, yes}
An empty page occurs when a @code{pagenum} tag is immediately followed
by another @code{pagenum} tag. By default, empty pages are completely
ignored. If you specify @samp{no} for this setting, a sequence of
@code{pagenum} tags will lead to a @emph{combined} print page number:
the number of the first empty page is combined with that of the page
on which text reappears, e.g. 5-7. If lettered continuation pages are
required (see @code{continuePages}), they carry only the number of the
page on which text reappears.

@anchor{printPageNumberRange setting}
@setting{printPageNumberRange, no}
By default, only the page number of the @emph{first} print page on a
Braille page is shown at the top or bottom. However, if
@code{printPageNumberRange} is set to @samp{yes}, the @emph{range} of
print pages contained in the current Braille page is displayed. If the
first page in this range is a continued print page, it is prefixed
with a letter as usual (see @code{continuePages}).

@setting{mergeUnnumberedPages, yes}
Page breaks without a page number can simply be ignored. This means
that unnumbered print pages will be treated as if they were a part of
the preceding page. You can also specify @samp{no} for this setting.

@setting{pageNumberTopSeparateLine, yes}
Whether or not to provide a separate line for page numbers when they
are placed at the top of a Braille page. The two valid values are
@samp{yes} and @samp{no}. A print page number range (see
@code{printPageNumberRange}) at the top of a page is always displayed
on a separate line.

@setting{pageNumberBottomSeparateLine, yes}
Whether or not to provide a separate line for page numbers when they
are placed at the bottom of a Braille page.

@setting{hyphenate, no}
If @samp{yes} is specified words will be hyphenated at the ends of
lines if a hyphenation table is available. In contracted English
Braille, hyphenation is not generally used, but it can save
considerable space. The hyphenation table is specified as part of the
table list in the @code{literaryTextTable} setting of the translation
section.

@setting{outputEncoding, ascii8}
This specifies that the output is to be in the form of 8-bit ASCII
characters. This is generally used if the output is intended directly
for a braille embosser or display. The other values of encoding are
@samp{UTF8}, @samp{UTF16} and @samp{UTF32}. These are useful if the
application will process the output further, such as for generating
displays of braille dots on a screen.

@setting{inputTextEncoding, ascii8}
This setting is used to specify the encoding of an input text file.
The valid values are @samp{UTF8} and @samp{ascii8}.

@anchor{formatFor setting}
@setting{formatFor, textDevice}
This setting specifies the type of device the output is intended for.
@samp{textDevice} is any device that accepts plain text, including
embossers. You can also specify @samp{browser}. In this case the
output will be formatted for viewing in a browser. If the input file
contains links, they will be preserved and can be used in the normal
way. The text will be translated into braille with the correct line
length. Math and computer material will be translated appropriately.
These files work well in lynx and Internet Explorer, not so well
in
elinks and Firefox (Before Jaws 10).

@setting{backFormat, plain}
This setting specifies the format of back-translated files.
@samp{Plain} specifies plain-text, while @samp{html} specifies xhtml.
The latter is always encoded in UTF-8. Plain-text files can be encoded
in ascii8, UTF-8 or UTF-16. Html is strongly recommended, since it
will preserve print page numbering and emphasis.

@setting{backLineLength, 70}
This setting specifies the length of lines in back-translated files,
whether in plain-text or html. This is mainly for human readability.
Lines may sometimes be somewhat longer.

@anchor{lineFill setting}
@setting{lineFill, '}
This setting defines the fill character that will be used before the
page numbers in the table of contents for example. The default fill
character is an apostrophe (dot 3).

@end table

@node translation
@section translation

This section specifies the liblouis translation tables to be used for
various purposes.

@table @code

@setting{literaryTextTable, en-us-g2.ctb}
The table used for producing literary braille. This may be either
contracted or uncontracted.

@setting{uncontractedTable, en-us-g1.ctb}
The table used for producing uncontracted or Grade One braille. This
setting appears to be superfluous and may be eliminated in the future.

@setting{compbrailleTable, en-us-compbrl.ctb}
The table used for producing large amounts of output in computer
braille, such as computer programs. The computer braille table is
usually combined with one of the two tables above.

@setting{mathtextTable, en-us-mathtext.ctb}
This table specifies how the non-mathematical parts of math books are
to be translated. In many cases it will be the same as
literaryTextTable or uncontractedTable. For books translated with the
Nemeth Code it is different, because this code requires modification
of standard Grade Two.

@setting{MathexpTable, nemeth.ctb}
This is the table used to translate mathematical expressions.

@setting{editTable, nemeth_edit.ctb}
When the output includes both mathematics and text there may be errors
where one type of translation directly follows another. The editTable
removes these errors.

@end table

@node xml
@section xml

This section provides various information for the processing of xml files.

@table @code

@setting{semanticFiles, *\,nemeth.sem}
This setting gives a list of semantic-action files. These files are
read in the sequence given in the list. Here the first member of the
list is an asterisk (@samp{*}). This means that the corresponding file
is to be named by taking the root element of the document and
appending @samp{.sem}. This asterisk member may occur anywhere in the
list.

@setting{xmlheader, <?xml version='1.0' encoding='UTF8' standalone='yes'?>}
This line gives the xml header to be added to strings produced by
programs like @command{Mathtype} that lack one.

@setting{entity, nbsp ^1}
This line defines an entity or substitution in an xml file. It is one
of those that has two values. The first is the thing to be replaced,
and the second is the replacement. As many entity lines as necessary
can be used. The information they contain is added to the information
provided by xmlHeader. In @file{liblouisutdml.ini} this line is commented
out, because specifying it at this point would prevent the user from
specifying his own xmlheader.

@setting{internetAccess, yes}
The computer has an internet connection and liblouisutdml may obtain
information necessary for the processing of this file from the
Internet. If this setting is @samp{no} liblouisutdml will not try to use
the internet. The necessary information may, however, be provided on
the local machine in the form of a "dtd" file.

@setting{newEntries, yes}
liblouisutdml may create a new semantic-action file (beginning with
@file{new_}) for a document with an unknown root element or a file
(beginning with @file{appended_}) containing new entries for an
existing semantic-action file. Both kinds of files are placed on the
current directory. If this setting is @samp{no} liblouisutdml will not
create a file of new entries and if it encounters a document with an
unknown root element it will issue an error message. Setting
newEntries to @samp{no} may be useful if users should not be bothered
with the minutiae of semantic-action files.

@end table

@node style
@section style

The following sections all deal with styles. Each style has its own
section. Style section names are unlike other section names in that they
consist of the word style, followed by a space, followed by a style
name. With some exceptions, styles are not hard-coded. The user may
define any style desired, with any name except @code{document},
@code{para}, @code{heading1}, @code{heading2}, @code{heading3},
@code{heading4}, @code{contentsheader}, @code{contents1},
@code{contents2}, @code{contents3} and @code{contents4}. The first two
are needed for basic formatting. The others are needed for the table of
contents tool. The user must define settings for these styles as for any
others. This is done in @file{liblouisutdml.ini}, which also contains
definitions and settings for many other styles. The user can add styles
at any time in her/his own configuration files.

Styles can be nested. That is, a document may contain a section of one
style, and inside this may be a section of another style. For example,
you might have styles named frontMatter, titlePage, dedication,
contents, and so on. Your document might contain a section of style
frontMatter. Inside this section might be subsections of styles
titlePage, dedication, contents, and so on. Inside the titlePage section
there might be other sections with styles heading1, para, centered, etc.

Your frontMatter style might also define the "persistent" style setting
@code{braillePageNumberFormat roman}. This setting will apply to all the
styles nested within frontMatter, unless they have a setting other than
@samp{normal}, which is the default and means ordinary braille page
numbers. However, the titlePage style might have the setting
@code{braillePageNumberFormat blank}. This will apply to all styles
nested within it. When the titlePage section ends, the frontMatter
setting @samp{roman} will be restored. The
@samp{braillePageNumberFormat} setting is an example of a "persistent"
style setting. Most settings apply only to the style for which they are
declared.


Below are the settings for the predefined style names. The
@samp{document} style contains all possible settings. The others contain
only settings that are different from the defaults.

@subsection style document
@styleindex document

This is a predefined style name. All settings have their default values.
The user must specify any other values. If a "persistent" style setting
is specified, it will apply to the whole document.

@table @code

@setting{linesBefore, 0}

This setting gives the number of blank lines which should be left
before the text to which this style applies. It is set to a non-zero
value for some header styles.

@setting{linesAfter, 0}

The number of blank lines which should be left after the text to which
this style applies.

@setting{leftMargin, 0}

The number of cells by which the left margin of all lines in the text
should be indented. Used for hanging indents, among other things. This
is a "persistent" setting, so by default all nested styles will inherit
the setting.

@setting{rightMargin, 0}

The equivalent of @samp{leftMargin} for the right side of the page.
This is also a persistent setting.

@setting{firstLineIndent, 0}

The number of cells by which the first line is to be indented relative
to leftMargin. firstLineIndent may be negative. If the result is less
than 0 it will be set to 0. This setting is persistent.

@setting{translate, contracted}

This setting is currently inactive. It may be used in the future. This
setting tells how text in this style should be translated. Possible
values are @samp{contracted}, @samp{uncontracted}, @samp{compbrl},
@samp{mathtext} and @samp{mathexpr}.

@setting{skipNumberLines, no}

If this setting is @samp{yes} the top and bottom lines on the page
will be skipped if they contain braille or print page numbers. This is
useful in some of the mathematical and graphical styles.

@setting{format, leftJustified}

The format setting controls how the text in the style will be
formatted. Valid values are @samp{leftJustified},
@samp{rightJustified}, @samp{centered}, @samp{computerCoded},
@samp{alignColumnsLeft}, @samp{alignColumnsRight},
and @samp{contents}. The first three are self-explanatory.
@samp{computerCoded} is used for computer programs and similar material.
The next two are used for tabular material. @samp{alignColumnsLeft}
causes the left ends of columns to be aligned. @samp{alignColumnsRight}
causes the right ends of columns to be aligned. @samp{contents} is used
only in styles specifically intended for tables of contents. In the
case of @samp{leftJustified}, @samp{rightJustified} and @samp{centered},
nested styles inherit this setting by default.

@setting{newPageBefore, no}

If this setting is @samp{yes}, the text will begin on a new page. This
is useful for certain mathematical and graphical styles. Page numbers
are handled properly.

@setting{newPageAfter, no}

If this setting is @samp{yes} any remaining space on the page after
the material covered by this style is handled is left blank, except
for page numbers.

@setting{rightHandPage, no}

if this setting is @samp{yes} and interpoint is yes the material
covered by this style will start on a right-hand page. This may cause
a left-hand page to be left blank except for page numbers. If
interpoint is @samp{no} this setting is equivalent to newPageBefore.

@setting{braillePageNumberFormat, normal}

This setting specifies the format of braille page numbers. @samp{normal}
means ordinary Arabic numbers. @samp{roman} means Roman numbers.
@samp{p} means to precede Arabic numbers with the letter "p" (for
preliminary). Finally, @samp{blank} causes the page number to be blank
(no page numbers). This is a "persistent" style setting.

@setting{dontSplit, no}

If this setting is @samp{yes}, the element is protected from being
split across pages. This means that if a block of text doesn't fit on
the current page, it will be placed at the beginning of the next one.
This setting applies to the whole element, including children, so if
nested styles specify other values for @samp{dontSplit}, these values
will be ignored.

@setting{keepWithNext, no}

If this setting is @samp{yes}, the element covered by this style is
protected from being split across pages, and in addition it is kept
together with the first line of text of the next sibling.

@setting{orphanControl, 0}

With this setting you can control how many lines of text of an
element must be printed at least at the bottom of a braille page.
The default value is @samp{0}. To have an effect, the setting must
have a value of @samp{2} or more.

@end table

@anchor{contentsheader style}
@subsection style contentsheader
@styleindex contentsheader

This style is used to specify where the table of contents should be
placed and its title. The xml tag assigned to it in the semantic action
file should be placed in the document where you want the table of
contents, and it should contain the title of that table between its
starting and ending markers.

@table @code
@setting{linesBefore, 1}
@setting{linesAfter, 1}
@setting{format, centered}
@end table

@subsection style contents1
@styleindex contents1

This style and the other contents styles are used for the table of
contents and correspond to the ten heading levels (@samp{contents5},
@samp{contents6}, @samp{contents7}, @samp{contents8},
@samp{contents9} and @samp{contents10} are not showed here).

@table @code
@setting{firstLineIndent, -2}
@setting{leftMargin, 2}
@setting{format, contents}
@end table

@subsection style contents2
@styleindex contents2

@table @code
@setting{firstLineIndent, -2}
@setting{leftMargin, 4}
@setting{format, contents}
@end table

@subsection style contents3
@styleindex contents3

@table @code
@setting{firstLineIndent, -2}
@setting{leftMargin, 6}
@setting{format, contents}
@end table

@subsection style contents4
@styleindex contents4

@table @code
@setting{firstLineIndent, -2}
@setting{leftMargin, 8}
@setting{format, contents}
@end table

@subsection style heading1
@styleindex heading1

This style is used for main headings, such as chapter titles.

@table @code
@setting{linesBefore, 1}
@setting{center, yes}
@setting{linesAfter, 1}
@end table

@subsection style heading2
@styleindex heading2

The first level of subheadings after the main heading.

@table @code
@setting{linesBefore, 1}
@setting{firstLineIndent, 4}
@end table

@subsection style heading3
@styleindex heading3

The third level of headings.

@table @code

@setting{firstLineIndent, 4}

@end table

@subsection style heading4
@styleindex heading4

The fourth level of headings. There are six more levels:
@samp{heading5}, @samp{heading6}, @samp{heading7},
@samp{heading8}, @samp{heading9} and @samp{heading10}.

@table @code

@setting{firstLineIndent, 4}

@end table

@subsection style para
@styleindex para

Paragraph. This is ordinary body text.

@table @code

@setting{firstLineIndent, 2}

@end table

@subsection style boxline
@styleindex boxline

Typically used to form the top and bottom lines of "boxed" material.
The character must be chosen to produce the desired dot pattern on the
embosser or display in use.

@table @code

@setting{topBoxline, .}

This should be set to the character you want to be used for the boxline
which appears before the content.

@setting{bottomBoxline, .}

This should be set to the character you want to be used for the boxline
which appears after the content.

@end table

@node Connecting with the xml Document
@chapter Connecting with the xml Document - Semantic-Action Files

@menu
* Semantic Actions Overview::
* Semantic Actions in detail::
* Pseudo-actions::
* Using XPath Expressions::
* Using Macros::
@end menu

@node Semantic Actions Overview
@section Overview

When liblouisutdml (or @command{file2brl}) processes an xml document, it
needs to be told how to use the information in that document to
produce a properly translated and formatted braille document. These
instructions are provided by a semantic-action file, called so because
it explains the meaning, or semantics, of the various specifications
in the xml document. To understand how this works, it is necessary to
have a basic knowledge of the organization of an xml document.

An xml document is organized like a book, but with much finer detail.
First there is the title of the whole book. Then there are various
sections, such as author, copyright, table of contents, dedication,
acknowledgments, preface, various chapters, bibliography, index, and so
on. Each chapter may be divided into sections, and these in turn can be
divided into subsections, subsubsections, etc. In a book the parts have
names or titles distinguished by capitalization, type fonts, spacing,
and so forth. In an xml document the names of the parts are enclosed in
angle brackets (@samp{<>}). For example, if liblouisutdml encounters
@code{<html>} at the beginning of a document, it knows it is dealing
with a document that conforms to the standards of the extensible markup
language (xhtml) - at least we hope it does. When you see a book, you
know it's a book. The computer can know only by being told. Something
enclosed in angle brackets is called an "element" (more properly, a
"tag") in xml parlance. (There may be more between the angle brackets
than just the name of the element. More of this later). The first
"element" in a document thus tells liblouisutdml what kind of document it
is dealing with. This element is called the "root element" because the
document is visualized as branching out from it like a tree. Some
examples of root elements are @code{<html>}, @code{<math>},
@code{<book>}, @code{<dtbook>} and @code{<wordDocument>}. Whenever
liblouisutdml encounters a root element that it doesn't know about it
creates a new file called a semantic-action file. The name of this file
is formed by stripping the angle brackets from the root element, putting
@samp{new_} in front of it and adding a period plus the letters
@samp{sem}. For example, @samp{new_myformat.sem}. If you look in a
directory containing semantic-action files you will see names like
@file{html.sem}, @file{dtbook.sem}, @file{math.sem}, and so on. The
"new" semantic-action files must be edited by a person and the prefix
"new" removed to get an ordinary semantic-action file name.

Sometimes it is advantageous to preempt the creation of a
semantic-action file for a new root element. For example, an article
written according to the docbook specification may have the root element
@code{<article>}. However, the specification itself has the root element
@code{<book>}. In this case you can specify the @file{book.sem} file in
the configuration file by writing, in the xml section,:

@example
semanticFiles book.sem
@end example

You will note that this setting uses the plural of "file". This is
because you can actually specify a list of file names separated by
commas. You might want to do this to specify the semantic-action file
for the particular braille mathematical code to be used. For example:

@example
semanticFiles book.sem,ukmaths.sem
@end example

You can use an asterisk @code{*} to specify the semantic-action file
corresponding to the root element of the document anywhere in the list.

As you will see in the next section, different braille style
conventions and different braille mathematical codes may require
different semantic-action files

liblouisutdml records the names of all elements found in the document in
the semantic-action file. The document has a multitude of elements,
which can be thought of as describing the headings of various parts of
the document. One element is used to denote a chapter heading. Another
is used to denote a paragraph, Still another to denote text in bold
type, and so on. In other words, the elements take the place of the
capitalization, changes in type font, spacing, etc. in a book.
However, the computer still does not know what to do when it
encounters an element. The semantic-action file tells it that.

Consider @file{html.sem}. A copy is included as part of this
documentation with the name @file{example_html.sem} (@pxref{Example
files}). It may differ from the file that liblouisutdml is currently
using. You will see that it begins with some lines about copyrights.
Each line begins with a number sign (@samp{#}). This indicates that it
is a "comment", intended for the human reader and the computer should
ignore it. Then there is a blank line. Finally, there are two other
comments explaining that the file must be edited to get proper output.
This is because a human being must tell the computer what to do with
each element. The semantic files for common types of documents have
already been edited, so you generally don't have to worry about this.
But if you encounter a new type of document or wish to specify special
handling for styles or mathematics you may have to edit the
semantic-action file or send it to the maintainer for editing. In any
case the rest of this section is essential for understanding how
liblouisutdml handles documents and for making changes if the way it
does so is not correct.

After another blank line you will see a table consisting of two, and
sometimes three, columns. The first column contains a word which tells
the computer to do something. For example, the first entry in the
table is: @samp{include nemeth.sem}. This tells liblouisutdml to include
the information in the @file{nemeth.sem} file when it is deciphering
an html (actually xhtml) document (it may be preferable to use the
semanticFiles setting in the configuration file rather than an
include).

The second row of the table is:

@example
no hr
@end example

@samp{hr} is an element with the angle brackets removed. It means
nothing in itself. However, the first column contains the word
@samp{no}. This tells liblouisutdml "no do", that is, do nothing. This is
not strictly true, since liblouisutdml will sometimes insert a blank space
so that words in text do not run together.

After a few more lines with @samp{no} in the first column, we see one
that says:

@example
softreturn br
@end example

This means that when the element @code{<br>} is encountered,
liblouisutdml is to do a soft return, that is, start a new line without
starting a new paragraph.

The next line says:

@example
heading1 h1
@end example

This tells liblouisutdml that when it encounters the element @code{<h1>}
it is to format the text which follows as a first-level braille
heading, that is, the text will be centered and preceded and followed
by blank lines. (You can change this by changing the definition of the
heading1 style).

The next line says:

@example
italicx em
@end example

This tells liblouisutdml that when it encounters the element @code{<em>}
it is to enclose the text which follows in braille italic indicators.
The @samp{x} at the end of the semantic action name is there to
prevent conflicts with names elsewhere in the software. Just where the
italic indicators will be placed is controlled by the liblouis
translation table in use.

The next line says:

@example
skip style
@end example

This tells liblouis to simply skip ahead until it encounters the
element @code{</style>}. Nothing in between will have any effect on
the braille output. Note the slash (@samp{/}) before the @samp{style}.
This means the end of whatever the @code{<style>} element was
referring to. Actually, it was referring to specifications of how
things should be printed. If liblouisutdml had not been told to skip
these specifications, the braille output would have contained a lot of
gobledygook.

The next line says:

@example
italicx strong
@end example

This tells liblouis to also use the italic braille indicators for the
text between the @code{<strong>} and @code{</strong>} elements.

After a few more lines with @samp{no} in the first column we come to
the line:

@example
document html
@end example

This tells liblouisutdml that everything between @code{<html>} and
@code{</html>} is an entire document. @code{<html>} was the root
element of this document, so this is logical.

After another @samp{no} line we come to:

@example
para p
@end example

liblouisutdml will consider everything between @code{<p>} and
@code{</p>} to be a normal body text paragraph.

The next line is:

@example
heading1 title
@end example

this causes the title of the document to also be treated as a braille
level 1 heading.

Next we have the line:

@example
list li
@end example

The xhtml @code{<li>} and @code{</li>} pair of elements is used to
enclose an item in a list. liblouisutdml will format this with its own
list style. That is, the first line will begin at the left margin and
subsequent lines will be indented two cells.

Next we have:

@example
table table
@end example

You will note that the names of actions and elements are often
identical. This is because they are both mnemonic. In any case, this
line tells liblouisutdml to format the table contained in the xhtml
document according to the table formatting rules it has been given for
braille output.

Next we have the line:

@example
heading2 h2
@end example

This means that the text between @code{<h2>} and @code{</h2>} is to be
formatted according to the Liblouisutdml style heading2. A blank line
will be left before the heading and the first line will be indented
four spaces.

After a few more lines we come to:

@example
no table,cellpadding
@end example

Note the comma in the second column. This divides the column into two
subcolumns. The first is the table element name. The second is called
an "attribute" in xml. It gives further instructions about the
material enclosed between the starting and ending "tags" of the
element (@code{<table>} and @code{</table>}. Full information requires
three subcolumns. The third is called the value and gives the actual
information. The attribute is merely the name of the information.

Much further down we find:

@example
no table,border,0
@end example

Here the element is table, the attribute is border and the value is 0.
If liblouisutdml were to interpret this, it would mean that the table
was to have a border of 0 width. It is not told to do so because
tables in braille do not have borders.

Now let's look at the file which is included at the beginning of the
@file{html.sem} file. This is @file{nemeth.sem}. As with
@file{html.sem}, a copy is included in the appendix
(@pxref{Example files}), but it is not necessarily the one that
liblouisutdml is currently using. It illustrates several more things
about how liblouisutdml uses semantic-action files.

The first thing you will notice is that for quite a few lines the
first and second columns are identical. This is because the MathML
element and attribute names are part of a standard, and it was
simplest to use the element names for the semantic actions as well. Most
of these actions do not do anything and could be replaced with the
@code{generic} semantic action. They are retained for backward
compatibility.

The first line of real interest is:

@example
math math
@end example

Every mathematical expression begins with the element @code{<math>}
(which may have attributes and values), and ends with @code{</math>}.
This is therefore the root element of a mathematical expression.
However, mathematical expressions are usually part of a document, so
it is not given the semantic action document. The math semantic action
causes liblouisutdml to carry out special interpretation actions. These
will become clearer as we continue to look at the @file{nemeth.sem}
file. You will note that this line has three columns. The meaning of
the third column is discussed below.

After another uninteresting line we come to two that illustrate
several more facts about semantic-action files:

@example
mfrac mfrac ^?,/,^#
mfrac mfrac,linethickness,0 ^(,^;%,^)
@end example

Like the math entry above, the first line has three columns. While the
first two columns must always be present, the third column is
optional. Here, it is also divided into subcolumns by commas. The
element @code{<mfrac>} indicates a fraction. A fraction has two parts,
a numerator and a denominator. In xml, we call these parts children of
@code{<mfrac>}. They may be represented in various ways, which need
not concern us here. What is of real importance is that the third
column tells liblouisutdml to put the characters @samp{~?} before the
numerator, @samp{/} between the numerator and denominator, and
@samp{~#} after the denominator. Later on, liblouis will translate
these characters into the proper representation of a fraction in the
Nemeth Code of Braille Mathematics. (For other mathematical codes,
@pxref{Implementing Braille Mathematics Codes}).

The second line is of even greater interest. The first column is again
@samp{mfrac}, but this line is for binomial coefficient. The second
column contains three subcolumns, an element name, an attribute name
and an attribute value. The attribute linethickness specifies the
thickness of the line separating the numerator and denominator. Here
it is 0, so there is no line. This is how the binomial coefficient is
represented in print. The third column tells how to represent it in
braille. liblouisutdml will supply @samp{~(}, upper number, @samp{~%},
lower number, @samp{~)} to liblouis, which will then produce the
proper braille representation for the binomial coefficient.

Returning to the line for the math element, we see that the third
column begins with a backslash followed by an asterisk. The backslash
is an escape character which gives a special meaning to the character
which follows it. Here the asterisk means that what follows is to be
placed at the very end of the mathematical expression, no matter how
complex it is.

For further discussion of how the third column is used
@pxref{Implementing Braille Mathematics Codes}. The third column is
not limited to mathematics. It can be used to add characters to
anything enclosed by an xml tag.

@node Semantic Actions in detail
@section Semantic Actions in detail

Here is a complete list of the semantic actions which liblouisutdml
recognizes. Some of them are also the names of styles. These are listed
in the first table. For a discussion of these, @pxref{Customization
Configuring liblouisutdml}.

Generally the format of a semantic action is:

@example
semanticAction elementSpecifier optionalArguments
@end example

@code{elementSpecifier} is the second-column value, which may be an
element name, an element-attribute pair or an element-attribute-value
triplet, separated by commas. This specifies where a semantic action
is to be applied. If it is solely an element then the action is
applied if this element is encountered. If it is an element-attribute
pair then the action is applied if the given element also has the
specified attribute. In the last case with an element-attribute-value
triplet the action is only applied if the element has the specified
attribute and the value of this attribute is equal to the specified
value.

@table @code

@semanticAction{contents1, elementSpecifier}

Note that the @code{contents1}, etc. semantic actions are never
assigned an
actual @code{elementSpecifier}. There used internally by the table of
contents generator. They should be assigned style settings, however.

@semanticAction{contents2, elementSpecifier}

@semanticAction{contents3, elementSpecifier}

@semanticAction{contents4, elementSpecifier}

@semanticAction{contentsheader, elementSpecifier}

This semantic action must be assigned an element specifier if used.
See the discussion of it in @ref{style}.

@semanticAction{document, elementSpecifier}

@semanticAction{heading1, elementSpecifier}

@semanticAction{heading2, elementSpecifier}

@semanticAction{heading3, elementSpecifier}

@semanticAction{heading4, elementSpecifier}

@semanticAction{para, elementSpecifier}

@end table

The following table explains each of the non-style semantic actions. In
general, each one performs a particular function. If a third column is
given, the subcolumns will be inserted in order before each branch of
any subtree starting from @code{elementSpecifier}.


@table @code

@semanticAction{blankline, elementSpecifier}

This semantic action causes a blank line to appear in the output
wherever it may occur. It is useful for fine formatting independent of
styles. @code{elementSpecifier} should be an empty element, that is, of
the form @code{<elementSpecifier/>}. If it is not, any content which it
may contain will be ignored.

@semanticAction{boldx, elementSpecifier}

Enclose the text which follows in braille bold indicators. The @samp{x}
at the end of the semantic action name is there to prevent conflicts
with names elsewhere in the software. Just where the bold indicators
will be placed is controlled by the liblouis translation table in use.

@semanticAction{chemistry, elementSpecifier}

When a module to handle chemical notation is ready, this semantic action
will invoke it. The processing will be like that produced by the
semantic action @code{math}.

@semanticAction{changetable, elementSpecifier}

This semantic action is used to change the active translation table. It
can switch to a table for another language or to a table for computer
braille in a mathematical expression, etc. @code{elementSpecifier} is in
the form @code{element,attribute}. The document contains something like:

@example
<span lang="en-us-g1.ctb">
This is uncontracted.
</span>
@end example

The specified table remains in effect from
@code{<element attribute="tablename">} until @code{</element>}, no
matter what is
between the two. The previous table is then restored.

@semanticAction{compbrl, elementSpecifier}

The material between @code{elementSpecifier} and
@code{/elementSpecifier} is translated as computer braille, if the
liblouis table in use provides for it. Beginning and ending computer
braille indicators are inserted if they are in the table.

@semanticAction{configfile, elementSpecifier filename}

The @code{configfile}, @code{configstring} and @code{configtweak}
semantic actions enable the configuration of liblouisutdml to be changed
according to the contents of the document being transcribed.
@code{configfile} and @code{configstring} take effect during the
document analysis phase performed by @file{examine_document.c}.
@code{configtweak} is effective during the transcription phase,
performed by @file{transcribe_document.c} and the functions called in
this module.

@code{elementSpecifier} is the usual second-column value, which may be
an element name, an element-attribute pair or an
element-attribute-value triplet, separated by commas. @code{filename}
must be on one of the paths set in the @file{paths.c} module. The file
may contain any configuration settings except those in the xml
section. These would be ineffective, since the document has already
been parsed.

@semanticAction{configstring, elementSpecifier setting1=value1;setting2=value2;...}

Note that the @code{setting=value} pairs are separated by semicolons.
Because the string may be longer than a screen line, you can use a
backslash @samp{\} followed immediately by a line ending @samp{\n}, to
continue to another line. The string must not contain any blanks. Any
setting which can be specified in a file read with configfile can be
specified in @code{configstring}.

@semanticAction{configtweak, elementSpecifier settings}

@code{configtweak} is identical to @code{configstring} except that it
is called in the transcription phase. It can be used for
things like changing translation tables. For example:

@example
configtweak elementSpecifier literaryTextTable=fooTable;\
mathExprTable=barTable
@end example

@code{configtweak} is not a generalization of @code{changetable}. The
latter changes the active table and applies to a subtree.
@code{configtweak} remains in effect until changed by another
@code{configtweak}.

@semanticAction{contracted, elementSpecifier}

@semanticAction{footer, elementSpecifier}

This semantic action is used to specify a footer which will be placed at
the bottom of each page.

@example
<elementSpecifier>This is a footer</elementSpecifier>
@end example

@semanticAction{generic, elementSpecifier}

This is a general-purpose semantic action. If the third column is blank
it does absolutely nothing. If the third column contains a string or
subcolumns its contents are placed in the output according to the usual
rules. That is, the first subcolumn is placed before the first branch of
the subtree rooted at this node, the second is placed before the second
branch, etc. If the last (or only) subcolumn begins with @code{\*} it is
placed after the last branch, no matter how many branches there may be.

@semanticAction{graphic, elementSpecifier}

When a module which can handle SVG graphics is ready this semantic
action will invoke it.

@semanticAction{htmllink, elementSpecifier}

This semantic action is used when the configuration file specifies
@code{formatFor browser}. It sets up a link which the browser can
follow.

@semanticAction{htmltarget, elementSpecifier}

This semantic action establishes a target for a link in the same file
when @code{formatFor browser} is specified in the configuration file.

@semanticAction{italicx, elementSpecifier}

Enclose the text which follows in braille italic indicators.
The @samp{x} at the end of the semantic action name is there to
prevent conflicts with names elsewhere in the software. Just where the
italic indicators will be placed is controlled by the liblouis
translation table in use.

@semanticAction{linespacing, elementSpecifier digit}

This semantic action specifies the number of blank lines to be left
between adjacent lines in the output. For example if the third column is
@samp{1}, lines will be double-spaced. @samp{0} specifies normal
spacing. The number cannot be greater than @samp{3}. @code{linespacing}
remains in effect until another @code{linespacing} is encountered. It
should be assigned to an empty element.

@semanticAction{maction, elementSpecifier}

In the early stages of development I thought that a separate piece of
code might be needed for each of the MathML element tags. It turned out,
as noted elsewhere, that most of them could have been handled with the
@code{generic} semantic action. They are retained for backward
compatibility. Therefore, unless this is not the case or additional
information is needed, they are simlly listed.

@semanticAction{maligngroup, elementSpecifier}

@semanticAction{malignmark, elementSpecifier}

@semanticAction{math, elementSpecifier}

Every mathematical expression begins with the element
@code{<elementSpecifier>} @code{math} (which may have attributes and
values), and ends with @code{</elementSpecifier>} (@code{/math}). This
is therefore the root element of a mathematical expression. However,
mathematical expressions are usually part of a document, so it is not
given the semantic action document. liblouisutdml will, however, handle
files and strings which consist of nothing but a mathematical expression
properly. The @code{math} semantic action causes liblouisutdml to carry
out special interpretation actions.

@semanticAction{menclose, elementSpecifier}

@semanticAction{merror, elementSpecifier}

@semanticAction{mfenced, elementSpecifier}

@semanticAction{mfrac, elementSpecifier}

@semanticAction{mglyph, elementSpecifier}

@semanticAction{mi, elementSpecifier}

@semanticAction{mlabeledtr, elementSpecifier}

@semanticAction{mmultiscripts, elementSpecifier}

@semanticAction{mn, elementSpecifier}

@semanticAction{mo, elementSpecifier}

@semanticAction{mover, elementSpecifier}

@semanticAction{mpadded, elementSpecifier}

@semanticAction{mphantom, elementSpecifier}

@semanticAction{mprescripts, elementSpecifier}

@semanticAction{mroot, elementSpecifier}

The MathML element @code{mroot} is actually given the semantic action
@code{reverse}.

@semanticAction{mrow, elementSpecifier}

This can be important in implementing Math codes because it is often
used to create visual groups, which may be significant for braille.

@semanticAction{ms, elementSpecifier}

@semanticAction{mspace, elementSpecifier}

This element and its attributes can be helpful for determining spacing.

@semanticAction{msqrt, elementSpecifier}

@semanticAction{mstyle, elementSpecifier}

This MathML element should usually have the semantic action @code{skip}.

@semanticAction{msub, elementSpecifier}

@semanticAction{msubsup, elementSpecifier}

@semanticAction{msup, elementSpecifier}

@semanticAction{mtable, elementSpecifier}

The file @file{liblouisutdml.ini} defines the style @code{matrix}. The
semantic-action files for math codes declare @code{mtable} to be
@code{matrix}. Depending on the attributes of this element, it can be
set to other styles, such as long division. The @code{matrix} style
contains the setting @code{format alignColumnsLeft}.

@semanticAction{mtd, elementSpecifier}

This element specifies a column in a mathematical table. For the style
@code{matrix} the third column of the entry in a semantic-action file
must contain @code{\*|ec}. This indicates the end of the column. Other
specifications using the liblouis @code{exactdots} feature may also be
necessary.

@semanticAction{mtext, elementSpecifier}

@semanticAction{mtr, elementSpecifier}

This element specifies a row in a mathematical table. The entry in a
semantic-action file must contain @code{\*\er} in the third column for
the @code{matrix} style, indicating the end of the row. Other things may
also need to be specified using the liblouis @code{exactdots} feature.
Note that rows are not declared as styles nested inside the
@code{matrix} style. This is because the table must be considered as a
whole.

@semanticAction{munder, elementSpecifier}

@semanticAction{munderover, elementSpecifier}

@semanticAction{music, elementSpecifier}

When a module which can interpret MusicML and produce braille music
notation is ready this semantic action will invoke it.

@semanticAction{newpage, elementSpecifier}

This semantic action causes the rest of the current page to be left
blank except for page numbers and footers. A new page is then begun.
Like @code{blankline}, it is useful for fine formatting independent of
styles.

@semanticAction{no, elementSpecifier}

Originally, this semantic action was intended to be the default and to
do nothing when an @code{elementSpecifier} had no meaning for braille
translation. Later it was found that it should insert a blank space if
parts of the text would run together, so this is now its action.

@semanticAction{none, elementSpecifier}

This is a MathML element.

@semanticAction{notranslate, elementSpecifier}

Output the text between the start and end tags exactly as written. It
will, however, be formatted with appropriate line breaks, page numbers
etc. If you want to make sure that things appear on the same line
separate them with an unbreakable space, @samp{&#160;} or
@samp{&#xa0;}.

@semanticAction{pagenum, elementSpecifier}

The text between @code{<elementSpecifier>} and @code{</elementSpecifier>}
is taken to be a print page number. If it does not begin with a digit
the string @code{\_} is placed before it. It is then passed to liblouis
for translation according to the active table. This table must contain
an entry for translating @code{\_} into a letter sign or whatever else
is wanted. This string is inserted so that roman page numbers will be
handled properly. Unnumbered page breaks are indicated with an empty
pagenum tag: @code{<elementSpecifier></elementSpecifier>}.

@semanticAction{reverse, elementSpecifier}

The branches of the subtree rooted at this node are reversed in order.
This is used in handling roots, where the arguments in the translation
are in reverse order to those in MathML. the MathML element @code{mroot}
is declared with this semantic action

@semanticAction{righthandpage, elementSpecifier}

If @code{interpoint yes} has been specified in the configuration file,
and the current page is a right-hand one, the rest of the page is
skipped except for footer and page number. the following left-hand page
is similarly skipped. Otherwise, the action is the same as
@code{newpage}.

@semanticAction{runninghead, elementSpecifier}

This semantic action is used to specify a running header, such as a book
title, to be placed at the top of each page. If the header is too long
it will be truncated.

@example
<elementSpecifier>liblouisutdml Manual</elementSpecifier>
@end example

@semanticAction{semantics, elementSpecifier}

This is a MathML action which seems to be irrelevant to braille
translation.

@semanticAction{skip, elementSpecifier}

Skip ahead until encountering the element @code{</elementSpecifier>}.
Nothing in between will have any effect on the braille output.

@semanticAction{softreturn, elementSpecifier}
Do a soft return, that is, start a new line without starting a new
paragraph. @code{elementSpecifier} should be empty, for example,
@code{<br/>}.

@semanticAction{uncontracted, elementSpecifier}

This semantic action seems superfluous and may be eliminated in the
future.

@semanticAction{underlinex, elementSpecifier}

Enclose the text which follows in braille underline indicators.

@end table

@node Pseudo-actions
@section Pseudo-actions

These actions affect the processing of semantic-action files. They are
not connected with any tag in the document. They are executed when they
are encountered in the processing of semantic-action files.

@menu
* include::
* newentries::
* namespaces::
@end menu

@node include
@subsection include

@example
include filename
@end example

filename must be the name of a semantic action file. The file is
compiled as though it were part of the file containing the
@code{include} entry. Included files may include other files.

@node newentries
@subsection newentries

@example
newentries no
@end example

The second column in this entry must contain @samp{no}. Any new entries
found in the document will be ignored. No @samp{appended_} file will be
produced. This affects only documents processed with this
semantic-action file. The configuration setting @code{newEntries}
affects all documents.

@node namespaces
@subsection namespaces
@cindex Namespaces

@example
namespaces dtb=http://www.daisy.org/z3986/2005/dtbook/
@end example

This pseudo-action is used to declare namespaces used in XPath
expressions. (@pxref{Using XPath Expressions}). The format is
@samp{namespaces prefix1=url1,prefix2=url2,...}. The list of
namespaces may not contain blanks.

@node Using XPath Expressions
@section Using XPath Expressions
@cindex XPath Expressions

The second column of a semantic action may contain an XPath expression
for matching nodes. When an XPath expression is to be used the second
column should be of the format: @samp{&xpath(<expression>)} where
@samp{<expression>} is the XPath expression to match nodes.

When constructing your XPath expressions you may wish to consider the
following facts:

@itemize @bullet
@item
The XPath expression may contain brackets but they must match

@item
liblouisutdml performs XPath matching from the document root, so you
most likely want all XPath expressions to begin with double slash
(@samp{//}).

@item
If the source document uses namespaces for the nodes you wish to match
then you must define the namespace in the semantic action file
(@pxref{namespaces}) and then prefix the node with the namespace (e.g.
for a namespace with alias @samp{xhtml} and node with name @samp{p},
this would be @samp{xhtml:p})

@item
You should be careful not to create XPath expressions which give
overlapping node set results. When liblouisutdml finds a match for a
node it assigns the semantic action to that node and this will not be
changed subsequently. Note that this is unlike XSLT, where for each
matcher a priority is calculated from the XPath expression while in
liblouisutdml it is unpredictable which rule will win.

@item
XPath expressions take precedence over ordinary semantic-file entries.

@end itemize

As with other types of semantic actions, you may define arguments in
the third column of a semantic action using XPath expressions.

@example
para &xpath(//h4)
@end example

This example causes any element with the name @samp{h4} to be given the
semantic action @code{para}, no matter what other assignments may be
made to it.

@node Using Macros
@section Using Macros
@cindex Macros

A semantic-action file permits only one action or style to be
mentioned in the first column. Macros get around this limitation. They
define a style and a series of semantic actions. A macro name can also
be in the first column.

Macros somewhat resemble styles. They are defined in a configuration
file and used in a semantic-action file. In a configuration file the
definition is of the form

@example
macro macroName macroBody
@end example

In a semantic-action file they are invoked as follows:

@example
macroName element[,attribute[,value]] [parameters]
@end example

Here is an example of a macro definition.

@example
macro useSpanish para,configtweak(literaryTextTable=es-Es-g2.ctb)
@end example

In a semantic-action file it might be used as follows.

@example
useSpanish p,lang,ES
@end example

The meanings of the various parts of a macro are as follows:

@table @code

@item macroName

is a string of alphanumeric characters, of which the first must be a
letter.

@item macroBody

is a series of items separated by commas. It may not contain
whitespace. If it is too long to fit on one line it may be continued
by using a backslash (@samp{\}) followed by enter. It should not be
more than 500 characters in length. Each item is one of the following:

@table @asis

@item A style name

Only one style can be specified in a macro. This is due to the way in
which styles are handled.

@item A semantic action, optionally with parameters

The parameters are enclosed in parentheses. They consist of whatever
is legal in the third column for the particular semantic action. If
the parentheses are empty, that is, simply @samp{()} the contents of
the third column of the macro invocation itself are used as the
parameters.

@item @samp{pause}

This is used after a style name so that text belonging to that style
can be processed. Semantic actions can be specified between the style
name and the word @samp{pause}.

@item @samp{endstyle}

This causes the style to be terminated and the processing of any text
which may have been entered into it to be completed. Semantic actions
may be specified after the word @samp{endstyle}.

@end table

If a style has been specified and neither @samp{pause} nor
@samp{endstyle} has been used the style is terminated when the end of
the macro has been reached, and the processing of text is completed.
(When the end_macro function is called by the program.)

@end table

@node Special Features
@chapter Special Features

@menu
* Table of contents::
* Back-translation::
* Reformatting::
* Interlining::
* Browser-Friendly Output::
* CDATA Sections::
* End notes::
@end menu

@node Table of contents
@section Table of contents

A table of contents is produced for an xml file if the file contains a
tag which has been defined with the @semanticref{contentsheader} and
also tags for the @code{heading1}, @code{heading2}, @code{heading3} or
@code{heading4} semantic actions (@pxref{heading1
semantic,heading1,@code{heading1}}). The table of contents will
contain print and braille page numbers if these features have been
enabled. A sequence of fill characters will be inserted before the
page numbers, so that the latter are at the right margin. The fill
character can be specified in a configuration file with the
@settingref{lineFill}. The default fill character is an apostrophe
(dot 3).

Five new styles have been defined for the table of contents. The first
is the @code{contentsheader} style (@pxref{contentsheader style}), which
is used to specify where the table of contents should be placed and the
title that should be given to it. In the latter respect it is much like
a heading style. The others correspond to the four heading levels and
are @code{contents1}, @code{contents2}, @code{contents3} and
@code{contents4}. These styles are chosen as appropriate while the table
of contents is being made. Do not declare them in a semantic-action
file. See the @file{liblouisutdml.ini} file for the current default
definitions of all these styles.

The table of contents will be placed where the xml tag is that you
declared in the @semanticref{contentsheader}. Its title will be whatever
is inside that tag, formatted according to the definition of the
@code{contentsheader} style. It begins on a new page. After it is
completed the braille page number is reset to
@code{beginningBraillePageNumber} and another new page is started. This
means that the xml tag with the @code{contentsheader} semantic action
should occur at the end of the information which you want to be at the
head of the output, such as a title page, dedication, etc.

It is not necessary that an xml file contain a tag with the
@code{contentsheader} semantic action. If the file contains headers
you can obtain a table of contents by specifying @code{contents yes}
in a configuration file or @option{-Ccontents=yes} on the command line
of @command{file2brl}. In this case, the table of contents will appear
at the beginning of the output. Pages will be numbered beginning with
1. When the table of contents is complete, the material in the file
will start on a new page and the page number will be the value given
in @code{beginningBraillePageNumber}.

The @code{contents1}, etc. styles all have the @code{format contents}
setting. This is a variant of the @code{leftJustified} format. It has
been necessary to change the way @code{firstLineIndent} is handled to
accommodate multilevel lists. Up till now, if @code{firstLineIndent}
was negative, the first line would start at the real left margin,
regardless of the value of @code{leftMargin}. Now the value of
@code{firstLineIndent} is simply added to @code{leftMargin}. This
means that if it is negative it is really subtracted. For example, if
@code{leftMargin} is 4 and @code{firstLineIndent} is -2 the first line
will start in cell 2. If the result of adding these two values is
negative it is set to 0.

@node Back-translation
@section Back-translation

@example
file2brl -b infile outfile
@end example

infile must be a braille file. It can have either upper-case or
lower-case letters, etc. outfile will contain the back-translation
according to the configuration specifications. It can be in two
formats according to the value of @code{backFormat}. @samp{ascii}
produces plain text output. The lines will generally correspond to the
lines in the original braille file. @samp{html} produces a file in
xhtml format. This is recommended, since it preserves print page
numbers, if present and some of the formatting of the original. It can
also be loaded into a browser or word processor, which will format it
for good readability. Note that for html format to work your liblouis
table must contain the following line:

@example
space \x001b 1b escape character
@end example

To perform the back-translation operation, @command{file2brl} uses the
liblouisutdml function @code{lbu_backTranslateFile}.

@node Reformatting
@section Reformatting

@example
file2brl -r infile outfile
@end example

As in the previous section, infile must be a braille file. It is
back-translated and then forward-translated to produce a braille file in
outfile which conforms to configuration specifications. It is useful for
changing the line length and page length of a braille file. New braille
page numbers will be generated if @code{braillePages yes} is specified.
If @code{backFormat html} has been specified, print page numbers will be
reproduced in the appropriate places. Some formatting may be lost.

@node Interlining
@section Interlining

Interlining means printing the original text between the lines of
translated braille. It requires special embossers or special methods.
The present way in which liblouisutdml produces interlining relies on
back-translation. However, it is inadequate for mathematics and depends
too much on the quality of the liblouis tables. It is scheduled to be
replaced, so you should not use it.

@node Browser-Friendly Output
@section Browser-Friendly Output

@example
file2brl infile outfile -CformatFor=browser
@end example

infile can be any of the file types accepted by @command{file2brl} (xml,
html or text). If it contains html links or targets they will be
formatted so that a browser can use them. This may be useful if a file
contains internal links to different sections, such as its own table of
contents. Text will be translated and formatted according to
configuration specifications. If the file contains mathematics expressed
as MathML it will be translated according to the mathematics code
specified by the configuration. outfile should have the extension
@samp{.html}. It will actually be xhtml. The @code{-CformatFor=browser}
part of the above example specifies a configuration setting, which, of
course, can also be specified in a configuration file.

@node CDATA Sections
@section @code{CDATA} Sections

A @code{cdata} section may be given the semantic actions @code{skip},
@code{no} or @code{code}. In the first case, the data in the
@code{cdata} section is ignored. In the second case, it is inserted into
the output with no translation. In the third case it is translated into
computer braille and inserted into the output. Any other semantic action
has the same effect as @code{no}.

@node End notes
@section End notes

An endnote is defined as the link between a reference character in the
body of the text and a description at the end of the output document.

@menu
* Use of Endnotes::
* Output::
* Configuration::
* Styles::
* Semantic Actions::
* Example::
@end menu

@node Use of Endnotes
@subsection Use of Endnotes

The position of the reference character in the body of the text is
defined by the @semanticref{noteref}, which is then linked to a
@semanticref{note} (which can appear anywhere within the input file)
with the same id. The content of @code{note} will appear at the end of
the output document, along with its corresponding reference character
and the page and line numbers of where the reference character appears
in the text.

A heading for the first endnote page can be set using the
@semanticref{notesheader}, and a small note can also be placed after
this heading, but before the endnotes, by using the
@semanticref{notesdescription}.

The endnote page created will follow any formatting (page numbers,
headers, footers) from the last page in the document.

@node Output
@subsection Output

Let's look at an example. The following text in an input file

@example
some text <mynoteref id="1">1</mynoteref> some text
...
<mynote id="1">Endnote Description</mynote>
@end example

will produce a reference to the end note in the output as follows
(with usual representation of numbers):

@example
some text 99#a some text
@end example

The @samp{99} in ascii is used as the indicator for an endnote
reference. And it will also produce an entry on the end notes page as
follows:

@example
#a p#g#b Endnote Description
@end example

with the usual representation of numbers and, in this example, the
reference to the note, i.e. the reference character appearing on the
2nd line of the 7th page.

@node Configuration
@subsection Configuration

@table @code
@setting{endnotes,yes}

Choose whether to use endnotes or not. Choosing @samp{no} will ignore
anything enclosed by all the semantic actions @ref{Semantic Actions}.

@end table

@node Styles
@subsection Styles

The semantic actions @code{note}, @code{notesdescription}, and
@code{notesheader} have corresponding styles.

@table @code

@item style note

Each endnote on the endnote page will use this style

@item style notesheader

The style used by the title on the endnote page

@item style notesdescription

The style used by the note just after the title on the endnote page

@end table

The @semanticref{noteref} will inherit its style.

@node Semantic Actions
@subsection Semantic Actions

@table @code
@semanticAction{note, elementSpecifier id}

Defines the endnote displayed at the bottom of the file. The id
attribute has to be unique, and be identical to the id attribute in a
@code{noteref} in the file in order to be displayed, but the
@code{note} action can appear before the corresponding @code{noteref}
action if needed.

Given the following definition in the semantic action file

@example
note    mynote,idref
@end example

we could define an endnote in the input file as follows:

@example
<mynote idref="1">This is an endnote</mynote>
@end example

@semanticAction{noteref, elementSpecifier id}

Defines the position where the endnote reference character should be
placed, as well as the endnote reference character in the endnote at
the bottom of the file. The order that these appear in the input file
determines the order that they appear in the endnote section.

Given the following definition in the semantic action file

@example
noteref    mynoteref,idref
@end example

we could place a reference to an endnote in the input file as follows:

@example
<mynoteref idref="1">*</mynoteref>
@end example

@semanticAction{notesheader, elementSpecifier}

The text enclosed defines the header to be placed at the top of the
first endnote page. For multiple of these defined in the input, the
last one is used.

Given the following definition in the semantic action file

@example
notesheader    mynotesheader
@end example

we could define the page header of the first endnotes page in the
input file as follows:

@example
<mynotesheader>Endnote Page Header</mynotesheader>
@end example

@semanticAction{notesdescription, elementSpecifier}

Defines some text to be placed after the @semanticref{notesheader},
but before the rest of the endnotes. Again, for multiple definitions
in the input file, the last one will be used.

Given the following definition in the semantic action file

@example
notesdescription    mynotesdescription
@end example

we could define some text to appear on the first endnotes page in the
input file as follows:

@example
<mynotesdescription>Endnote Page Text</mynotesdescription>
@end example
@end table

@node Example
@subsection Example

So, to define end notes we need an input file (@pxref{endnotes.xml})
containing end notes and references to them , end notes have to be
enabled in the ini file or via command line options
(@pxref{endnotes.ini}) and finally we have to specify which element in
the input file constitutes an endnote and a reference to it by
defining this in a semantic action file (@pxref{endnotes.sem}).
Optionally we can also define styles for the notes, the header of the
notes page and the descriptive text (@pxref{endnote styles}).

The following example shows the relevant excerpts in the input, sem
and configuration files together with the resulting output
(@pxref{endnote output}).

@subsubsection input.xml
@anchor{endnotes.xml}

@example
<?xml version=""1.0" encoding="UTF-8"?>
<doc>
    <notesheader>not seen header</notesheader>
    <notesdescription>not seen description</notesdescription>

    <note id = "2">Endnote Description 2</note>

    <p>Foo<noteref id = "1">1</noteref>Bar.</p>
    <p>Foo<noteref id = "2">ref2</noteref>Bar.</p>

    <notesheader>Endnotes</notesheader>
    <notesdescription>Some descriptive text</notesdescription>

    <note id = "1">Endnote Description 1</note>
</doc>
@end example

@subsubsection liblouisutdml.ini
@anchor{endnotes.ini}

@example
endnotes yes
@end example

@subsubsection endnotes.sem
@anchor{endnotes.sem}

@example
note                note,id
noteref             noteref,id
notesheader         notesheader
notesdescription    notesdescription
@end example

@subsubsection styles.cfg
@anchor{endnote styles}

@example
style note
    leftMargin 2
    firstLineIndent 2

style notesheader
    format centered

style notesdescription
    format leftJustified
@end example

@subsubsection output.txt
@anchor{endnote output}

@example
Foo 99#a Bar.
Foo 99ref#b Bar.






-page-
     Endnotes Header

Some descriptive text

#a p#a#a Endnote
  Description #a
ref#b p#a#b Endnote
  Description #b
-page-
@end example

@node Special Formats
@chapter Special Formats

@menu
* Tables::
* Reserving Space for Graphics::
* Displayed Text::
* Displayed Mathematics::
* Spatial Layouts in Mathematics::
* Arithmetic Examples::
* Poetry::
* Dividing a Book Into Volumes::
@end menu

@node Tables
@section Tables

Various methods of handling tables can be devised. One that is in
current use requires the following lines in a semantic-action file:

@example
list tr \*;
generic td \*;\s
@end example

The @code{list} style specifies that the first line should begin at the
left
margin and subsequent lines should be indented two spaces. The third
column specifies that a semicolon should be placed at the very end of
the row. The @code{generic} semantic action causes each column in the
table to be followed by a semicolon and a space, as specified in the
third column. your liblouis table must also contain the following line:


@example
noback always ;\s; 0
@end example

@node Reserving Space for Graphics
@section Reserving Space for Graphics

Your configuration files should contain lines like these:

@example
style graphspace
rightHandPage yes
@end example

In your semantic-action file you must assign a tag to this style. Note
that the semantic action @code{graphic} will invoke code to translate
SVG graphics when this feature is developed. You can nest various styles
within the @samp{graphspace} style, such as a caption at the beginning.
In particular, you should have another invocation of @samp{graphspace}
at the end to skip to a new page, or the next right-hand page if you are
using interpoint.

@node Displayed Text
@section Displayed Text

Conventions for setting off a block of text from the rest vary. you may
wish to use the @code{quotation} style or devise a style of your own.

@node Displayed Mathematics
@section Displayed Mathematics

Again, conventions vary. you can define your own style for this purpose
and invoke it according to the attributes of the @code{math} tag.

@node Spatial Layouts in Mathematics
@section Spatial Layouts in Mathematics

This is also known as 2d mathematics. It spreads out complex fractions
and other materials for easier viewing. It is being developed based on
the specifications of MathML 3.

@node Arithmetic Examples
@section Arithmetic Examples

This is another format that is being developed using MathML 3. It is
difficult in earlier versions.

@node Poetry
@section Poetry

@file{liblouisutdml.ini} defines two styles which can be used to format
poetry, as follows:

@example
style stanza
linesBefore 1
linesAfter 1
style line
leftMargin 2
firstLineIndent -2
@end example

Your document might then contain the following from Samuel Taylor
Coleridge's "Rime of the Ancient Mariner":

@example
<stanza>
<line>He holds him with his glittering eye</line>
<line>The wedding guest stands still</line>
<line>And listens like a three-years' child.</line>
<line>He has no force nor will.</line>
</stanza>
@end example

Note that when stanzas follow each other liblouisutdml will produce only
one blank line between them, not two.

@node Dividing a Book Into Volumes
@section Dividing a Book Into Volumes

Details are still under development. However, this much can be said.
First, obtain a table of contents for the whole book. This requires that
your configuration files have the following settings:

@example
contents yes
braillePages yes
@end example

This will tell you the approximate braille pages on which things will be
placed in the finished product. You can then calculate the number of
pages required for each chapter and how many chapters will fit in a
volume of your preferred size. From the point of view of the braille
reader, it is desirable to avoid splitting chapters between volumes.

At this point you will probably have to edit the source xml file to
indicate the beginning and end of volumes. You can define a liblouisutdml
style called @samp{volume} and assign appropriate xml tags to it in a
semantic-action file. Within the volume style you can nest a title page,
chapters, etc. A volume table of contents is still under development.

@node Implementing Braille Mathematics Codes
@chapter Implementing Braille Mathematics Codes

Much information useful in implementing braille mathematical codes is
given in the sections on styles and on semantic actions, especially in
the discussion of MathML semantic actions. The chapter on Special
Formats also contains much useful information.

The Nemeth Code of Braille Mathematical and Science Notation, BAUK maths
and Marburg Maths have been implemented. the Nemeth code was the first
and uses an implementation which is now obsolete. The discussion below
will concentrate on the implementation of BAUK Maths.

Four tables are used to translate xml documents containing a mixture of
text and mathematics. They can be found in the subdirectory
@file{lbu_files} of the liblouisutdml directory and in the @file{tables}
subdirectory of the liblouis distribution. First, the semantic-action
file @file{ukmaths.sem} is used to interpret the mathematical portions
of the xml document (The text portions are interpreted by another
semantic-action file which will not be discussed here). After the math
and text have been interpreted, two liblouis tables, @file{ukmaths.ctb}
and @file{en-us-g2.ctb} are used to translate them. The latter table may
be replaced by another table at the user's discretion. Each piece of
mathematics or text is translated separately and the pieces are strung
together with blanks between them. This results in inaccuracies where
mathematics meets text. The fourth table, also a liblouis table, is used
to remove these inaccuracies. It is called @file{ukmaths_edit.ctb}, and
it does things like removing the multi-purpose indicator before a blank,
inserting the punctuation indicator before a punctuation mark following
a math expression, and removing extra spaces. This table may need
editing if a different text translation table is used.

The general format and use of semantic-action files were discussed in
the section @pxref{Connecting with the xml Document,
Connecting with the xml Document - Semantic-Action Files, Connecting
with the xml Document - Semantic-Action Files}. In this section we
shall concentrate on the optional third column, which is used a lot in
@file{ukmaths.sem}. While the first two columns can be generated by
liblouisutdml but must be edited by a person, the third column must
always be provided by a human.

As previously stated, the third column tells liblouisutdml what
characters to insert to inform liblouis how to translate the math
expression. In fact, you can tell liblouis exactly what dots to insert.
This relies on the liblouis opcode @code{exactdots}. If you look at the
file @file{example_ukmaths.ctb} you will see lines like the following:

@example
exactdots @@126
exactdots @@345
exactdots @@123456
@end example

This opcode has only a string operand. liblouis assumes that the
characters following the at sign are its dot pattern.

In your semantic-action file you might have lines like:

@example
mfenced mfenced @@126,@@345
mfenced mfenced,open,@{ @@246,@@135
mover mover ,@@4-346,@@12456
@end example

By using this approach you do not have to remember which characters will
produce the desired dots in a particular liblouis table or on a
particular output device.

Sometimes an element or tag can have an indeterminate number of
children. This is true of @code{<math>} itself. Yet, it may be
necessary to place some characters after the very last element. Let us
look at the @code{<math>} entry.

@example
math math \eb,\*\ee
@end example

First let us discuss escape sequences starting with a backslash. These
are basically the same as in liblouis. The sequence @samp{\e} is
shorthand for the escape character, which would otherwise be
represented by @samp{\x001b}. The beginning of a math expression is
denoted by an escape character followed by the letter b and the end by
an escape character followed by the letter @samp{e}. This enables the
editing table to do such things as drop the baseline indicator at the
end of a math expression and insert a number sign at the beginning, if
needed.

Not found in liblouis is the sequence @samp{\*}. This means to put
what follows after the very last child of the math element, no matter
how many there are.

As another example consider:

@example
mtd mtd \*\ec
@end example

@code{mtd} is the MathML tag for a table column. There may be many
children of this tag. The entry says to put an escape character (hex
1b), plus the letter @samp{c}, after the very last of them.

As a final example consider:

@example
mtr mtr ^.^\,^(,\*^.^\,^)\er
@end example

@code{mtr} is the MathML tag for a row in a table, in this case a
matrix. Each row in a matrix must begin with the dot pattern
@samp{46-6-12356} and end with the dot pattern @samp{46-6-12456}. As
usual a caret is placed before the corresponding characters. Since dot
6 is a comma, it must be escaped. This is done by placing a backslash
before the comma. There are two subcolumns. the first contains the
characters to be placed at the beginning of each row. The second
starts with @samp{\*}, signifying that the characters following it
are to be placed at the end of everything in this row. A subcolumn
starting with @samp{\*} must be the last (or only) subcolumn.

Here this last subcolumn ends with an escape character and the letter
@key{r}, signifying the end of a row.

So much for the semantic action file. Even though the characters in
the third column were chosen to correspond with nemeth characters,
they may not have to be changed for other math codes. liblouis can
replace them with anything needed.

This brings us to a consideration of the two tables used by liblouis
to translate mathematics texts. The first, @file{en-mathtext.ctb} is
used to translate text appearing outside math expressions. It is
necessary because the Nemeth code requires modifications of Grade 2
braille. Other math codes may not have this requirement.

The table actually used to translate mathematics is @file{nemeth.ctb}.
It includes two other tables, @file{chardfs.cti} and
@file{nemethdefs.cti}. The first gives ordinary character definitions
and is included by all the other tables. Note however, that the
unbreakable space, @samp{\x00a0}, is translated by dot 9. This is used
before and after the equal sign and other symbols in
@file{nemeth.ctb}. The second table contains character definitions for
special math symbols, most of which are Unicode characters greater
than @samp{\x00ff}. The Greek letters are here. So are symbols like
the integral sign.

Most of the entries in @file{nemeth.ctb} should be familiar from other
tables. The unfamiliar ones follow the comments @samp{# Semantic
pairs} and @samp{# pass2 corrections}. The first simply replace
characters preceded by a caret with the character itself. The second
make adjustments in the code generated directly from the
@file{nemeth.sem} file. The pass2 opcode is discussed in the liblouis
documentation (@pxref{Top, , Overview, liblouis, Liblouis User's and
Programmer's Manual}). Here are some comments on a few of the entries in
@file{nemeth.ctb}.

@example
pass2 @@1456-1456 @@6-1456
@end example

Replaces double start-fraction indicators with the start complex
fraction indicator.

@example
pass2 @@3456-3456 @@6-3456
@end example

Replaces double end-fraction indicators with the end-complex-fraction
indicator.

@example
pass2 @@56[$d1-5]@@5 *
@end example

Removes the subscript and baseline indicators from numeric subscripts.

@example
pass2 @@5-9 @@9
@end example

Removes the baseline or multipurpose indicator before an unbreakable
space generated by the translation of an equal sign, etc.

@example
pass2 @@45-3-5 @@3
@end example

Replaces a superscript apostrophe with a simple prime symbol.

@example
pass2 @@9[]$d @@3456
@end example

Puts a number sign before a digit preceded by a blank.

@example
pass2 @@9-0 @@9
@end example

Removes a space following an unbreakable space.

We now come to the fourth and last table used for math translation,
the editing table, @file{nemeth_edit.ctb}. As explained at the
beginning, this table is used to remove inaccuracies where math
translation butts up against text translation. For example, the Nemeth
code puts numbers in the lower part of the cell. However, punctuation
marks are also in the lower part of the cell. So Nemeth puts a
punctuation indicator, dots @samp{456}, in front of any lower-cell
punctuation that immediately follows a mathematical expression. If
this occurs inside Mathml it is handled by @file{nemeth.ctb}. However,
a MathML expression is often followed by a punctuation mark which is
the first part of text. liblouisutdml puts a blank between math and
text, but this can result in a mathematical expression followed by a
blank and then, say, a period, dots @samp{256}. @file{nemeth_edit.ctb}
replaces the blank with the punctuation indicator.

When you look at @file{nemeth_edit.ctb} you will see that it begins with
an include of @file{chardefs.cti}. Most of the entries are ordinary,
but some are interesting. for example,

@example
always "\s 0
@end example

replaces the baseline or multipurpose indicator followed by a space
with just a space.

@node Programming with liblouisutdml
@chapter Programming with liblouisutdml

@menu
* License::
* Overview::
* Files and Paths::
* lbu_version::
* lbu_initialize::
* lbu_translateString::
* lbu_translateFile::
* lbu_translateTextFile::
* lbu_backTranslateFile::
* lbu_free::
@end menu

@node License
@section License

Liblouisutdml may contain code borrowed from the Linux screenreader
BRLTTY, Copyright @copyright{} 1999-2009
by the BRLTTY Team.

@noindent
Copyright @copyright{} 2004-2009 ViewPlus Technologies, Inc.
@uref{www.viewplus.com}.

@noindent
Copyright @copyright{} 2006,2009 Abilitiessoft, Inc.
@uref{www.abilitiessoft.org}.

Liblouisutdml is free software: you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published
by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Liblouisutdml is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with Liblouisutdml. If not, see
@uref{http://www.gnu.org/licenses/}.

@node Overview
@section Overview

liblouisutdml is an "extensible renderer", designed to translate a wide
variety of xml and text documents into braille, but with a special
emphasis on
technical material. The overall operation of liblouisutdml is controlled
by a configuration file. The way in which a particular type of xml
document is to be rendered is specified by a semantic-action file for
that document type. Braille translation is done by the liblouis
braille translation and back-translation library (@pxref{Top, ,
Overview, liblouis, Liblouis User's and Programmer's Manual}).
Its operation, in turn is controlled by translation table files. All
these files are plain text and can be created and edited in any text
editor. Configuration settings can also be specified on the command
line of the console-mode transcription program @command{file2brl}.

The general operation of liblouisutdml is as follows. It uses the libxml2
library to construct a parse tree of the xml document. After the parse
tree is constructed, a function called @code{examine_document} looks it
over and determines whether math translation tables, etc. are needed.
@code{examine_document} also constructs a prototype semantic-action
file, if one does not exist already. It may also construct another file
containing entries not found in an existing file. When it is finished,
another function, called @code{transcribe_document}, does the actual
braille transcription. It calls @code{transcribe_math} to handle MathML
subtrees, @code{transcribe_chemistry} for chemical formula subtrees,
@code{transcribe_graphic} for SVG graphics, etc. Entities are translated
to Unicode, if they are not already. Sequences of symbols indicate
superscripts, return to the baseline, subscripts, start and end of
fractions, etc. The Braille translator and back-translator library
liblouis is used to do the braille translation.


The @code{transcribe_math} function works in conjunction with the
latest version of liblouis and a special math translation table to
transcribe most mathematical expressions into good braille mathematical
Code.

The functions which are not ready for use at the moment, such as
@code{transcribe_chemistry}, are only skeletons. However, I hope that
@code{transcribe_graphics} can be expanded in the near future to use the
graphics capability of the Tiger tactile graphics embossers.

The latest versions of liblouisutdml and liblouis can be downloaded
from @uref{www.liblouis.org}. This site also contains links to a
mailing list and to project pages on github.com. Note that
liblouisutdml will only work with the latest version of liblouis.

liblouisutdml can be compiled to use either 16-bit or 32-bit Unicode
internally. This is inherited from liblouis, so liblouis must be
compiled first and then liblouisutdml. Wherever 16 bits are mentioned in
this document, read 32 if you have compiled the library for 32 bits.

@node Files and Paths
@section Files and Paths

liblouisutdml uses three kinds of
files, configuration files, semantic-action files, and liblouis
translation tables. The first two are discussed elsewhere in this
documentation. liblouis translation tables are discussed in the
liblouis documentation (@pxref{Top, , Overview, liblouis, Liblouis
User's and Programmer's Manual}) which is distributed with liblouis.

Note that liblouisutdml also generates some files, all of which are placed
in the current directory. These files are new prototype semantic-action
files, additions to old semantic-action files, temporary files, and log
files. The first two can be used to extend the capability of liblouisutdml
to process xml documents. The latter two are useful for debugging.

liblouisutdml determines the paths on which it will search for files at
run time, as part of its initialization. First, if the first file in a
configuration file list includes a path, liblouisutdml will search first
on this path. The path may be either absolute or relative. Only the
first filename in a configuration file list may have a path. Next, in
Windows, liblouisutdml determines the path to itself. this is the second
path on which it will look for files. The liblouis @file{tables}
directory and the liblouisutdml @file{lbu_files} directory are relative to
this path. In Unix systems, including the Mac,, these directories are
absolute paths determined at compile time. liblouisutdml searches first
the @file{tables} directory and then the @file{lbu_files} directory.
Finally, it establishes the current directory as the final path to be
searched. If you wish the current directory to be the first path
searched, prefix the first configuration file name with @samp{./} for
Unix or @samp{.\} for Windows.

Paths are handled in the @code{paths.c} module. This contains the
function @code{set_paths}, which is called from @code{readconfig.c} and
in turn calls @code{addPath} in the @code{paths.c} module.

@node lbu_version
@section lbu_version

@findex lbu_version
@example
char *lbu_version (void)
@end example

This function returns a pointer to a character string containing the
version of liblouisutdml. Other information such as the release
date and perhaps notable changes may be added later.

@node lbu_initialize
@section lbu_initialize

@findex lbu_initialize
@example
void * lbu_initialize (
const char *configFilelist,
const char *logFileName,
const char *settingsString)
@end example

This function initializes the libxml2 library, processes
@file{liblouisutdml.ini} and configuration settings given in
the configuration files given in @code{configFilelist}. This is a list
of configuration file names separated by commas. If the first character
is a comma it is taken to be a string containing configuration settings
and is processed like the @code{settingsString} string. if the parameter
@code{settingsString} is not @code{NULL} it is processed last. Such a
string must conform to the format of a configuration file. Newlines
should be represented with ASCII 10. If @code{logfilename} is not
@code{null}, a log file is produced on the current directory. If it is
@code{null} any messages are printed on stderr. The function returns a
pointer to the @code{UserData} structure. This pointer is @code{void}
and must be cast to @code{(UserData *)} in the calling program. To
access the information in this structure you must include
@file{louisutdml.h}. This function is used by @command{file2brl}.

@node lbu_translateString
@section lbu_translateString

@findex lbu_translateString
@example
int lbu_translateString (
const char *configfilelist,
char * inbuf,
widechar *outbuf,
int *outlen,
unsigned int mode)
@end example

This function takes a well-formed xml expression in @code{inbuf} and
translates it into a string of 16-bit (or 32-bit if this has been
specified in liblouis) braille characters in @code{outbuf}. The xml
expression must be immediately followed by a zero or null byte.
Leading whitespace is ignored. If it does not then begin with the
characters @samp{<?xml} an xml header is added. If it does not begin
with @samp{<} it is assumed to be a text string and is translated
accordingly. The header is specified by the @code{xmlHeader} line in
the configuration file. If no such line is present, a default header
specifying UTF-8 encoding is used. The @code{mode} parameter specifies
whether you want the library to be initialized. If it is 0 everything
is reset, the @file{liblouisutdml.ini} file is processed and the
configuration file and/or string (see previous section) are processed.
If @code{mode} is 1 liblouisutdml simply prepares to handle a new
document. For more on the @code{mode} parameter see the next section.

Which 16-bit character in @code{outbuf} represents which dot pattern
is indicated in the liblouis translation tables. The
@code{configfilelist} parameter points to a configuration file or
string. Among other things, this file specifies translation tables. It
is these tables which control just how the translation is made,
whether in Grade 2, Grade 1, the Nemeth Code of Braille Mathematics or
something else.

Note that the @code{*outlen} parameter is a pointer to an integer.
When the function is called, this integer contains the maximum output
length. When it returns, it is set to the actual length used. The
function returns 1 if no errors were encountered and a negative number
if a complete translation could not be done.

@node lbu_translateFile
@section lbu_translateFile

@findex lbu_translateFile
@example
int lbu_translateFile (
char *configfilelist,
char *inputFileName,
char *outputFileName,
unsigned int mode)
@end example

This function accepts a well-formed xml document in
@code{inputFilename} and produces a braille translation in
@code{outputFilename}. As for @code{lbu_translateString}, the
@code{mode} parameter specifies whether the library is to be
initialized with new configuration information or simply prepared to
handle a new document. In addition, the @code{mode} parameter can
specify that a document is in html, not xhtml. @file{liblouisutdml.h}
contains an enumeration type with the values @code{dontInit} and
@code{htmlDoc}. These can be combined with an or (@samp{|}) operator. The
input file is assumed to be encoded in UTF-8, unless otherwise
specified in the xml header. The encoding of the output file may be
UTF-8, UTF-16, UTF-32 or Ascii-8. This is specified by the
@code{outputEncoding} line in the configuration file,
@code{configfilelist}. The function returns 1 if the translation was
successful.

@node lbu_translateTextFile
@section lbu_translateTextFile

@findex lbu_translateTextFile
@example
int lbu_translateTextFile (
char *configfilelist,
char *inputFileName,
char *outputFileName,
unsigned int mode)
@end example

This function accepts a text file in @code{inputFilename} and produces
a braille translation in @code{outputFilename}. The input file is
assumed to be encoded in Ascii8. However, utf-8 can be specified with
the configuration setting @code{inputTextEncoding utf8}. Blank lines
indicate the divisions between paragraphs. Two blank lines cause a
blank line between paragraphs (or headers). The output file may be in
UTF-8, UTF-16, or Ascii8, as specified by the @code{outputEncoding}
line in the configuration file, @code{configfilelist}. As for
@code{lbu_translateString}, the @code{mode} parameter specifies
whether complete initialization is to be done or simply initialization
for a new document.

@node lbu_backTranslateFile
@section lbu_backTranslateFile

@findex lbu_backTranslateFile
@example
int lbu_backTranslateFile (
char *configfilelist,
char *inputFileName,
char *outputFileName,
unsigned int mode)
@end example


This function accepts a braille file in @code{inputFilename} and
produces a back-translation in @code{outputFilename}. The input file
is assumed to be encoded in Ascii8. The output file is in either plain
text or html, according to the setting of @code{backFormat} in the
configuration file. Html files are encoded in UTF8. In plain-text,
blank lines are inserted between paragraphs. The output file may be in
UTF-8, UTF-16, or Ascii8, as specified by the @code{outputEncoding}
line in the configuration file, @code{configfilelist}. The mode
parameter specifies whether or not the library is to be initialized
with new configuration information, as described in the section on
@code{lbu_translateString} (@pxref{lbu_translateString}).

@node lbu_free
@section lbu_free

@findex lbu_free
@example
void lbu_free (void)
@end example

This function should be called at the end of the application to free
all memory allocated by liblouisutdml and liblouis. If you wish to
change configuration files during your application, use a @code{mode}
parameter of 0 on the function call using the new configuration
information. This will call the @code{lbu_free} function automatically.

@node Example files
@appendix Example files

This manual refers to files to files contained in liblouisutdml and
liblouis. You might want to look up these files in the source
distribution (located under @file{lbu_files/}) or online in the
@uref{https://github.com/liblouis/liblouisutdml, source code
repository} and use them as a reference or to study how things are
done. In particular the following files are mentioned:

@table @file

@item liblouisutdml.ini

The
@uref{https://github.com/liblouis/liblouisutdml/blob/master/lbu_files/liblouisutdml.ini,
main initialization file} that contains the minimal settings for
liblouisutdml operation.

@item preferences.cfg

The
@uref{https://github.com/liblouis/liblouisutdml/blob/master/lbu_files/preferences.cfg,
preferences.cfg} file contains all possible configuration settings,
with sample values, where appropriate. It is used by the
@command{file2brl} command-line interface if no configuration file is
given.

@item html.sem

An example of a
@uref{https://github.com/liblouis/liblouisutdml/blob/master/lbu_files/html.sem,
semantic action file to handle html}.

@item nemeth.sem

An example of a
@uref{https://github.com/liblouis/liblouisutdml/blob/master/lbu_files/nemeth.sem,
semantic action file to handle math}.

@item ukmaths.sem

An example of a
@uref{https://github.com/liblouis/liblouisutdml/blob/master/lbu_files/ukmaths.sem,
semantic action file to handle math}.

@item ukmaths.ctb

The
@uref{https://github.com/liblouis/liblouis/blob/master/tables/ukmaths.ctb,
liblouis UK Maths table for mathematics}.

@item ukmaths_edit.ctb

The
@uref{https://github.com/liblouis/liblouis/blob/master/tables/ukmaths_edit.ctb,
liblouis table for post-translation editing of UK Maths}.

@end table

@node Configuration Settings Index
@unnumbered Configuration Settings Index

@printindex tp

@node Semantic Action Index
@unnumbered Semantic Action Index

@printindex semantic

@node Style Index
@unnumbered Style Index

@printindex style

@node Function Index
@unnumbered Function Index

@printindex fn

@node Program Index
@unnumbered Program Index

@printindex pg

@node Concept Index
@unnumbered Concept Index

@printindex cp

@bye

