[liblouis-liblouisxml] Re: [PATCH 0/1] Finished texinfo version of liblouis-guide
- From: Christian Egli <christian.egli@xxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 02 Dec 2008 12:05:51 +0100
Hi John
On Mon, 2008-12-01 at 10:18 -0600, John J. Boyer wrote:
> Great work! I don't see the patch attached to this message.
The patch was attached to a companion message with the subject
"[PATCH 1/1] Added a texinfo version of the liblouis
guide."
(//www.freelists.org/post/liblouis-liblouisxml/PATCH-11-Added-a-texinfo-version-of-the-liblouis-guide,1)
> Two
> questions. What version of liblouis did you use?
I used version 1.3.9 which I downloaded from your site.
> Is the html xhtml?
> Ordinary html could be a problem for liblouisxml in producing a braille
> version.
The texinfo documentation says:
The HTML generated is mostly standard (i.e., HTML 2.0, RFC-1866).
One exception is that HTML 3.2 tables are generated from the
`@multitable' command, but tagged to degrade as well as possible in
browsers without table support. The HTML 4 `lang' attribute on the
`<html>' attribute is also used. (Please report output from an
error-free run of `makeinfo' which has browser portability problems as
a bug.)
I'm also attaching the generated html, txt and pdf file to give you a
feel of the generated output
I would love to get this included in the standard liblouis distribution.
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind and Visually Impaired
Grubenstrasse 12, CH-8045 Zürich, Switzerland
Table of Contents
*****************
Liblouis Programmer's and User's Guide
1 Introduction
2 Programming with liblouis
2.1 Overview
2.2 lou_version
2.3 lou_translateString
2.4 lou_translate
2.5 lou_backTranslateString
2.6 lou_backTranslate
2.7 lou_hyphenate
2.8 lou_logFileName
2.9 lou_logPrint
2.10 lou_getTable
2.11 lou_readCharFromFile
2.12 lou_free
3 Test Programs
3.1 lou_checktable
3.2 lou_allround
3.3 lou_translate -f | -b tablename
4 How to Write Translation Tables
4.1 Hyphenation Tables
4.2 Character-Definition Opcodes
4.3 Braille Indicator Opcodes
4.4 Emphasis Opcodes
4.5 Special Symbol Opcodes
4.6 Special Processing Opcodes
4.7 Translation Opcodes
4.8 Character-Class Opcodes
4.9 Swap Opcodes
4.10 The Context and Multipass Opcodes
4.11 The correct Opcode
4.12 Miscellaneous Opcodes
5 Notes on Back-Translation
Opcode Index
Function Index
Program Index
Liblouis Programmer's and User's Guide
**************************************
This manual is for liblouis (version 1.3.9, 2 December 2008), a Braille
Translation and Back-Translation Library derived from the Linux
screenreader BRLTTY.
Copyright (C) 1999-2008 by the BRLTTY Team.
It is also Copyright (C) 2004-2008 by ViewPlus Technologies, Inc.
`www.viewplus.com' and JJB Software, Inc. `www.jjb-software.com'.
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.
1 Introduction
**************
Liblouis is an open-source braille translator and back-translator
derived from the translation routines in the BRLTTY screenreader for
Linux. It has, however, gone far beyond these routines. It is named in
honor of Louis Braille. In Linux and Mac OSX it is a shared library,
and in Windows it is a DLL. For installation instructions see the
README file. Please report bugs and oddities to the maintainer,
<john.boyer@xxxxxxxxxxxxxxxx>
This documentation is derived from Chapter 7 of the BRLTTY manual,
but it has been extensively rewritten to cover new features.
Please read the following copyright and warranty information. Note
that this information also applies to all source code, tables and other
files in this distribution of liblouis. It applies similarly to the
sister library liblouisxml.
This file is maintained by John J. Boyer
<john.boyer@xxxxxxxxxxxxxxxx>.
Persons who wish to write translation tables but will not be
programming with liblouis may want to skip ahead to *note Test
Programs:: or *note How to Write Translation Tables::.
2 Programming with liblouis
***************************
2.1 Overview
============
You use the liblouis library by calling eleven functions,
`lou_translateString', `lou_backTranslateString', `lou_logFileName',
`lou_logPrint', `lou_getTable', `lou_translate', `lou_backTranslate',
`lou_hyphenate', `lou_readCharFromFile' and `lou_free'. These are
described below. The header file, `liblouis.h', also contains brief
descriptions. Liblouis is written in straight C. It has just three code
modules, `compileTranslationTable.c', `lou_translateString.c' and
`lou_backTranslateString.c'. In addition, there are two header files,
`liblouis.h', which defines the API, and `louis.h', used only
internally. The latter includes `liblouis.h'.
`compileTranslationTable.c' keeps track of all translation tables
which an application has used. It is called by the translation,
hyphenation and checking functions when they start. If a table has not
yet been compiled `compileTranslationTable.c' checks it for correctness
and compiles it into an efficient internal representation. The main
entry point is `lou_getTable'. Since it is the module that keeps track
of memory usage, it also contains the `lou_free' function. In addition,
it contains the `lou_logFileName' and `lou_logPrint' functions, plus
some utility functions which are used by the other modules.
By default, liblouis handles all characters internally as 16-bit
unsigned integers. It can be compiled for 32-bit characters as
explained below. The meanings of these integers are not hard-coded.
Rather they are defined by the character-definition opcodes. However,
the standard printable characters, from decimal 32 to 126 are
recognized for the purpose of processing the opcodes. Hence, the
following definition is included in `liblouis.h'. It is correct for
computers with at least 32-bit processors.
#define widechar unsigned short int
To make liblouis handle 32-bit Unicode simply remove the word
`short' in the above `define'. This will cause the translate and
back-translate functions to expect input in 32-bit form and to deliver
their output in this form. The input to the compiler (tables) is
unaffected except that two new escape sequences for 20-bit and 32-bit
characters are recognized.
Here are the definitions of the eleven liblouis functions and their
parameters. They are given in terms of 16-bit Unicode. If liblouis has
been compiled for 32-bit Unicode simply read 32 instead of 16.
2.2 lou_version
===============
char *lou_version ()
This function returns a pointer to a character string containing the
version of liblouis, plus other information, such as the release date
and perhaps notable changes.
2.3 lou_translateString
=======================
int lou_translateString (
const char *const trantab,
const widechar *const inbuf,
int *inlen,
widechar *outbuf,
int *outlen,
char *typeform,
char *spacing,
int mode);
This function takes a string of 16-bit Unicode characters in `inbuf'
and translates it into a string of 16-bit characters in `outbuf'. Each
16-bit character produces a particular dot pattern in one braille cell
when sent to an embosser or braille display or to a screen typefont.
Which 16-bit character represents which dot pattern is indicated by the
character-definition and display opcodes in the translation table.
The `trantab' parameter points to a list of translation tables
separated by commas. If only one table is given, no comma should be
used after it. It is these tables which control just how the
translation is made, whether in Grade 2, Grade 1, or something else.
The first table in the list must be a full pathname, unless the tables
are in the current directory. The pathname is extracted up to the
filename. The first table is then compiled. The pathname is then added
to the name of the second table, which is compiled, and so on. The
tables in a list are all compiled into the same internal table. The
list is then regarded as the name of this table. As explained in *note
How to Write Translation Tables::, each table is a file which may be
plain text, big-endian Unicode or little-endian Unicode. A table (or
list of tables) is compiled into an internal representation the first
time it is used. Liblouis keeps track of which tables have been
compiled. For this reason, it is essential to call the lou_free
function at the end of your application to avoid memory leaks. Do _NOT_
call `lou_free' after each translation. This will force liblouis to
compile the translation tables each time they are used, leading to
great inefficiency.
Note that both the `*inlen' and `*outlen' parameters are pointers to
integers. When the function is called, these integers contain the
maximum input and output lengths, respectively. When it returns, they
are set to the actual lengths used.
The `typeform' parameter is used to indicate italic type, boldface
type, computer braille, etc. It is a string of characters with the same
length as the input buffer pointed to by `*inbuf'. However, it is used
to pass back character-by-character results, so enough space must be
provided to match the `*outlen' parameter. Each character indicates
the typeform of the corresponding character in the input buffer. The
values are as follows: 0 plain-text; 1 italic; 2 bold; 4 underline; 8
computer braille. These values can be added for multiple emphasis. If
this parameter is `NULL', no checking for typeforms is done. In
addition, if this parameter is not `NULL', it is set on return to have
an 8 at every position corresponding to a character in `outbuf' which
was defined to have a dot representation containing dot 7, dot 8 or
both, and to 0 otherwise.
The `spacing' parameter is used to indicate differences in spacing
between the input string and the translated output string. It is also
of the same length as the string pointed to by `*inbuf'. If this
parameter is `NULL', no spacing information is computed.
The `mode' parameter specifies how the translation should be done.
The valid values of mode are listed in `liblouis.h'. They are all
powers of 2, so that a combined mode can be specified by adding up
different values.
The function returns 1 if no errors were encountered and 0 if a
complete translation could not be done.
2.4 lou_translate
=================
int lou_translate (
const char *const trantab,
const widechar * const inbuf,
int *inlen,
widechar * outbuf,
int *outlen,
char *typeform,
char *spacing,
int *outputPos,
int *inputPos,
int *cursorPos,
int mode);
This function adds the parameters `outputPos', `inputPos' and
`cursorPos', to facilitate use in screenreader programs. The
`outputPos' parameter must point to an array of integers with at least
`outlen' elements. On return, this array will contain the position in
`inbuf' corresponding to each output position. Similarly, `inputPos'
must point to an array of integers of at least `inlen' elements. On
return, this array will contain the position in `outbuf' corresponding
to each position in `inbuf'. `cursorPos' must point to an integer
containing the position of the cursor in the input. On return, it will
contain the cursor position in the output. Any parameter after `outlen'
may be `NULL'. In this case, the actions corresponding to it will not
be carried out. The `mode' parameter, however, must be present and must
be an integer, not a pointer to an integer. If the `compbrlAtCursor'
bit is set in the `mode' parameter the space-bounded characters
containing the cursor will be translated in computer braille.
2.5 lou_backTranslateString
===========================
int lou_backTranslateString (
const char *const trantab,
const widechar *const inbuf,
int *inlen,
widechar *outbuf,
int *outlen,
char *typeform,
char *spacing,
int mode);
This is exactly the opposite of `lou_translateString'. `inbuf' is a
string of 16-bit Unicode characters representing braille. `outbuf' will
contain a string of 16-bit Unicode characters. `typeform' will indicate
any emphasis found in the input string, while `spacing' will indicate
any differences in spacing between the input and output strings. The
`typeform' and `spacing' parameters may be `NULL' if this information is
not needed. `mode' again specifies how the back-translation should be
done.
2.6 lou_backTranslate
=====================
int lou_backTranslate (
const char *const trantab,
const widechar *const inbufx,
int *inlen,
widechar * outbuf,
int *outlen,
char *typeform,
char *spacing,
int *outputPos,
int *inputPos,
int *cursorPos,
int mode);
This function is exactly the inverse of `lou_translate'.
2.7 lou_hyphenate
=================
int lou_hyphenate (
const char *const trantab,
const widechar * const inbuf,
int inlen,
char *hyphens,
int mode);
This function looks at the characters in `inbuf' and if it finds a
sequence of letters attempts to hyphenate it as a word. Leading and
trailing punctuation marks are ignored. The table named by the
`trantab' parameter must contain a hyphenation table. If it does not,
the function does nothing. `inlen' is the length of the character
string in `inbuf'. `hyphens' is an array of characters and must be of
size `inlen'. If hyphenation is successful it will have a 1 at the
beginning of each syllable and a 0 elsewhere. If the `mode' parameter
is 0 `inbuf' is assumed to contain untranslated characters. Any nonzero
value means that `inbuf' contains a translation. In this case, it is
back-translated, hyphenation is performed, and it is retranslated so
that the hyphens can be placed correctly. The `lou_translate' and
`lou_backTranslate' functions are used in this process.
`lou_hyphenate' returns 1 if hyphenation was successful and 0
otherwise. In the latter case, the contents of the `hyphens' parameter
are undefined. This function was provided for use in liblouisxml.
2.8 lou_logFileName
===================
void lou_logFileName (char *fileName);
This function is used when it is not convenient either to let
messages be printed on stderr or to use redirection, as when liblouis
is used in a GUI application or in liblouisxml. Any error messages
generated will be printed to the file given in this call. The entire
pathname of the file must be given.
2.9 lou_logPrint
================
void lou_logPrint (char *format, ...);
This function is called like `fprint'. It can be used by other
libraries to print messages to the file specified by the call to
`lou_logFileName'. In particular, it is used by the companion library
liblouisxml.
2.10 lou_getTable
=================
void *lou_getTable (char *tablelist);
`tablelist' is a list of names of table files separated by commas,
as explained previously (*note `trantab' parameter in
`lou_translateString': translation-tables.). If no errors are found
this function returns a pointer to the compiled table. If errors are
found messages are printed to the log file, which is stderr unless a
different filename has been given using the `lou_logFileName' function.
Errors result in a `NULL' pointer being returned.
2.11 lou_readCharFromFile
=========================
int lou_readCharFromFile (const char *fileName, int *mode);
This function is provided for situations where it is necessary to
read a file which may contain little-endian or big-endian 16-bit Unicode
characters or ASCII8 characters. The return value is a little-endian
character, encoded as an integer. The `fileName' parameter is the name
of the file to be read. The `mode' parameter is a pointer to an integer
which must be set to 1 on the first call. After that, the function
takes care of it. On end-of-file the function returns `EOF'.
2.12 lou_free
=============
void lou_free ();
This function should be called at the end of the application to free
all memory allocated by liblouis. Failure to do so will result in
memory leaks. Do _NOT_ call `lou_free' after each translation. This
will force liblouis to compile the translation tables every time they
are used, resulting in great inefficiency.
3 Test Programs
***************
Three test programs are provided as part of the liblouis package. They
are intended for testing liblouis and for debugging tables. None of
them is suitable for braille transcription. An application that can be
used for transcription is `xml2brl', which is part of the liblouisxml
package (*note Introduction: (liblouisxml-guide)Top.). The source code
of the test programs can be studied to learn how to use the liblouis
library and they can be used to perform the following functions.
3.1 lou_checktable
==================
To use this program type `lou_checktable' followed by a space and the
name of a table. If the table contains errors, appropriate messages
will be displayed. If there are no errors the message `no errors
found.' will be shown.
3.2 lou_allround
================
This program tests every capability of the liblouis library. It is
completely interactive. To start it, type `lou_allround' and then
<RET>. You will see a few lines telling you how to use the program.
Pressing one of the letters in parentheses and then enter will take you
to a message asking for more information or for the answer to a yes/no
question. Typing the letter `r' and then <RET> will take you to a
screen where you can enter a line to be processed by the library and
then view the results.
3.3 lou_translate -f | -b tablename
===================================
This program translates whatever is on the standard input unit and
prints it on the standard output unit. It is intended for large-scale
testing of the accuracy of translation and back-translation. The first
argument must be `-f' for forward translation or `-b' for backward
translation. To use it to translate or back-translate a file use a line
like
`./lou_translate -f en-us-g2.ctb <liblouis-guide.txt >testtrans'
4 How to Write Translation Tables
*********************************
Several translation (contraction) tables have already been made up.
They are included in this distribution and should be studied as part of
the documentation. The most helpful are listed in the following table:
`chardefs.cti'
Character definitions for U.S. tables
`compress.ctb'
Remove excessive white-space
`en-us-g1.ctb'
Uncontracted American English
`en-us-g2.ctb'
Contracted or Grade 2 American English
`fr-integral.ctb'
Uncontracted Unified French
`fr-abrege.ctb'
Contracted Unified French
`french.dis'
display entries for french character to braille cells
`text.nab.dis'
North American characters to cells associations
The names used for files containing translation tables are completely
arbitrary. They are not interpreted in any way by the translator.
Contraction tables may be 8-bit ASCII files, 16-bit big-endian Unicode
files or 16-bit little-endian Unicode files. Blank lines are ignored.
Any leading and trailing white-space (any number of blanks and/or tabs)
is ignored. Lines which begin with a number sign or hatch mark (`#')
are ignored, i.e. they are comments. If the number sign is not the
first non-blank character in the line, it is treated as an ordinary
character. Lines which are not blank or comments define table entries.
The general format of a table entry is:
opcode operands comments
Table entries may not be split between lines. The opcode is a
mnemonic that specifies what the entry does. The operands may be
character sequences, braille dot patterns or occasionally something
else. They are described for each opcode. With some exceptions, opcodes
expect a certain number of operands. Any text on the line after the last
operand is ignored, and may be a comment. A few opcodes accept a
variable number of operands. In this case a number sign begins a
comment unless it is preceded by a backslash (`\'). *Note Opcode
Index::, for a list of opcodes, with a link to each one.
Here are some examples of table entries.
# This is a comment.
always world 456-2456 A word and the dot pattern of its contraction
Most opcodes have both a "characters" operand and a "dots" operand,
though some have only one and a few have other types.
The characters operand consists of any combination of characters and
escape sequences proceeded and followed by whitespace. Escape sequences
are used to represent difficult characters. They begin with a backslash
(`\`). They are:
`\'
backslash
`\f'
form feed
`\n'
new line
`\r'
carriage return
`\s'
blank (space)
`\t'
horizontal tab
`\v'
vertical tab
`\e'
"escape" character (hex 1b, dec 27)
`\xhhhh'
4-digit hexadecimal value of a character
If liblouis has been compiled for 32-bit Unicode the following are
also recognized.
`\xhhhhh'
5-digit (20 bit) character
`\xhhhhhhhh'
Full 32-bit value.
The dots operand is a braille dot pattern. The real braille dots, 1
through 8, must be specified with their standard numbers. liblouis
recognizes "virtual dots," which are used for special purposes, such as
distinguishing accent marks. There are seven virtual dots. They are
specified by the number 9 and the letters `a' through `f'. For a
multi-cell dot pattern, the cell specifications must be separated from
one another by a dash (`-'). For example, the contraction for the
English word `lord' (the letter `l' preceded by dot 5) would be
specified as 5-123. A space may be specified with the special dot
number 0.
An opcode which is helpful in writing translation tables is
`include'. Its format is:
include filename
It reads the file indicated by `filename' and incorporates or
includes its entries into the table. Included files can include other
files, which can include other files, etc. For an example, see what
files are included by the entry `include en-us-g1.ctb' in the table
`en-us-g2.ctb'. If the included file is not in the same directory as
the main table, use a full pathname for filename.
The order of the various types of opcodes or table entries is
important. Character-definition opcodes should come first. However, if
the optional `display' opcode is used (*note display: display opcode.)
it should precede character-definition opcodes. Braille-indicator
opcodes should come next. Translation opcodes should follow. The
`context' opcode is a translation opcode, even though it is considered
along with the multipass opcodes. These latter should follow the
translation opcodes. the `correct' opcode can be used anywhere after
the character-definition opcodes, but it is probably a good idea to
group all `correct' opcodes together. The `include' opcode can be used
anywhere, but the order of entries in the combined table must conform
to the order given above. Within each type of opcode, the order of
entries is generally unimportant. Thus the translation entries can be
grouped alphabetically or in any other order that is convenient.
4.1 Hyphenation Tables
======================
Hyphenation tables are necessary to make opcodes such as the `nocross'
opcode (*note nocross: nocross opcode.) function properly. There are no
opcodes for hyphenation table entries because these tables have a
special format. Therefore, they cannot be specified as part of an
ordinary table. Rather, they must be included using the `include'
opcode (*note include: include opcode.). Hyphenation tables must
follow character definitions. For an example of a hyphenation table,
see `hyph_en_US.dic'.
4.2 Character-Definition Opcodes
================================
These opcodes are needed to define attributes such as digit,
punctuation, letter, etc. for all characters and their dot patterns.
liblouis has no built-in character definitions, but such definitions
are essential to the operation of the `context' opcode (*note context:
context opcode.), the `correct' opcode (*note correct: correct
opcode.), the multipass opcodes and the back-translator. If the dot
pattern is a single cell, it is used to define the mapping between dot
patterns and characters, unless a `display' opcode (*note display:
display opcode.) for that character-dot-pattern pair has been used
previously. If only a single-cell dot pattern has been given for a
character, that dot pattern is defined with the character's own
attributes. If more than one cell is given and some of them have not
previously been defined as single cells, the undefined cells are
entered into the dots table with the undefined attribute. This is done
for backward compatibility with old tables, but it may cause problems
with the above opcodes or back-translation. For this reason, every
single-cell dot pattern should be defined before it is used in a
multi-cell character representation. The best way to do this is to use
the 8-dot computer braille representation for the particular braille
code. If a character or dot pattern used in any rule, except those with
the `display' opcode, the `repeated' opcode (*note repeated: repeated
opcode.) or the `replace' opcode (*note replace: replace opcode.), is
not defined by one of the character-definition opcodes, liblouis will
give an error message and refuse to continue until the problem is
fixed. If the translator or back-translator encounters an undefined
character in its input it produces a succinct error indication in its
output, and the character is treated as a space.
`space character dots'
Defines a character as a space and also defines the dot pattern as
such. for example:
space \s 0 \s is the escape sequence for blank; 0 means no dots.
`punctuation character dots'
Associates a punctuation mark in the particular language with a
braille representation and defines the character and dot pattern as
punctuation. For example:
punctuation . 46 dot pattern for period in NAB computer braille
`digit character dots'
Associates a digit with a dot pattern and defines the character as
a digit. For example:
digit 0 356 NAB computer braille
`uplow characters dots [,dots]'
The characters operand must be a pair of letters, of which the
first is uppercase and the second lowercase. The first dots
suboperand indicates the dot pattern for the upper-case letter. It
may have more than one cell. The second dots suboperand must be
separated from the first by a comma and is optional, as indicated
by the square brackets. If present, it indicates the dot pattern
for the lower-case letter. It may also have more than one cell. If
the second dots suboperand is not present the first is used for
the lower-case letter as well as the upper-case letter. This
opcode is needed because not all languages follow a consistent
pattern in assigning Unicode codes to upper and lower case
letters. It should be used even for languages that do. The
distinction is important in the forward translator. for example:
uplow Aa 1
`letter character dots'
Associates a letter in the language with a braille representation
and defines the character as a letter. This is intended for
letters which are neither uppercase nor lowercase.
`lowercase character dots'
Associates a character with a dot pattern and defines the
character as a lowercase letter. Both the character and the dot
pattern have the attributes lowercase and letter.
`uppercase character dots'
Associates a character with a dot pattern and defines the
character as an uppercase letter. Both the character and the dot
pattern have the attributes uppercase and letter. `lowercase' and
`uppercase' should be used when a letter has only one case.
Otherwise use the `uplow' opcode (*note uplow: uplow opcode.).
`litdigit digit dots'
Associates a digit with the dot pattern which should be used to
represent it in literary texts. For example:
litdigit 0 245
litdigit 1 1
`sign character dots'
Associates a character with a dot pattern and defines both as a
sign. This opcode should be used for things like at sign (`@'),
percent (`%'), dollar sign (`$'), etc. Do not use it to define
ordinary punctuation such as period and comma. For example:
sign % 4-25-1234 literary percent sign
`math character dots'
Associates a character and a dot pattern and defines them as a
mathematical symbol. It should be used for less than (`<'),
greater than(`>'), equals(`='), plus(`+'), etc. For example:
math + 346 plus
4.3 Braille Indicator Opcodes
=============================
Braille indicators are dot patterns which are inserted into the braille
text to indicate such things as capitalization, italic type, computer
braille, etc. The opcodes which define them are followed only by a dot
pattern, which may be one or more cells.
`capsign dots'
The dot pattern which indicates capitalization of a single letter.
In English, this is dot 6. for example:
capsign 6
`begcaps dots'
The dot pattern which begins a block of capital letters. For
example:
begcaps 6-6
`endcaps dots'
The dot pattern which ends a block of capital letters within a
word. For example:
endcaps 6-3
`letsign dots'
This indicator is needed in Grade 2 to show that a single letter is
not a contraction. It is also used when an abbreviation happens to
be a sequence of letters that is the same as a contraction. For
example:
letsign 56
`noletsign letters'
The letters in the operand will not be proceeded by a letter sign.
More than one `noletsign' opcode can be used. This is equivalent
to a single entry containing all the letters. In addition, if a
single letter, such as `a' in English, is defined as a `word'
(*note word: word opcode.) or `largesign' (*note largesign:
largesign opcode.), it will be treated as though it had also been
specified in a `noletsign' entry.
`noletsignbefore characters'
If any of the characters proceeds a single letter without a space a
letter sign is not used. By default the characters apostrophe
(`'') and period (`.') have this property. Use of a
`noletsignbefore' entry cancels the defaults. If more than one
`noletsignbefore' entry is used, the characters in all entries are
combined.
`noletsignafter characters'
If any of the characters follows a single letter without a space a
letter sign is not used. By default the characters apostrophe
(`'') and period (`.') have this property. Use of a
`noletsignafter' entry cancels the defaults. If more than one
`noletsignafter' entry is used the characters in all entries are
combined.
`numsign dots'
The translator inserts this indicator before numbers made up of
digits defined with the `litdigit' opcode (*note litdigit:
litdigit opcode.) to show that they are a number and not letters
or some other symbols. For example:
numsign 3456
4.4 Emphasis Opcodes
====================
These also define braille indicators, but they require more
explanation. There are four sets, for italic, bold, underline and
computer braille. In each of the first three sets there are seven
opcodes, for use before the first word of a phrase, for use before the
last word, for use after the last word, for use before the first letter
(or character) if emphasis starts in the middle of a word, for use
after the last letter (or character) if emphasis ends in the middle of
a word, before a single letter (or character), and to specify the
length of a phrase to which the first-word and last-word-before
indicators apply. This rather elaborate set of emphasis opcodes was
devised to try to meet all contingencies. It is unlikely that a
translation table will contain all of them. The translator checks for
their presence. If they are present, it first looks to see if the
single-letter indicator should be used. Then it looks at the word (or
phrase) indicators and finally at the multi-letter indicators.
The translator will apply up to two emphasis indicators to each
phrase or string of characters, depending on what the `typeform'
parameter in its calling sequence indicates (*note Programming with
liblouis::).
For computer braille there are only two braille indicators, for the
beginning and end of a sequence of characters to be rendered in
computer braille. Such a sequence may also have other emphasis. The
computer braille indicators are applied not only when computer braille
is indicated in the `typeform' parameter, but also when a sequence of
characters is determined to be computer braille because it contains a
subsequence defined by the `compbrl' opcode (*note compbrl: compbrl
opcode.) or the `literal' opcode (*note literal: literal opcode.).
Here are the various emphasis opcodes.
`firstwordital dots'
This is the braille indicator to be placed before the first word
of an italicized phrase that is longer than the value given in the
`lenitalphrase' opcode (*note lenitalphrase: lenitalphrase
opcode.). For example:
firstwordital 46-46 English indicator
`lastworditalbefore dots'
`italsign dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the last word of an italicized phrase. In addition,
if `firstwordital' is not used, this braille indicator is doubled
and placed before the first word. Do not use `lastworditalbefore'
and `lastworditalafter' in the same table. For example:
lastworditalbefore 4-6
`lastworditalafter dots'
This is the braille indicator to be placed after the last word of
an italicized phrase. Do not use `lastworditalbefore' and
`lastworditalafter' in the same table. See also the
`lenitalphrase' opcode (*note lenitalphrase: lenitalphrase
opcode.) for more information.
`firstletterital dots'
`begital dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the first letter (or character) if italicization
begins in the middle of a word.
`lastletterital dots'
`endital dots'
These two opcodes are synonyms. This is the braille indicator to be
placed after the last letter (or character) when italicization
ends in the middle of a word.
`singleletterital dots'
This braille indicator is used if only a single letter (or
character) is italicized.
`lenitalphrase number'
If `lastworditalbefore' is used, an italicized phrase is checked
to see how many words it contains. If this number is less than or
equal to the number given in the `lenitalphrase' opcode, the
`lastworditalbefore' sign is placed in front of each word. If it
is greater, the `firstwordital' indicator is placed before the
first word and the `lastworditalbefore' indicator is placed after
the last word. Note that if the `firstwordital' opcode is not used
its indicator is made up by doubling the dot pattern given in the
`lastworditalbefore' entry. For example:
lenitalphrase 4
`firstwordbold dots'
This is the braille indicator to be placed before the first word
of a bold phrase. For example:
firstwordbold 456-456
`lastwordboldbefore dots'
`boldsign dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the last word of a bold phrase. In addition, if
`firstwordbold' is not used, this braille indicator is doubled and
placed before the first word. Do not use `lastwordboldbefore' and
`lastwordboldafter' in the same table. For example:
lastwordboldbefore 456
`lastwordboldafter dots'
This is the braille indicator to be placed after the last word of a
bold phrase. Do not use `lastwordboldbefore' and
`lastwordboldafter' in the same table.
`firstletterbold dots'
`begbold dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the first letter (or character) if bold emphasis
begins in the middle of a word.
`lastletterbold dots'
`endbold dots'
These two opcodes are synonyms. This is the braille indicator to be
placed after the last letter (or character) when bold emphasis
ends in the middle of a word.
`singleletterbold dots'
This braille indicator is used if only a single letter (or
character) is in boldface.
`lenboldphrase number'
If `lastwordboldbefore' is used, a bold phrase is checked to see
how many words it contains. If this number is less than or equal to
the number given in the `lenboldphrase' opcode, the
`lastwordboldbefore' sign is placed in front of each word. If it
is greater, the `firstwordbold' indicator is placed before the
first word and the `lastwordboldbefore' indicator is placed after
the last word. Note that if the `firstwordbold' opcode is not used
its indicator is made up by doubling the dot pattern given in the
`lastwordboldbefore' entry.
`firstwordunder dots'
This is the braille indicator to be placed before the first word
of an underlined phrase.
`lastwordunderbefore dots'
`undersign dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the last word of an underlined phrase. In addition,
if `firstwordunder' is not used, this braille indicator is doubled
and placed before the first word.
`lastwordunderafter dots'
This is the braille indicator to be placed after the last word of
an underlined phrase.
`firstletterunder dots'
`begunder dots'
These two opcodes are synonyms. This is the braille indicator to be
placed before the first letter (or character) if underline emphasis
begins in the middle of a word.
`lastletterunder dots'
`endunder dots'
These two opcodes are synonyms. This is the braille indicator to be
placed after the last letter (or character) when underline emphasis
ends in the middle of a word.
`singleletterunder dots'
This braille indicator is used if only a single letter (or
character) is underlined.
`lenunderphrase number'
If `lastwordunderbefore' is used, an underlined phrase is checked
to see how many words it contains. If this number is less than or
equal to the number given in the `lenunderphrase' opcode, the
`lastwordunderbefore' sign is placed in front of each word. If it
is greater, the `firstwordunder' indicator is placed before the
first word and the `lastwordunderbefore' indicator is placed after
the last word. Note that if the `firstwordunder' opcode is not
used its indicator is made up by doubling the dot pattern given in
the `lastwordunderbefore' entry.
`begcomp dots'
This braille indicator is placed before a sequence of characters
translated in computer braille, whether this sequence is indicated
in the `typeform' parameter (*note Programming with liblouis::) or
inferred because it contains a subsequence specified by the
`compbrl' opcode (*note compbrl: compbrl opcode.).
`endcomp dots'
This braille indicator is placed after a sequence of characters
translated in computer braille, whether this sequence is indicated
in the `typeform' parameter (*note Programming with liblouis::) or
inferred because it contains a subsequence specified by the
`compbrl' opcode (*note compbrl: compbrl opcode.).
4.5 Special Symbol Opcodes
==========================
These opcodes define certain symbols, such as the decimal point, which
require special treatment.
`decpoint character dots'
This opcode defines the decimal point. The character operand must
have only one character. For example, in `en-us-g1.ctb' we have:
decpoint . 46
`hyphen character dots'
This opcode defines the hyphen, that is, the character used in
compound words such as have-nots. The back-translator uses it to
determine the end of individual words.
4.6 Special Processing Opcodes
==============================
These opcodes cause special processing to be carried out.
`capsnocont'
This opcode has no operands. If it is specified words or parts of
words in all caps are not contracted. This is needed for languages
such as Norwegian.
4.7 Translation Opcodes
=======================
These opcodes define the braille representations for character
sequences. Each of them defines an entry within the contraction table.
These entries may be defined in any order except, as noted below, when
they define alternate representations for the same character sequence.
Each of these opcodes specifies a condition under which the
translation is legal, and each also has a characters operand and a dots
operand. The text being translated is processed strictly from left to
right, character by character, with the most eligible entry for each
position being used. If there is more than one eligible entry for a
given position in the text, then the one with the longest character
string is used. If there is more than one eligible entry for the same
character string, then the one defined first is is tested for legality
first. (This is the only case in which the order of the entries makes a
difference.)
The characters operand is a sequence or string of characters preceded
and followed by whitespace. Each character can be entered in the normal
way, or it can be defined as a four-digit hexadecimal number preceded
by `\x'.
The dots operand defines the braille representation for the
characters operand. It may also be specified as an equals sign (`=').
This means that the the default representation for each character
(*note Character-Definition Opcodes::) within the sequence is to be
used.
In what follows the word `characters' means a sequence of one or
more consecutive letters between spaces and/or punctuation marks.
`compbrl characters'
`literal characters'
These two opcodes are synonyms. If the characters are found within
a block of text surrounded by whitespace the entire block is
translated according to the default braille representations
defined by the *note Character-Definition Opcodes::, if 8-dot
computer braille is enabled or according to the dot patterns given
in the `comp6' opcode (*note comp6: comp6 opcode.), if 6-dot
computer braille is enabled. For example:
compbrl www translate URLs in computer braille
`comp6 character dots'
This opcode specifies the translation of characters in 6-dot
computer braille. It is necessary because the translation of a
single character may require more than one cell. The first operand
must be a character with a decimal representation from 0 to 255
inclusive. The second operand may specify as many cells as
necessary. The opcode is somewhat of a misnomer, since any dots,
not just dots 1 through 6, can be specified. This even includes
virtual dots.
`nocont characters'
Like `compbrl', except that the string is uncontracted. `prepunc'
opcode (*note prepunc: prepunc opcode.) and `postpunc' opcode
(*note postpunc: postpunc opcode.) rules are applied, however.
This is useful for specifying that foreign words should not be
contracted in an entire document.
`replace characters {characters}'
Replace the first set of characters, no matter where they appear,
with the second. Note that the second operand is _NOT_ a dot
pattern. It is also optional. If it is omitted the character(s)
in the first operand will be discarded. This is useful for
ignoring characters. It is possible that the "ignored" characters
may still affect the translation indirectly. Therefore, it is
preferable to use `correct' opcode (*note correct: correct
opcode.).
`always characters dots'
Replace the characters with the dot pattern no matter where they
appear. Do _NOT_ use an entry such as `always a 1'. Use the
`uplow', `letter', etc. character definition opcodes instead. For
example:
always world 456-2456 unconditional translation
`repeated characters dots'
Replace the characters with the dot pattern no matter where they
appear. Ignore any consecutive repetitions of the same character
sequence. This is useful for shortening long strings of spaces or
hyphens or periods. For example:
repeated --- 36-36-36 shorten separator lines made with hyphens
`largesign characters dots'
Replace the characters with the dot pattern no matter where they
appear. In addition, if two words defined as large signs follow
each other, remove the space between them. For example, in
`en-us-g2.ctb' the words `and' and `the' are both defined as large
signs. Thus, in the phrase `the cat and the dog' the space would
be deleted between `and' and `the', with the result `the cat
andthe dog'. Of course, `and' and `the' would be properly
contracted. The term `largesign' is a bit of braille jargon that
pleases braille experts.
`word characters dots'
Replace the characters with the dot pattern if they are a word,
that is, are surrounded by whitespace and/or punctuation.
`syllable characters dots'
As its name indicates, this opcode defines a "syllable" which must
be represented by exactly the dot patterns given. Contractions may
not cross the boundaries of this "syllable" either from left or
right. The character string defined by this opcode need not be a
lexical syllable, though it usually will be. For example:
syllable horse = sawhorse, horseradish
`nocross characters dots'
Replace the characters with the dot pattern if the characters are
all in one syllable (do not cross a syllable boundary). For this
opcode to work, a hyphenation table must be included. If this is
not done, `nocross' behaves like the `always' opcode (*note
always: always opcode.). For example, if the English Grade 2 table
is being used and the appropriate hyphenation table has been
included `nocross sh 146' will cause the `sh' in `monkshood' not
to be contracted.
`joinword characters dots'
Replace the characters with the dot pattern if they are a word
which is followed by whitespace and a letter. In addition remove
the whitespace. For example, `en-us-g2.ctb' has `joinword to 235'.
This means that if the word `to' is followed by another word the
contraction is to be used and the space is to be omitted. If these
conditions are not met, the word is translated according to any
other opcodes that may apply to it.
`lowword characters dots'
Replace the characters with the dot pattern if they are a word
preceded and followed by whitespace. No punctuation either before
or after the word is allowed. The term `lowword' derives from the
fact that in English these contractions are written in the lower
part of the cell. For example:
lowword were 2356
`contraction characters'
If you look at `en-us-g2.ctb' you will see that some words are
actually contracted into some of their own letters. A famous
example among braille transcribers is `also', which is contracted
as `al'. But this is also the name of a person. To take another
example, `altogether' is contracted as `alt', but this is the
abbreviation for the alternate key on a computer keyboard.
Similarly `could' is contracted into `cd', but this is the
abbreviation for compact disk. To prevent confusion in such cases,
the letter sign (see `letsign' opcode (*note letsign: letsign
opcode.)) is placed before such letter combinations when they
actually are abbreviations, not contractions. The `contraction'
opcode tells the translator to do this.
`sufword characters dots'
Replace the characters with the dot pattern if they are either a
word or at the beginning of a word.
`prfword characters dots'
Replace the characters with the dot pattern if they are either a
word or at the end of a word.
`begword characters dots'
Replace the characters with the dot pattern if they are at the
beginning of a word.
`begmidword characters dots'
Replace the characters with the dot pattern if they are either at
the beginning or in the middle of a word.
`midword characters dots'
Replace the characters with the dot pattern if they are in the
middle of a word.
`midendword characters dots'
Replace the characters with the dot pattern if they are either in
the middle or at the end of a word.
`endword characters dots'
Replace the characters with the dot pattern if they are at the end
of a word.
`partword characters dots'
Replace the characters with the dot pattern if the characters are
anywhere in a word, that is, if they are proceeded or followed by a
letter.
`prepunc characters dots'
Replace the characters with the dot pattern if they are part of
punctuation at the beginning of a word.
`postpunc characters dots'
Replace the characters with the dot pattern if they are part of
punctuation at the end of a word.
`begnum characters dots'
Replace the characters with the dot pattern if they are at the
beginning of a number, that is, before all its digits. For
example, in `en-us-g1.ctb' we have `begnum # 4'.
`midnum characters dots'
Replace the characters with the dot pattern if they are in the
middle of a number. For example, `en-us-g1.ctb' has `midnum . 46'.
This is because the decimal point has a different dot pattern than
the period.
`endnum characters dots'
Replace the characters with the dot pattern if they are at the end
of a number. For example `en-us-g1.ctb' has `endnum th 1456'.
This handles things like `4th'. A letter sign is _NOT_ inserted.
`joinnum characters dots'
Replace the characters with the dot pattern. In addition, if
whitespace and a number follows omit the whitespace.
4.8 Character-Class Opcodes
===========================
These opcodes define and use character classes. A character class
associates a set of characters with a name. The name then refers to any
character within the class. A character may belong to more than one
class.
The basic character classes correspond to the character definition
opcodes, with the exception of the `uplow' opcode (*note uplow: uplow
opcode.), which defines characters belonging to the two classes
`uppercase' and `lowercase'. These classes are:
`space'
White-space characters such as blank and tab
`digit'
Numeric characters
`letter'
Both uppercase and lowercase alphabetic characters
`lowercase'
Lowercase alphabetic characters
`uppercase'
uppercase alphabetic characters
`punctuation'
Punctuation marks
`sign'
signs such as percent (`%')
`math'
Mathematical symbols
`litdigit'
literary digit
`undefined'
Not properly defined
The opcodes which define and use character classes are shown below.
For examples see `fr-abrege.ctb'.
`class name characters'
Define a new character class. The characters operand must be
specified as a string. A character class may not be used until it
has been defined.
`after class opcode ...'
The specified opcode is further constrained in that the matched
character sequence must be immediately preceded by a character
belonging to the specified class. If this opcode is used more than
once on the same line then the union of the characters in all the
classes is used.
`before class opcode ...'
The specified opcode is further constrained in that the matched
character sequence must be immediately followed by a character
belonging to the specified class. If this opcode is used more than
once on the same line then the union of the characters in all the
classes is used.
4.9 Swap Opcodes
================
The swap opcodes are needed to tell the `context' opcode (*note
context: context opcode.), the `correct' opcode (*note correct: correct
opcode.) and multipass opcodes which dot patterns to swap for which
characters. There are two, `swapcd' and `swapdd'. The first swaps dot
patterns for characters. The second swaps dot patterns for dot
patterns. The first is used in the `context' opcode and the second is
used in the multipass opcodes. Dot patterns are separated by commas and
may contain more than one cell.
`swapcd name characters dots, dots, dots, ...'
See above paragraph for explanation. For example:
swapcd dropped 0123456789 356,2,23,...
`swapdd name dots, dots, dots ... dotpattern1, dotpattern2, dotpattern3, ...'
The `swapdd' opcode defines substitutions for the multipass
opcodes. In the second operand the dot patterns must be single
cells, but in the third operand multi-cell dot patterns are
allowed. This is because multi-cell patterns in the second operand
would lead to ambiguities.
4.10 The Context and Multipass Opcodes
======================================
`context test action'
`pass2 test action'
`pass3 test action'
`pass4 test action'
The `context' and multipass opcodes (`pass2', `pass3' and `pass4')
provide translation capabilities beyond those of the basic
translation opcodes (*note Translation Opcodes::) discussed
previously. The multipass opcodes cause additional passes to be
made over the string to be translated. The number after the word
`pass' indicates in which pass the entry is to be applied. If no
multipass opcodes are given, only the first translation pass is
made. The `context' opcode is basically a multipass opcode for the
first pass. It differs slightly from the multipass opcodes per se.
The format of all these opcodes is:
opcode test action
The `test' and `action' operands have suboperands. Each suboperand
begins with a non-alphanumeric character and ends when another
non-alphanumeric character is encountered. The suboperands and
their initial characters are as follows.
`" (double quote)'
a string of characters. This string must be terminated by
another double quote. It may contain any characters. If a
double quote is needed within the string, it must be preceded
by a backslash (`\'). If a space is needed, it must be
represented by the escape sequence \s. This suboperand is
valid only in the test part of the `context' opcode.
`@ (at sign)'
a sequence of dot patterns. Cells are separated by hyphens as
usual. This suboperand is not valid in the test part of the
context opcode.
`$ (dollar sign)'
a string of attributes, such as `d' for digit, `l' for
letter, etc. More than one attribute can be given. If you
wish to check characters with any attribute, use the letter
`a'. Input characters are checked to see if they have at
least one of the attributes. The attribute string can be
followed by numbers specifying how many characters are to be
checked. If no numbers are given, 1 is assumed. If two
numbers separated by a hyphen are given, the input is checked
to make sure that at least the first number of characters with
the attributes are present, but no more than the second
number. If only one number is present, then exactly that many
characters must have the attributes. A period instead of the
numbers indicates an indefinite number of characters. This
suboperand is valid in all test parts but not in action parts.
`! (exclamation point)'
reverses the logical meaning of the suboperand which follows.
For example, !$d is true only if the character is _NOT_ a
digit. This suboperand is valid in test parts only.
`% (percent sign)'
the name of a class defined by the `class' opcode (*note
class: class opcode.) or the name of a swap set defined by
the swap opcodes (*note Swap Opcodes::). Names may contain
only letters and digits. The letters may be upper or
lower-case. The case matters. Class names may be used in test
parts only. Swap names are valid everywhere.
`_ (underscore)'
Move backward. If a number follows, move backward that number
of characters. The program never moves backward beyond the
beginning of the input string. This suboperand is valid only
in test parts.
`[ (left bracket)'
start replacement here. This suboperand must always be paired
with a right bracket and is valid only in test parts.
`] (right bracket)'
end replacement here. This suboperand must always be paired
with a left bracket and is valid only in test parts.
`# (number sign or crosshatch)'
test or set a variable. Variables are referred to by numbers
1 to 50, for example, `#1', `#2', `#25'. Variables may be set
by one `context' or multipass opcode and tested by another.
Thus, an operation that occurs at one place in a translation
can tell an operation that occurs later about itself. This
feature will be used in math translation, and it may also
help to alleviate the need for new opcodes. This suboperand
is valid everywhere.
Variables are set in the action part. To set a variable use an
expression like `#1=1', `#2=5', etc. Variables are also
incremented and decremented in the action part with
expressions like `#1+', `#3-', etc. These operators increment
or decrement the variable by 1.
Variables are tested in the test part with expressions like
`#1=2', `#3<4', `#5>6', etc.
`* (asterisk)'
Copy the characters or dot patterns in the input within the
replacement brackets into the output and discard anything
else that may match. This feature is used, for example, for
handling numeric subscripts in Nemeth. This suboperand is
valid only in action parts.
`? (question mark)'
Valid only in the action part. The characters to be replaced
are simply ignored. That is, they are replaced with nothing.
4.11 The correct Opcode
=======================
`correct test action'
Because some input (such as that from an OCR program) may contain
systematic errors, it is sometimes advantageous to use a
pre-translation pass to remove them. The errors and their
corrections are specified by the `correct' opcode. If there are no
`correct' opcodes in a table, the pre-translation pass is not
used. The format of the `correct' opcode is very similar to that
of the `context' opcode (*note context: context opcode.). The only
difference is that in the action part strings may be used and dot
patterns may not be used. Some examples of `correct' opcode
entries are:
correct "\\" ? Eliminate backslashes
correct "cornf" "comf" fix a common "scano"
correct "cornm" "comm"
correct "cornp" "comp"
correct "*" ? Get rid of stray asterisks
correct "|" ? ditto for vertical bars
correct "\s?" "?" drop space before question mark
4.12 Miscellaneous Opcodes
==========================
`include filename'
Read the file indicated by `filename' and incorporate or include
its entries into the table. Included files can include other files,
which can include other files, etc. For an example, see what files
are included by the entry include `en-us-g1.ctb' in the table
`en-us-g2.ctb'. If the included file is not in the same directory
as the main table, use a full pathname for filename.
`locale characters'
Not implemented, but recognized and ignored for backward
compatibility.
`display character dots'
Associates dot patterns with the characters which will be sent to a
braille embosser, display or screen font. The character must be in
the range 0-255 and the dots must specify a single cell. Here are
some examples:
display a 1 When the character a is sent to the embosser or display,
it # will produce a dot 1.
display L 123 When the character L is sent to the display or embosser
# produces dots 1-2-3.
The display opcode is optional. It is used when the embosser or
display has a different mapping of characters to dot patterns than
that given in *note Character-Definition Opcodes::. If used,
display entries must proceed character-definition entries.
`multind dots opcode opcode ...'
the multind opcode tells the back-translator that a sequence of
braille cells represents more than one braille indicator. For
example, in `en-us-g1.ctb' we have `multind 56-6 letsign capsign'.
The back-translator can generally handle single braille indicators,
but it cannot apply them when they immediately follow each other.
It recognizes the letter sign if it is followed by a letter and
takes appropriate action. It also recognizes the capital sign if
it is followed by a letter. But when there is a letter sign
followed by a capital sign it fails to recognize the letter sign
unless the sequence has been defined with `multind'. A `multind'
entry may not contain a comment because liblouis would attempt to
interpret it as an opcode.
5 Notes on Back-Translation
***************************
Back-translation is carried out by the function
`lou_backTranslateString'. Its calling sequence is described in *note
Programming with liblouis::. Tables containing no `context' opcode
(*note context: context opcode.), `correct' opcode (*note correct:
correct opcode.) or multipass opcodes can be used for both forward and
backward translation. If these opcodes are needed different tables will
be required. `lou_backTranslateString' first performs `pass4', if
present, then `pass3', then `pass2', then the backtranslation, then
corrections. Note that this is exactly the inverse of forward
translation.
Opcode Index
************
after: See 4.8. (line 1247)
always: See 4.7. (line 1051)
before: See 4.8. (line 1254)
begbold: See 4.4. (line 866)
begcaps: See 4.3. (line 702)
begcomp: See 4.4. (line 935)
begital: See 4.4. (line 816)
begmidword: See 4.7. (line 1145)
begnum: See 4.7. (line 1174)
begunder: See 4.4. (line 908)
begword: See 4.7. (line 1141)
boldsign: See 4.4. (line 851)
capsign: See 4.3. (line 696)
capsnocont: See 4.6. (line 973)
class: See 4.8. (line 1242)
comp6: See 4.7. (line 1024)
compbrl: See 4.7. (line 1012)
context: See 4.10. (line 1290)
contraction: See 4.7. (line 1119)
correct: See 4.11. (line 1403)
decpoint: See 4.5. (line 956)
digit: See 4.2. (line 625)
display: See 4.12. (line 1439)
endbold: See 4.4. (line 872)
endcaps: See 4.3. (line 708)
endcomp: See 4.4. (line 942)
endital: See 4.4. (line 822)
endnum: See 4.7. (line 1185)
endunder: See 4.4. (line 914)
endword: See 4.7. (line 1157)
firstletterbold: See 4.4. (line 866)
firstletterital: See 4.4. (line 816)
firstletterunder: See 4.4. (line 908)
firstwordbold: See 4.4. (line 845)
firstwordital: See 4.4. (line 791)
firstwordunder: See 4.4. (line 893)
hyphen: See 4.5. (line 962)
include: See 4.12. (line 1427)
italsign: See 4.4. (line 799)
joinnum: See 4.7. (line 1190)
joinword: See 4.7. (line 1101)
largesign: See 4.7. (line 1067)
lastletterbold: See 4.4. (line 872)
lastletterital: See 4.4. (line 822)
lastletterunder: See 4.4. (line 914)
lastwordboldafter: See 4.4. (line 861)
lastwordboldbefore: See 4.4. (line 851)
lastworditalafter: See 4.4. (line 809)
lastworditalbefore: See 4.4. (line 799)
lastwordunderafter: See 4.4. (line 904)
lastwordunderbefore: See 4.4. (line 897)
lenboldphrase: See 4.4. (line 882)
lenitalphrase: See 4.4. (line 832)
lenunderphrase: See 4.4. (line 924)
letsign: See 4.3. (line 714)
letter: See 4.2. (line 648)
litdigit: See 4.2. (line 665)
literal: See 4.7. (line 1012)
locale: See 4.12. (line 1435)
lowercase: See 4.2. (line 653)
lowword: See 4.7. (line 1110)
math: See 4.2. (line 680)
midendword: See 4.7. (line 1153)
midnum: See 4.7. (line 1179)
midword: See 4.7. (line 1149)
multind: See 4.12. (line 1456)
nocont: See 4.7. (line 1034)
nocross: See 4.7. (line 1091)
noletsign: See 4.3. (line 722)
noletsignafter: See 4.3. (line 739)
noletsignbefore: See 4.3. (line 731)
numsign: See 4.3. (line 747)
partword: See 4.7. (line 1161)
pass2: See 4.10. (line 1290)
pass3: See 4.10. (line 1290)
pass4: See 4.10. (line 1290)
postpunc: See 4.7. (line 1170)
prepunc: See 4.7. (line 1166)
prfword: See 4.7. (line 1137)
punctuation: See 4.2. (line 618)
repeated: See 4.7. (line 1059)
replace: See 4.7. (line 1041)
sign: See 4.2. (line 672)
singleletterbold: See 4.4. (line 878)
singleletterital: See 4.4. (line 828)
singleletterunder: See 4.4. (line 920)
space: See 4.2. (line 612)
sufword: See 4.7. (line 1133)
swapcd: See 4.9. (line 1274)
swapdd: See 4.9. (line 1279)
syllable: See 4.7. (line 1082)
undersign: See 4.4. (line 897)
uplow: See 4.2. (line 631)
uppercase: See 4.2. (line 658)
word: See 4.7. (line 1078)
Function Index
**************
lou_backTranslate: See 2.6. (line 282)
lou_backTranslateString: See 2.5. (line 260)
lou_free: See 2.12. (line 374)
lou_getTable: See 2.10. (line 348)
lou_hyphenate: See 2.7. (line 300)
lou_logFileName: See 2.8. (line 327)
lou_logPrint: See 2.9. (line 338)
lou_readCharFromFile: See 2.11. (line 361)
lou_translate: See 2.4. (line 228)
lou_translateString: See 2.3. (line 156)
lou_version: See 2.2. (line 147)
Program Index
*************
lou_allround: See 3.2. (line 404)
lou_checktable: See 3.1. (line 396)
lou_translate: See 3.3. (line 416)
Other related posts:
