This manual is for liblouisutdml (version 2.2.0, 24 February 2012), an xml to Braille Translation Library.
This file may contain code borrowed from the Linux screenreader BRLTTY, Copyright © 1999-2009 by the BRLTTY Team.
Copyright © 2004-2009 ViewPlus Technologies, Inc. www.viewplus.com and Copyright © 2006,2009 Abilitiessoft, Inc. www.abilitiessoft.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.
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 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 file2brl will produce an excellent braille file.
There is a Mac GUI application incorporating liblouisutdml called louis. For a link to it go to www.abilitiessoft.com/downloads. You can also obtain a Windows binary on this page. At present it is command-line. We hope to have a GUI soon.
Users who want to generate Braille using file2brl will be interested in Transcribing XML files with file2brl. Those who wish to change the output generated by liblouisutdml should read 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 Connecting with the xml Document. If you wish to implement a new braille mathematics code read Implementing Braille Mathematics Codes. Finally, computer programmers who wish to use liblouisutdml in their software can find the information they need in 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 (see Overview).
At the moment, actual transcription with liblouisutdml is done with the command-line (or console) program file2brl. The line to type is:
file2brl [OPTIONS] [-f config-file] [infile] [outfile]
The brackets indicate that something is optional. You will see that nothing is required except the program name itself, file2brl. The various optional parts control how the program will behave, as follows:
./
.
backFormat
in the 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 `space
\e 1b' so that it will pass through escape characters. The
html.sem file must also contain the line `pagenum
pagenum'. Text output files simply have a blank line between
paragraphs. Encoding of text files is controlled by the
outputEncoding
setting. Html files are always in UTF-8.
formatFor
configuration (see formatFor setting) file setting, which enables
you to format the braille output for viewing in a browser.
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 (`-') for the input file.
If only the program name is typed file2brl assumes that the configuration file is default.cfg, input is from the standard input unit, and output is to the standard output unit.
See the previous section on using 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.
file2brl -p infile outfile
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 -p option of 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. However, if rtf2xml (see Transcribing RTF files with rtf2brl) will convert the file, it will work with the resulting xml file.
file2brl -t infile outfile
The -t option prevents xml2blr from trying to transcribe infile as an xml document. This will produce a lot of error messages. file2brl will then try the html parser. Note that xhtml documents are actually xml.
msword2brl infile outfile
Infile must be a Microsoft Word file. The script first calls the antiword program, so you must have this installed on your machine. antiword is called with -x db, which causes the output to be in docbook format. This is piped to file2brl. The output file from file2brl contains much of the formatting, including emphasis, of the word file.
rtf2brl infile outfile
Infile must be a rich-text (rtf) file, such as Bookshare provides for
proofreading. The script first calls rtf2xml, so you must have
this program installed on your machine. You can find it on the downloads
page of www.abilitiessoft.com. It was copied from its SourceForge
project. Since it is a Python program, it can be rather slow. Its output
is piped to file2brl. The output of rtf2xml is xml
with the root element doc
. The file doc.sem is fairly
complete, so the output of file2brl contains much of the
formatting, including emphasis, of the original rtf file.
pdf2brl infile outfile
Infile must be a PDF (Portable Document Format) file. The script first calls the pdftotext program, so you must have this installed on your machine. It is part of xpdf and most likely already installed if you're on a modern Linux distribution. Otherwise, you can get it from either http://poppler.freedesktop.org or http://www.foolabs.com/xpdf/download.html. pdftotext is called with the -raw and - options, which cause it to place its output on stdout. This is piped to file2brl, which is called with the -p option, since output from pdftotext is likely to be poorly formatted. The output file from file2brl is mostly in sensible paragraphs.
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 (see 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 (see Overview). Another section of the present document which may be of interest is Implementing Braille Mathematical Codes (see 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 -C option on the file2brl command
line, by the configstring
and configtweak
semantic
actions, or by passing a string to the lbu_initialize
function.
The information below applies to 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
lbu_initialize
. This function returns a pointer to a data
structure containing the configuration information. The calling program
must include the header file louisutdml.h
. You do not need to call
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 ./
. After the path, if any, has been
evaluated, but before reading any of the files, liblouisutdml reads in a
file called 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 liblouisutdml.ini, but you should not delete any
settings. Do not specify 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
liblouisutdml.ini or any previously read configuration file.
Originally, configuration files contained four main sections,
outputFormat
, translation
, xml
and style
.
The section names, except for 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 style
are optional. In this document and in the
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 liblouisutdml.ini the distribution also sontains a number of configuration files. The most important of these is preferences.cfg, which contains all possible settings and a "default" value for each. You should use this file as a refererence. It is the file read by the file2brl command-line interface program if no configuration file is giben.
Here, then, is an explanation of each section and setting in the 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 (`#'), 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 `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.
This section specifies the format of the output file (or string).
cellsPerLine 40
linesPerPage 25
interpoint no
lineEnd \r\n
pageEnd \f
fileEnd ^z
printPages yes
braillePages yes
cellsPerLine
, but the
value of linesPerPage
will be ignored.
paragraphs yes
beginningPageNumber 1
braillePages
is yes. This is useful when producing multiple
Braille volumes.
printPageNumberAt top
pageSeparator
is set to `yes', a page separator line
will also be produced on the Braille page where the print page break
actually occurs. You may also specify `bottom' for this setting.
braillePageNumberAt bottom
interpoint yes
has been specified only odd pages
will receive page numbers. You may also specify `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.
continuePages yes
pageSeparator yes
pageSeparatorNumber yes
ignoreEmptyPages yes
pagenum
tag is immediately followed
by another pagenum
tag. By default, empty pages are completely
ignored. If you specify `no' for this setting, a sequence of
pagenum
tags will lead to a 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 continuePages
), they carry only the number of the
page on which text reappears.
printPageNumberRange no
printPageNumberRange
is set to `yes', the 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 continuePages
).
mergeUnnumberedPages yes
pageNumberTopSeparateLine yes
printPageNumberRange
)
at the top of a page is always displayed on a separate line.
pageNumberBottomSeparateLine yes
hyphenate no
literaryTextTable
setting of the translation
section.
outputEncoding ascii8
inputTextEncoding ascii8
formatFor textDevice
backFormat plain
backLineLength 70
interline no
lineFill '
This section specifies the liblouis translation tables to be used for various purposes.
literaryTextTable en-us-g2.ctb
uncontractedTable en-us-g1.ctb
compbrailleTable en-us-compbrl.ctb
mathtextTable en-us-mathtext.ctb
MathexpTable nemeth.ctb
editTable nemeth_edit.ctb
interlineBackTable en-us-interline.ctb
This section provides various information for the processing of xml files.
semanticFiles *,nemeth.sem
xmlheader <?xml version='1.0' encoding='UTF8' standalone='yes'?>
entity nbsp ^1
internetAccess yes
newEntries yes
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 document
,
para
, heading1
, heading2
, heading3
,
heading4
, contentsheader
, contents1
,
contents2
, contents3
and 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 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
braillePageNumberFormat roman
. This setting will apply to all the
styles nested within frontMatter, unless they have a setting other than
`normal', which is the default and means ordinary braille page
numbers. However, the titlePage style might have the setting
braillePageNumberFormat blank
. This will apply to all styles
nested within it. When the titlePage section ends, the frontMatter
setting `roman' will be restored. The
`braiblePageNumberFormat' 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 `document' style contains all possible settings. The others contain only settings that are different from the defaults.
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 ducument.
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.
linesAfter 0
The number of blank lines which should be left after the text to which this style applies.
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.
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.
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 `contracted', `uncontracted', `compbrl', `mathtext' and `mathexpr'.
skipNumberLines no
If this setting is `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.
format leftJustified
The format setting controls how the text in the style will be formatted. Valid values are `leftJustified', `rightJustified', `centered', `computerCoded', `alignColumnsLeft', `alignColumnsRight', and `contents'. The first three are self-explanatory. `computerCoded' is used for computer programs and similar material. The next two are used for tabular material. `alignColumnsLeft' causes the left ends of columns to be aligned. `alignColumnsRight' causes the right ends of columns to be aligned. `contents' is used only in styles specifically intended for tables of contents.
newPageBefore no
If this setting is `yes', the text will begin on a new page. This is useful for certain mathematical and graphical styles. Page numbers are handled properly.
newPageAfter no
If this setting is `yes' any remaining space on the page after the material covered by this style is handled is left blank, except for page numbers.
rightHandPage no
if this setting is `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 `no' this setting is equivalent to newPageBefore.
braillePageNumberFormat normal
This setting specifies the format of braille page numbers. `normal' means ordinary Arabic numbers. `roman' means Roman numbers. `p' means to precede Arabic numbers with the letter "p" (for preliminary). Finally, `blank' causes the page number to be blank (no page numbers). This is a "persistent" style setting.
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.
linesBefore 1
linesAfter 1
format centered
This style and the other contents styles are used for the table of contents and correspond to the four heading levels.
firstLineIndent -2
leftMargin 2
format contents
firstLineIndent -2
leftMargin 4
format contents
firstLineIndent -2
leftMargin 6
format contents
firstLineIndent -2
leftMargin 8
format contents
This style is used for main headings, such as chapter titles.
The first level of subheadings after the main heading.
firstLineIndent 4
The fourth and final level of headings.
firstLineIndent 4
Paragraph. This is ordinary body text.
firstLineIndent 2
When liblouisutdml (or 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, so called 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 (`<>'). For example, if liblouisutdml encounters
<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 <html>
, <math>
,
<book>
, <dtbook>
and <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
`new_' in front of it and adding a period plus the letters
`sem'. For example, `new_myformat.sem'. If you look in a
directory containing semantic-action files you will see names like
html.sem, dtbook.sem, 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
<article>
. However, the specification itself has the root element
<book>
. In this case you can specify the book.sem file in
the configuration file by writing, in the xml section,:
semanticFiles book.sem
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:
semanticFiles book.sem,ukmaths.sem
You can use an asterisk *
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 html.sem. A copy is included as part of this documentation with the name example_html.sem (see html.sem). 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 (`#'). 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: `include nemeth.sem'. This tells liblouisutdml to include the information in the 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:
no hr
`hr' is an element with the angle brackets removed. It means nothing in itself. However, the first column contains the word `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 `no' in the first column, we see one that says:
softreturn br
This means that when the element <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:
heading1 h1
This tells liblouisutdml that when it encounters the element <h1>
it is to format the text which follows as a first-level braille
heading, that is, the text will be centered and preceeded and followed
by blank lines. (You can change this by changing the definition of the
heading1 style).
The next line says:
italicx em
This tells liblouisutdml that when it encounters the element <em>
it is to enclose the text which follows in braille italic indicators.
The `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:
skip style
This tells liblouis to simply skip ahead until it encounters the
element </style>
. Nothing in between will have any effect on
the braille output. Note the slash (`/') before the `style'.
This means the end of whatever the <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:
italicx strong
This tells liblouis to also use the italic braille indicators for the
text between the <strong>
and </strong>
elements.
After a few more lines with `no' in the first column we come to the line:
document html
This tells liblouisutdml that everything between <html>
and
</html>
is an entire document. <html>
was the root
element of this document, so this is logical.
After another `no' line we come to:
para p
liblouisutdml will consider everything between <p>
and
</p>
to be a normal body text paragraph.
The next line is:
heading1 title
this causes the title of the document to also be treated as a braille level 1 heading.
Next we have the line:
list li
The xhtml <li>
and </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:
table table
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:
heading2 h2
This means that the text between <h2>
and </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:
no table,cellpadding
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 (<table>
and </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:
no table,border,0
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 html.sem file. This is nemeth.sem. As with html.sem, a copy is included in the appendix (see nemeth.sem), 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
generic
semantic action. They are retained for backward
compatibility.
The first line of real interest is:
math math
Every mathematical expression begins with the element <math>
(which may have attributes and values), and ends with </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 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:
mfrac mfrac ^?,/,^# mfrac mfrac,linethickness,0 ^(,^;%,^)
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 <mfrac>
indicates a fraction. A fraction has two parts,
a numerator and a denominator. In xml, we call these parts children of
<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 `~?' before the
numerator, `/' between the numerator and denominator, and
`~#' 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,
see Implementing Braille Mathematics Codes).
The second line is of even greater interest. The first column is again `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 `~(', upper number, `~%', lower number, `~)' 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 see 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.
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, see Customization Configuring liblouisutdml.
Generally the format of a semantic action is:
semanticAction elementSpecifier optionalArguments
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 a 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.
contenss1 elementSpecifier
Note that the contenss1
, etc. semantic actions are never
assigned an
actual elementSpecifier
. There used internally by the table of
contents generator. They should be assigned style settings, however.
contenss2 elementSpecifier
contenss3 elementSpecifier
contenss4 elementSpecifier
contentsheader elementSpecifier
This semantic action must be assigned an element specifier if used. See the discussion of it in the section on styles.
document elementSpecifier
heading1 elementSpecifier
heading2 elementSpecifier
heading3 elementSpecifier
heading4 elementSpecifier
para elementSpecifier
The following table expbains 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 elementSpecifier
.
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. elementSpecifier
should be an empty element, that is, of
the form <elementSpecifier/>
. If it is not, any content which it
may contain will be ignored.
boldx elementSpecifier
Enclose the text which follows in braille bold indicators. The `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.
boxline elementSpecifier character
A line consisting entirely of the character in the third column is placed in the output. If the third column is blank this semantic action does nothing. It is 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.
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 math
.
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. elementSpecifier
is in
the form element,attribute
. The document contains something like:
<span lang="en-us-g1.ctb"> This is uncontracted. </span>
The specified table remains in effect from
<element attribute="tablename">
until </element>
, no
matter what is
between the two. The previous table is then restored.
compbrl elementSpecifier
The material between elementSpecifier
and
/elementSpecifier
is translated as computer braille, if the
liblouis table in use phovides for it. Beginning and ending computer
braille indicators are inserted if they are in the table.
configfile elementSpecifier filename
The configfile
, configstring
and configtweak
semantic actions enable the configuration of liblouisutdml to be changed
according to the contents of the document being transcribed.
configfile
and configstring
take effect during the
document analysis phase performed by examine_document.c.
configtweak
is effective during the transcription phase,
performed by transcribe_document.c and the functions called in
this module.
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. filename
must be on one of the paths set in the 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.
configstring elementSpecifier setting1=value1;setting2=value2;...
Note that the setting=value
pairs are separated by semicolons.
Because the string may be longer than a screen line, you can use a
backslash `\' followed immediately by a line ending `\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 configstring
.
configtweak elementSpecifier settings
configtweak
is identical to configstring
except that it
is called in the transcription phase. It can be used for
things like changing translation tables. For example:
configtweak elementSpecifier literaryTextTable=fooTable;\ mathExprTable=barTable
configtweak
is not a generalization of changetable
. The
latter changes the active table and applies to a subtree.
configtweak
remains in effect until changed by another
configtweak
.
contracted elementSpecifier
footer elementSpecifier
This semantic action is used to specify a footer which will be placed at the bottom of each page.
<elemntSpecifier>This is a footer</elementSpecifier>
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 \*
it is
placed after the last branch, no matter how many branches there may be.
graphic elementSpecifier
When a module which can handle SVG graphics is ready this semantic action will invoke it.
htmllink elementSpecifier
This semantic action is used when the configuration file specifies
formatFor browser
. It sets up a link which the browser can
follow.
htmltarget elementSpecifier
This semantic action establishes a target for a link in the same file
when formatFor browser
is specified in the configuration file.
italicx elementSpecifier
Enclose the text which follows in braille italic indicators. The `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.
linespacing elementSpecifier digit
This semantic action specifies the numbr of blank lines to be left
between adjacent lines in the output. For example if the third column is
`1', lines will be double-spaced. `0' specifies normal
spacing. The number cannot be greater than `3'. linespacing
remains in effect until another linespacing
is encountered. It
should be assigned to an empty element.
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
generic
semantic action. They are retained for backward
compatibi2ity. Therefore, unless this is not the case or additional
information is needed, they are simlly listed.
maligngroup elementSpecifier
malignmark elementSpecifier
math elementSpecifier
Every mathematical expression begins with the element
<elementSpecifier>
math
(which may have attributes and
values), and ends with </elementSpecifier>
(/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 math
semantic action causes liblouisutdml to carry
out special interpretation actions.
menclose elementSpecifier
merror elementSpecifier
mfenced elementSpecifier
mfrac elementSpecifier
mglyph elementSpecifier
mi elementSpecifier
mlabeledtr elementSpecifier
mmultiscripts elementSpecifier
mn elementSpecifier
mo elementSpecifier
mover elementSpecifier
mpadded elementSpecifier
mphantom elementSpecifier
mprescripts elementSpecifier
mroot elementSpecifier
The MathML element mroot
is actually given the semantic action
reverse
.
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.
ms elementSpecifier
mspace elementSpecifier
This element and its attributes can be helpful for determining spacing.
msqrt elementSpecifier
mstyle elementSpecifier
This MathML element should usually have the semantic action skip
.
msub elementSpecifier
msubsup elementSpecifier
msup elementSpecifier
mtable elementSpecifier
The file liblouisutdml.ini defines the style matrix
. The
semantic-action files for math codes declare mtable
to be
matrix
. Depending on the attributes of this element, it can be
set to other styles, such as long division. The matrix
style
contains the setting format alignColumnsLeft
.
mtd elementSpecifier
This element specifies a column in a mathematical table. For the style
matrix
the third column of the entry in a semantic-action file
must contain \*|ec
. This indicates the end of the column. Other
specifications using the liblouis exactdots
feature may also be
necessary.
mtext elementSpecifier
mtr elementSpecifier
This element specifies a row in a mathematical table. The entry in a
semantic-action file must contain \*\er
in the third column for
the matrix
style, indicating the end of the row. Other things may
also need to be specified using the liblouis exactdots
feature.
Note that rows are not declared as styles nested inside the
matrix
style. This is because the table must be considered as a
whole.
munder elementSpecifier
munderover elementSpecifier
music elementSpecifier
When a module which can interpret MusicML and produce braille music notation is ready this semantic action will invoke it.
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 blankline
, it is useful for fine formatting independent of
styles.
no elementSpecifier
Originally, this semantic action was intended to be the default and to
do nothing when an 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.
none elementSpecifier
This is a MathML element.
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, ` ' or ` '.
pagenum elementSpecifier
The text between <elementSpecifier>
and </elementSpecifier>
is taken to be a print page number. If it does not begin with a digit
the string \_
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 \_
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: <elementSpecifier></elementSpecifier>
.
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 elemnt mroot
is declared with this semantic action
righthandpage elementSpecifier
If interpoint yes
has been specified in the configuration file,
and the current page is a right-hand one, the lest 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
newpage
.
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.
<elementSpecifier>liblouisutdml Manual</elementSpecifier>
semantics elementSpecifier
This is a MathML action which seems to be irrelevant to braille translation.
skip elementSpecifier
Skip ahead until encountering the element </elementSpecifier>
.
Nothing
in between will have any effect on the braille output.
softreturn elementSpecifier
elementSpecifier
should be empty, for example,
<br/>
.
uncontracted elementSpecifier
This semantic action seems superfluous and may be eliminated in the future.
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.
include filename
filename must be the name of a semantic action file. The file is
compiled as though it were part of the file containing the
include
entry. Included files may include other files.
newentries no
The second column in this entry must contain `no'. Any new entries
found in the document will be ignored. No `appended_' file will be
produced. This affects only documents processed with this
semantic-action file. The configuration setting newEntries
affects all documents.
namespaces dtb=http://www.daisy.org/z3986/2005/dtbook/
This pseudo-action is used to declare namespaces used in XPath expressions. (See following section). The format is `namespaces prefix1=url1,prefix2=url2,...'. The list of namespaces may not contain blanks.
para &xpath(h4)
This example causes any element with the name `h4' to be given the
semantic action para
, no matter what other assignments may be
made to it. In general, XPath expressions are entered in the second
column with the syntax &xpath(...)
. That is, the XPath
expression is placed within parentheses following &xpath
. It may
contain parentheses itself, as long as they match. The third column may
contain arguments, as with any line in a semantic-action file. XPath
expressions are not processed in any particular order. Care should be
taken that the node sets which they find do not overlap. If a node is in
a node set found by a particular XPath expression it will be given the
semantic-action and arguments associated with that expression. This will
not be changed subsequently.
The `&funcname(...)' notation may be used for other features, such as XPointer, in the future.
A table of contents is produced for an xml file if the file contains a
tag which has been defined with the contentsheader
semantic action (see contentsheader) and
also tags for the heading1
, heading2
, heading3
or
heading4
semantic actions (see 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
lineFill
setting (see 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 contentsheader
style (see 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 contents1
, contents2
, contents3
and
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 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 contentsheader
semantic action (see contentsheader). Its title will be whatever
is inside that tag, formatted according to the definition of the
contentsheader
style. It begins on a new page. After it is
completed the braille page number is reset to
beginningBraillePageNumber
and another new page is started. This
means that the xml tag with the 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
contentsheader
semantic action. If the file contains headers
you can obtain a table of contents by specifying contents yes
in a configuration file or -Ccontents=yes on the command line
of 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 beginningBraillePageNumber
.
The contents1
, etc. styles all have the format contents
setting. This is a variant of the leftJustified
format. It has
been necessary to change the way firstLineIndent
is handled to
accommodate multilevel lists. Up till now, if firstLineIndent
was negative, the first line would start at the real left margin,
regardless of the value of leftMargin
. Now the value of
firstLineIndent
is simply added to leftMargin
. This
means that if it is negative it is really subtracted. For example, if
leftMargin
is 4 and 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.
file2brl -b infile outfile
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 backFormat
. `ascii'
produces plain text output. The lines will generally correspond to the
lines in the original braille file. `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:
space \x001b 1b escape character
To perform the back-translation operation, file2brl uses the
liblouisutdml function lbu_backTranslateFile
.
file2brl -r infile outfile
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 braillePages yes
is specified.
If backFormat html
has been specified, print page numbers will be
reproduced in the appropriate places. Some formatting may be lost.
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.
file2brl infile outfile -CformatFor=browser
infile can be any of the file types accepted by 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
`.html'. It will actually be xhtml. The -CformatFor=browser
part of the above example specifies a configuration setting, which of
course can also be specified in a configuration file.
CDATA
SectionsA cdata
section may be given the semantic actions skip
,
no
or code
. In the first case, the data in the
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 no
.
Various methods of handling tables can be devised. One that is in current use requires the following lines in a semantic-action file:
list tr \*; generic td \*;\s
The 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 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:
noback always ;\s; 0
Your configuration files should contain lines like these:
style graphspace rightHandPage yes
In your semantic-action file you must assign a tag to this style. Note
that the semantic action graphic
will invoke code to translate
SVG graphics when this feature is developed. You can nest various styles
within the `graphspace' style, such as a caption at the beginning.
In particular, you should have another invocation of `graphspace'
at the end to skip to a new page, or the next right-hand page if you are
using interpoint.
Conventions for setting off a block of text from the rest vary. you may
wish to use the quotation
style or devise a style of your own.
Again, conventions vary. you can define your own style for this purpose
and invoke it according to the attributes of the math
tag.
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.
This is another format that is being developed using MathML 3. It is difficult in earlier versions.
liblouisutdml.ini defines two styles which can be used to format poetry, as follows:
style stanza linesBefore 1 linesAfter 1 ttyle line leftMargin 2 firstLineIndent -2
Your document might then contain the following from Samuel Taylor Coleridge's "Rime of the Ancient Mariner":
<stanza> <lino>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>
Note that when stanzas follow each other liblouisutdml will produce only one blank line between them, not two.
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:
contents yes braillePages yes
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 `volume' and assign appopriate 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.
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 lbu_files of the liblouisutdml directory and in the tables subdirectory of the liblouis distribution. First, the semantic-action 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, ukmaths.ctb and 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 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 see 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 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 exactdots
. If you look at the
file example_ukmaths.ctb you will see lines like the following:
exactdots @126 exactdots @345 exactdots @123456
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:
mfenced mfenced @126,@345 mfenced mfenced,open,{ @246,@135 mover mover ,@4-346,@12456
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 <math>
itself. Yet, it may be
necessary to place some characters after the very last element. Let us
look at the <math>
entry.
math math \eb,\*\ee
First let us discuss escape sequences starting with a backslash. These are basically the same as in liblouis. The sequence `\e' is shorthand for the escape character, which would otherwise be represented by `\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 `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 `\*'. 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:
mtd mtd \*\ec
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 `c', after the very last of them.
As a final example consider:
mtr mtr ^.^\,^(,\*^.^\,^)\er
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
`46-6-12356' and end with the dot pattern `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 `\*', signifying that the characters following it
are to be placed at the end of everything in this row. A subcolumn
starting with `\*' must be the last (or only) subcolumn.
Here this last subcolumn ends with an escape character and the letter <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, 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 nemeth.ctb. It includes two other tables, chardfs.cti and nemethdefs.cti. The first gives ordinary character definitions and is included by all the other tables. Note however, that the unbreakable space, `\x00a0', is translated by dot 9. This is used before and after the equal sign and other symbols in nemeth.ctb. The second table contains character definitions for special math symbols, most of which are Unicode characters greater than `\x00ff'. The Greek letters are here. So are symbols like the integral sign.
Most of the entries in nemeth.ctb should be familiar from other tables. The unfamiliar ones follow the comments `# Semantic pairs' and `# 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 nemeth.sem file. The pass2 opcode is discussed in the liblouis documentation (see Overview). Here are some comments on a few of the entries in nemeth.ctb.
pass2 @1456-1456 @6-1456
Replaces double start-fraction indicators with the start complex fraction indicator.
pass2 @3456-3456 @6-3456
Replaces double end-fraction indicators with the end-complex-fraction indicator.
pass2 @56[$d1-5]@5 *
Removes the subscript and baseline indicators from numeric subscripts.
pass2 @5-9 @9
Removes the baseline or multipurpose indicator before an unbreakable space generated by the translation of an equal sign, etc.
pass2 @45-3-5 @3
Replaces a superscript apostrophe with a simple prime symbol.
pass2 @9[]$d @3456
Puts a number sign before a digit preceded by a blank.
pass2 @9-0 @9
Removes a space following an unbreakable space.
We now come to the fourth and last table used for math translation, the editing table, 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 `456', in front of any lower-cell punctuation that immediately follows a mathematical expression. If this occurs inside Mathml it is handled by 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 `256'. nemeth_edit.ctb replaces the blank with the punctuation indicator.
When you look at nemeth_edit.ctb you will see that it begins with an include of chardefs.cti. Most of the entries are ordinary, but some are interesting. for example,
always "\s 0
replaces the baseline or multipurpose indicator followed by a space with just a space.
Liblouisutdml may contain code borrowed from the Linux screenreader BRLTTY, Copyright © 1999-2009 by the BRLTTY Team.
Copyright © 2004-2009 ViewPlus Technologies, Inc. www.viewplus.com.
Copyright © 2006,2009 Abilitiessoft, Inc. www.abilitiessoft.com.
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 http://www.gnu.org/licenses/.
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 (see Overview). 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 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 examine_document
looks it
over and determines whether math translation tables, etc. are needed.
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 transcribe_document
, does the actual
braille transcription. It calls transcribe_math
to handle MathML
subtrees, transcribe_chemistry
for chemical formula subtrees,
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 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
transcribe_chemistry
, are only skeletons. However, I hope that
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 www.abilitiessoft.com. This site also contains links to a mailing list and to project pages on googlecode.google.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.
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 (see Overview) 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 absolune 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 tables directory and the liblouisutdml 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 tables directory and then the 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 `./' for Unix or `.\' for Windows.
Paths are handled in the paths.c
module. This contains the
function set_paths
, which is called from readconfig.c
and
in turn calls addPath
in the paths.c
module.
char *lbu_version (void)
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.
void * lbu_initialize ( const char *configFilelist, const char *logFileName, const char *settingsString)
This function initializes the libxml2 library, processes
liblouisutdml.ini and configuration settings given in
the configuration files given in 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 settingsString
string. if the parameter
settingsString
is not 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 logfilename
is not
null
, a log file is produced on the current directory. If it is
null
any messages are printed on stderr. The function returns a
pointer to the UserData
structure. This pointer is void
and must be cast to (UserData *)
in the calling program. To
access the information in this structure you must include
louisutdml.h. This function is used by file2brl.
int lbu_translateString ( const char *configfilelist, char * inbuf, widechar *outbuf, int *outlen, unsigned int mode)
This function takes a well-formed xml expression in inbuf
and
translates it into a string of 16-bit (or 32-bit if this has been
specified in liblouis) braille characters in 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 `<?xml' an xml header is added. If it does not begin
with `<' it is assumed to be a text string and is translated
accordingly. The header is specified by the xmlHeader
line in
the configuration file. If no such line is present, a default header
specifying UTF-8 encoding is used. The mode
parameter specifies
whether you want the library to be initialized. If it is 0 everything
is reset, the liblouisutdml.ini file is processed and the
configuration file and/or string (see previous section) are processed.
If mode
is 1 liblouisutdml simply prepares to handle a new
document. For more on the mode
parameter see the next section.
Which 16-bit character in outbuf
represents which dot pattern
is indicated in the liblouis translation tables. The
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 *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.
int lbu_translateFile ( char *configfilelist, char *inputFileName, char *outputFileName, unsigned int mode)
This function accepts a well-formed xml document in
inputFilename
and produces a braille translation in
outputFilename
. As for lbu_translateString
, the
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 mode
parameter can
specify that a document is in html, not xhtml. liblouisutdml.h
contains an enumeration type with the values dontInit
and
htmlDoc
. These can be combined with an or (`|') 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
outputEncoding
line in the configuration file,
configfilelist
. The function returns 1 if the translation was
successful.
int lbu_translateTextFile ( char *configfilelist, char *inputFileName, char *outputFileName, unsigned int mode)
This function accepts a text file in inputFilename
and produces
a braille translation in outputFilename
. The input file is
assumed to be encoded in Ascii8. However, utf-8 can be specified with
the configuration setting 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 outputEncoding
line in the configuration file, configfilelist
. As for
lbu_translateString
, the mode
parameter specifies
whether complete initialization is to be done or simply initialization
for a new document.
int lbu_backTranslateFile ( char *configfilelist, char *inputFileName, char *outputFileName, unsigned int mode)
This function accepts a braille file in inputFilename
and
produces a back-translation in 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 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 outputEncoding
line in the configuration file, configfilelist
. The mode
parameter specifies whether or not the library is to be initialized
with new configuration information, as described in the section on
lbu_translateString
(see lbu_translateString).
void lbu_free (void)
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 mode
parameter of 0 on the function call using the new configuration
information. This will call the lbu_free
function automatically.
This appendix contains all the files referenced in this document. They are up-to-date at the time of writing, but the actual files used by the software may change. Besides being used for reference, they can be studied to see how things are done.
# canonical Configuration File # This file contains all possible settings, together with their # default values. # It is read automatically when liblouisutdml starts. You should use it as # a reference but never specify it as a configuration file. # There are three kinds of lines in the file. the first has a single # column beginning at the left margin. This column contains the name of # a category of settings, such as outputFormat or translation. These # lines are optional. The # second type of line contains the word style in the first column, # followed by at least one space or tab, and then a style name. The # third kind of line is indented one tab stop to set it off from the # others. It centains a setting name, at least one blank space or tab, # and the value of the setting. outputFormat cellsPerLine 40 linesPerPage 25 interpoint no lineEnd \r\n pageEnd \f fileEnd ^z printPages yes braillePages yes paragraphs yes beginningPageNumber 1 printPageNumberAt top braillePageNumberAt bottom hyphenate no outputEncoding ascii8 inputTextEncoding ascii8 backFormat plain backLineLength 70 formatFor textDevice interline no lineFill ' translation literarytextTable en-us-g2.ctb uncontractedTable en-us-g1.ctb compbrlTable en-us-compbrl.ctb mathtextTable en-us-g2.ctb mathexprTable nemeth.ctb editTable nemeth_edit.ctb interlineBackTable en-us-interline.ctb xml semanticFiles *,nemeth.sem xmlheader "<?xml version='1.0' encoding='UTF8' standalone='yes'?>" # entity nbsp ^1 internetAccess yes newEntries yes # Unlike the other categories, the style category must be followed by # the name of a style. style document linesBefore 0 linesAfter 0 leftMargin 0 firstLineIndent 0 translate contracted skipNumberLines no format leftJustified newPageBefore no newPageAfter no righthandPage no braillePageNumberFormat normal style arith style attribution format rightJustified style biblio style caption leftMargin 4 firstLineIndent 2 style code linesBefore 1 linesAfter 1 skipNumberLines yes format computerCoded style contentsheader linesBefore 1 format centered linesAfter 1 style contents1 firstLineIndent -2 leftMargin 2 format contents style contents2 firstLineIndent -2 leftMargin 4 format contents style contents3 firstLineIndent -2 leftMargin 6 format contents style contents4 firstLineIndent -2 leftMargin 8 format contents style dedication newPageBefore yes newPageAfter yes format centered style directions style dispmath leftMargin 2 style disptext leftMargin 2 firstLineIndent 2 style exercise1 leftMargin 2 firstLineIndent -2 style exercise2 leftMargin 4 firstLineIndent -2 style exercise3 leftMargin 6 firstLineIndent -2 style glossary firstLineIndent 2 style graph skipNumberLines yes style graphlabel style heading1 linesBefore 1 format centered linesAfter 1 style heading2 linesBefore 1 firstLineIndent 4 style heading3 firstLineIndent 4 style heading4 firstLineIndent 4 style index style line firstLineIndent -2 leftMargin 2 style list firstLineIndent -2 leftMargin 2 style matrix format alignColumnsLeft style music skipNumberLines yes style note style para firstLineIndent 2 style quotation linesBefore 1 linesAfter 1 style section firstLineIndent 4 style spatial style stanza linesBefore 1 linesAfter 1 style style1 style style2 style style3 style style4 style style5 style subsection firstLineIndent 4 style table linesBefore 1 linesAfter 1 style titlepage newPageAfter yes style trnote firstLineIndent 7 leftMargin 5 style volume
outputFormat cellsPerLine 32 linesPerPage 25 interpoint no braillePages no # backFormat html # hyphenate yes # interline yes translation literaryTextTable en-us-g2.ctb,corrections.ctb # literaryTextTable en-us-g2.ctb,hyph_en_US.dic # literaryTextTable no-no-g1.ctb # interlineBackTable en-us-interline.ctb compbrlTable en-us-comp8.ctb xml internetAccess no # newEntries no # semanticFiles book.sem # entity nbsp ~1
# This file was produced by liblouisutdml and is considered part of # the code. See the file copyright-notice for permissions and # restrictions. This notice also applies to any files with names # beginning with 'appended_'.  # # 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 # Library GNU General Public License for more details. # # You should have received a copy of the Library GNU General Public # License 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. # # Maintained by John J. Boyer<EMAIL_ADDRESS># Updated 6-18-08 by Mike Sivill<EMAIL_ADDRESS>include ukmaths_single_cell_defs.cti include ukmaths_unicode_defs.cti # grouping definitions are character-definition rules grouping mrow \x0001\x0002 1e,2e grouping mfrac \x0003\x0004 3e,4e grouping brackets \x0005\x0006 126,345 # Braille indicators numsign 3456 capsign 6 begcaps 6-6 endcaps 6-3 singleletterital 4 singleletterbold 4 # litdigit opcodes must be in this table, not the single-cell table. litdigit 0 245 litdigit 1 1 litdigit 2 12 litdigit 3 14 litdigit 4 145 litdigit 5 15 litdigit 6 124 litdigit 7 1245 litdigit 8 125 litdigit 9 24 # No letsign but endnum for letters a-j. endnum a 56-1 endnum b 56-12 endnum c 56-14 endnum d 56-145 endnum e 56-15 endnum f 56-124 endnum g 56-1245 endnum h 56-125 endnum i 56-24 endnum j 56-245 # Ordinary translation entries always = a-56-2356 always + a-56-235 always > a-135-a always < a-246-a always % 25-1234 always $ 256 always & 4-12346 always ~ 45-156 always ! 6-236 prepunc " 236 postpunc " 356 postpunc ' 3 always '' 36 always ''' 36-3 midnum , 3 postpunc , 6-2 always , 3 always # 35-2345 print number sign before number always ( 126 always ) 345 pass2 [{mrow]@126/@345}mrow ? pass2 @126[{mrow]/}mrow@345 ? decpoint . 2 always ... 3-3-3 hyphen - 36 postpunc . 6-256 postpunc ; 6-23 postpunc : 6-25 postpunc ? 6-236 endnum % 4-356 midnum * 4-16 repeated \s 0 repeated \x00a0 a # swap opcodes for replacement and testing. swapcd dropped<PHONE_NUMBER> 356,2,23,25,456,26,235,2356,236,35 swapdd upnum 245,1,12,14,145,15,124,1245,125,24 0,0,0,0,0,0,0,0,0,0 swapdd lownum 356,2,23,25,256,26,235,2356,236,35 0,0,0,0,0,0,0,0,0,0 # now we start doing the real work # Correction rules correct {mrow$ld1-20[}mrow] ? correct "\eb"[{mrow]/}mrow"\ee" ? context "\eb"[]$l"\ee" @56 context "\eb"[]","$l"\ee" @56 context []"@456-34"$d1-10}mfrac #1=1 # context []"@456-34"$d1-10}mfrac #1=1 context []"@346"$d1-10"@12456" #1=1 context []"@16"$d1-10"@12456" #1=1 # context []"@146"$d1-10 #1=1 context #1=1$d1-10 #1=0%dropped # exactdots opcodes for dot patterns in ukmaths.sem exactdots @126 exactdots @345 exactdots @123456 exactdots @346 exactdots @16 exactdots @23456 exactdots @34 exactdots @456-34 exactdots @12456 exactdots @146 # Function names and abbreviations word cos 1246-14 word grad 1246-1245 word cosh 1246-125-14 word sinh 1246-125-234 word tanh 1246-125-2345 word cosech 1246-125-126 word coth 1246-125-1256 word sech 1246-125-36 word log 1246-123 word sin 1246-234 word tan 1246-2345 word cosec 1246-126 word curl 1246-146 word div 1246-1456 word cot 1246-1256 word arccosh 1246-236-14 word arcsinh 1246-236-234 word arctanh 1246-236-2345 word arccosech 1246-236-126 word arccoth 1246-236-1256 word arcsech 1246-236-36 word sec 1246-36 word arccos 1246-4-14 word antilog 1246-4-123 word arcsin 1246-4-234 word arctan 1246-4-2345 word arccosec 1246-4-126 word arccot 1246-4-1256 word arcsec 1246-4-25 word colog 1246-45-123 # pass2 processing pass2 [@3456]%lownum1-10 ? pass2 [@456-34-3456]%lownum1-10 ? # pass3 processing pass3 @346%lownum1-10[@12456] ? pass3 @16[%lownum1-10]@12456 * pass3 {mfrac[@3456%upnum1-10%lownum1-10]}mfrac *
# liblouis Table for Post-Translation Editing # # Based on the Linux screenreader BRLTTY, copyright (C) 1999-2006 by # The BRLTTY Team # # Copyright (C) 2004, 2005, 2006 # ViewPlus Technologies, Inc. www.viewplus.com # and # JJB Software, Inc. www.jjb-software.com # All rights reserved # # This file is free software; you can redistribute it and/or modify it # under the terms of the Lesser or Library GNU General Public License # 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 # Library GNU General Public License for more details. # # You should have received a copy of the Library GNU General Public # License 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.


The math functions have been divided into three broad categories. The
basic math functions are always provided with XSI. The trigonometric
and extended math functions are included as part of the extended math
package.
Subtopics:
BASIC_MATH_FUNCTIONS
EXTENDED_MATH_FUNCTIONS
TRIGONOMETRIC_FUNCTIONS


Solar System Exploration
Solar System Exploration, 1950s – 1960s
Mercury
Venus
Earth (Orbit/Moon)
Mars
Jupiter
Saturn
Uranus
Neptune
Comet Haley
Observations


What really happened:
Montreal police are turning to the public for help in tracking down Eric Demers, 40, wanted in connection with an armed robbery at Montreal hospital on October 16, 2017. A hospital employee pushing a cart that had approximately $15,000 cash of hospital funds, was ambushed by two men and hospital security was held at gunpoint. Police took the second suspect 59-year-old Claude Joly into custody after he was found in possession of a loaded handgun. Eric Demers is still missing.


Public gives differing views on substitute mandatory death sentence, says former CJ
KOTA KINABALU, Nov 20 — Five Town Hall sessions of the special committee set up to study alternatives to mandatory death sentence have obtained differing feedback from the people.
Committee chairman Tan Sri Richard Malanjum, who was the former Chief Justice said the Town Hall sessions are important to obtain the views and feedback from stakeholders in the grassroots.
“The feedback received so far is very good. We will gather all opinions and analysis as recommendations which would be tabled to the cabinet by Minister in the Prime Minister’s Department, Datuk Liew Vui Leong.
“The recommendations will be prepared in January next year and are expected to be tabled to the cabinet later in March,” he said when met after the special committee Town Hall session here today.
The session was conducted by Universiti Sains Malaysia Security Department director Assoc Prof Datuk Dr. P. Sundramoorthy and among the panelists present were former Chief Judge of Malaya Tan Sri Zaharah Ibrahim and former Solicitor General II Datin Paduka Zauyah Be T. Loth Khan.
The stakeholders present at the public consultative session included members of the public, as well as ministry and department officers and non-governmental organisations.
Richard said the proposed replacement for mandatory death sentence involved eleven sections.
According to him, the views and feedback received at the five Town Hall sessions are mixed with some agreeing and some disagreeing.
Some even want the death sentence to be abolished, he said.
He said there are two more Town Hall sessions after this in Kuching, Sarawak next week and before that, a session with members of the Parliament.
The Office of Legal Affairs under the Prime Minister’s Department has become the secretariat of the Town Hall sessions. — Bernama


We are sad to see you go. All information on user {{username}} will be deleted and can't be recovered after proceeding. Please enter your username.


{% extends "flatpages/foundation.html" %} {% block title %}Thanks for your support!{% endblock %} {% block content %}
Copy and paste the source below each image to link to our donation page.
126x54 I donated to Django (green)
126x54 I donated to Django (grey)


---
layout: organizers
---
The London Django Meetup Group
June 14th 2016
Announcements
Django v1.10 is coming!
DjangoCon US 17-22 July
Sponsorship
- Tonight's meetup is kindly sponsored by Me (Anand)!
- We're looking for more sponsors
Today's Schedule
Talks
- How Django knows who you are
Stephanos Papanikolopoulos
- The ORM: Don't ask the DB
Anthony 'cybo' King
- How (and how not) to scale with Django
Malcolm Box
Today's Schedule
Eating and Drinking
- Until 9pm - Drinks at The Space Bar
- 9pm - close: Room at the Red Lion Pub (opposite), bar menu available


Exact 1 year before today, BBLog was released in the first working developer version.
That means, BBLog B-Day is today.
For that reason i started a little lottery game where you can win a DLC of your choice for Battlefield 3.
This DLC is sponsored by BBLog directly (by me).
What you need to do for it?
Not that much.
1. First, you must make sure that you have a Battlelog Account and a BBLog Account (on getbblog.com).
2. Than you must connect your Battlelog Account with your BBLog Account (My Account -> Settings -> Click on "Connect with Battlelog") - You must have BBLog installed and activated that this will work.
3. At last, write here in this thread why Better Battlelog is awesome :-) If you write multiple posts with one user, it doesn't increase your chance to win.
At the end, 16.01.2013, i choose a random winner within all the comments here in this post.
Team Member's cannot win that DLC. This thread must have a minimum of 250 Posts, under this line the price goto nobody.
arfnbarfl3000
Better Battlelog is awesome because you can edit EVERYTHING in the Battlelog. Before BBL was built up the old Battlelog looked shitty and oldschool. It was not as attractive. But most i like the background changing option and the new assignments because it gives new style to your Battlelog and the assignments make you want to achieve something in Battlefield3 when you made it all the way through the game.
 I specially like theme and background switching thing nice way to have custom backgrounds. One thing that i like are the radars. BATTLELOG IS SIMPLY AWESOME!
vpieter
BBlog is awesome because of the easily accessible weapon data and server filtersets.
It does a lot more, but even just these 2 things save a lot of time.
WolfskinLux
thank you for exist, BBlog :)
CptChaosNL
BBLog makes a (digital) soldier's life so much easier. :) And it has a great community I think, which creates lots of cool stuff (plugins) for BBLog! :)
ezek1el3000
With BetterBattlelog i can enjoy the Battlelog experience even more. The look and feel just how i want it to be. Thank you for this great application.
manuel2
Customizable appearance, extra shortcuts, extra stats all around and all customizable! Did i mention customizations?
MacMillanDAN
I really like BBlog because it's the way Blog is supposed to be.With themes,more info about players,server info,weapon and players stats.One of the best things for me are those awesome themes,because after a year of playing you get kinda bored with the standard theme that Blog has and thank god you have BBlog that has such good themes.I truly love them!Another badass thing about BBlog is that it's radar option.You can't believe how many times this has helped me.(I have used the radar at some player that where cheating,at some players that where to damn good and I couldn't compete with them so I would never join a server with those players.If used the radar at some server to because of the bad admins that sit and spawn kill the other team and kicked everyone that they don't like.This could be one of the best things to.)
Guys keep up the good job!!!And thanks for everything.
(P.S It would be awesome if I could win an expansion.I think I would get the B2K one.These maps are one of the best.And I'm kinda sick of all those vanilla maps so it would be really great!!!)
NoName-SANGRAL
Hi, bBlog is an extension to the well Battlelog, I would say the best, there are many options intéressentes as add missions in the game have comparisons weapons, put images in our sections. I thank the whole team for the work they provide us
KALOUSH37
How to say to you in which point I find really extraordinary Better Battlelog? Cet Add-on completes totally Battlelog besides all the statistics, and in every update çà improves as one goes along, it is really a brilliant idea of the credit note to create!! Thank you and long life in Better Battlelog!! Hoah!!
omena
i like bblog because it adds everything i expected to have in the official battlelog, and more.
komarsoma
I love in BetterBattleLog is the weapon comparison, and very very detailed weapon informations.
Miniv3nom
BetterBattelog is amazing because we have all the time new, you think of everything, and just for that, the plugin is interesting.
Thank you very much bBlog :)
Post edited 1 x times, last by
MoHW-For-PS3
MoHW-For-PS3
I love Better- Battlelog, because it has nawesome features like more Buttons in the Stats, the stats himself are also anwesome, because you connected it with BF3Stats.com! I also like the function to ulpoad images in the clan! And that all Link that have been Postet i directli can click on! IT's a must have this Add-On! Thank you very much for it! And the best is: It's free!!!!
~MoHW_For_Ps3
Post edited 3 x times, last by
ORFK
Global Moderator
Gab
Mir gefällts super weil ich liebe statistikem um sie mit freunden zu vergleichen.
I like it very much because I love statistics to compare them with friends.
-edit- ORFK: translated
-edit- Meaurk: Reactions only in English!
Post edited 1 x times, last by
ALL-RIGHTZ01
ALL-RIGHTZ01
Hi guys,
i think better battlelog is awesome because everything you can imagine you can find there. Even stats like how many kills i did this day or that day or charts where the KPM or the SPM are listed can be found.I also love the inplementation into original Dice/EA Battlelog. All the other things i also like about this tiny browser app were mentioned before. Thanks for reading.
Notilix
BLog is so beautiful with skins ! ^^
It is awesome !!
I love it, because now, i can have a signature at forum, join a favourite server quickly, change of color and I like the stats detailed !!!!!!!!!!!!!!!!!!!!!
It's a very good job !!!
jungerFuchs
With betterbattlelog I can see more details! It is so amazing!
M1NdFre4k
For me bblog is awesome because now i have all the stuff that premium members have and even more, the info the details, theme changer that i love so much, just want to thank you guys 4 all the hard work you have put into making such an epic bblog ^-^
Tallmios
BBlog is awesome, because I can customize the web I spend a lot of time on to my liking. For example change it to the old layout, that is centered, not this "left side" cräp. I love the custom plugins, backgrounds, additional stats. Can't imagine Battlelog without it.
younGviLA
BBLOG Hands DOWN! And I will say this with honesty, the only competition I see BetterBattlelog facing are themselves. I really can't remember what my stock-Battlelog looked like, but I probably wouldn't play this game anymore without you guys. I'm more social on here than Facebook haha. But really though, props to the team!
JDRexXx
Why BBlog is awesome? Because it makes Batterlog cooler and gives you extra options like custom assignments. That's why
RicoSchulz
It is so awesome,because you have the possibility to work with the developers every day for a better experience
for all users of this fantastic socialsystem for Battlefieldgamers ,that is better then Facebook,Really.!!!!!,you can create own plugins, own backgrounds and can report all about bugs and errors directly to the developers and not to a Mailboxsystem on the fidji isles.
So Please-Stay as you are, to be independent, hard working, individually and you will be successful for a long time.!!!
Greetings from Germany,Rico Schulz aka Bub3812
Post edited 1 x times, last by
TheAnnapolisGuy
TheAnnapolisGuy
Quite a neat little add-on!
lightsword
Bblog is totally community driven and independently developed to allow us to understand all the various minute of our weapons and performance. It is a fantastic testing tool and guide for loadouts.
Santamust
BBlog is awesome because you can change your own battlelog however you want and get easier information about weapons and so. and BBlog have helped battlelog to be so much better, keep up this good work!
T3RRORTOAST
Community Manager
Better Battlelog, the "better" says it all
SkSnsk
Better Battlelog is awesome for many reasons, primarily because it gives more information about the weapon (information, statistics). And of course the assignments, in the drafting of which takes an involved community. And good support and attention of developers to users!  Speaking of servers the ability to create custom filters for the server browser is great but then to add to that the BBL-plugin that filters out the map list just makes it that much better.
The weapons pages that shows the recoil and plots the spread and adjust the results based on the attachments is great too.
Allow people to create plugins for BBL to make BBL even better than it already is is great too. It's because of that you have some of the great plugins that I use; DICE Friends, Cheat-o-meter (suggested by me, made by Pun1a), Smart Server Browser (mentioned before), and others.
Rearranging the awards is also nice and I think that EA/DICE took what BBL had done and added it to Battlelog, the linking of the medals and ribbons so you can easily tell which goes with which. Nice that EA/DICE didn't credit BBL for the idea but such is life.