[liblouis-liblouisxml] Re: translating files to braille

  • From: "Norbert Markus" <hamilfonz@xxxxxxxxx>
  • To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
  • Date: Fri, 23 Nov 2018 15:36:56 +0100

Hi Juan Pablo,

I am trying to answer your recurring question about displaying Braille output 
of liblouis conversions.

I think you guess it well that display tables are the key to correct 
representation of the Braille signs, although .dis files are not always needed 
for that.
As I can see there isn't a separate chapter in the liblouis documentation 
dedicated to display tables but the topic is covered in the sections dealing 
with opcodes. display itself is an opcode. The trick is that display opcodes 
may be gathered in a separate file and be applied at once prior to loading a 
translation table.

The character-definition opcodes (especially the single-cell ones) implicitly 
define a character representing the Braille dot combination associated to the 
specified Braille symbol.
Once a translation table is completed, it will inherently have a set of output 
characters representing the Braille cells that are the result of the 
translation. These characters will appear in the output in place of the dot 
combinations covered by the character-definition opcodes.

I don't have experience with too many translation tables, only with the en-us, 
ueb, German, Hungarian and Esperanto tables. What these have in common is they 
consistently cover the most commonly used input characters and have a default 
set of output characters compatible with one of the three main Braille 
representation standards: USA Braille, Euro Braille or Unicode Braille.
For instance, the en-us and UEB tables provide output according to the USA 
Computer Braille standard, whereas the German and Hungarian translation tables 
generate output by the Euro Braille standard.

Thus these tables produce a highly consistent output that contains only a range 
of the 64 character codes allowed by the named Braille standard, in case of 
6-dot Braille, or 256 different codes in case of 8-dot Braille. Of course, a 
translation table cannot cover all possible unicode characters but in case of 
these tables, apparently an effort has been made to cover the most frequently 
occuring ones like the letters of the alphabet, digits, punctuation and the 
most common other symbols.

A common characteristic of these translation tables is that their output will 
not contain accented letters or both upper and lower-case characters appearing 
in the same file but either upper or lower-case letters only. Characters in 
place of punctuation and digit characters may or may not match their ascii 
equivalents etc.
Once a text is processed using any of such translation tables, your screen 
reader, Braille display or Braille embosser must be set to accept material 
using the same character set.

The display tables may be used to alter the inherent, default output character 
set of the translation table being used. Since for each Braille character 
defined in a translation table, its Braille dot combination is defined by its 
character-definition opcode, a display opcode targeting that dot combination 
may be used to redefine the output character for that dot combination.
You can simply open a .dis file, these are plain text files and could be part 
of translation-tables. Each line contains a display opcode that first specifies 
the desired output character, then the Braille dot combination that is to be 
represented by the character preceding the dot combination in the definition.
In case of a six-dot paradigm, such a file contains 64 display lines covering 
all 64 dot combinations.

Thus a well defined set of display opcodes, practically put in a .dis file 
creates an extra layer on top of the translation table. For instance, if I just 
use a German table, like de-de-g1.ctb, the output will comply with the Euro 
Braille standard, that is a specific set of 64 ascii characters representing 
the 64 different Braille dot combinations.
But if my embosser is set to accept jobs in the USA Braille charset, then I 
apply the us-table.dis display table prior to the German translation table and 
then the table list will look like this:
us-table.dis,de-de-g1.ctb
Then the result will use the 64 ascii characters defined by the USA Braille 
standard.

If I use the en-us-g2.ctb translation table, it will produce output already 
according to the USA Braille character set, but if my Braille display is set to 
Euro Braille and I want to read American Grade 2 material produced by liblouis 
on the display without changing its settings, I can simply prefix the German 
6-dot display table (that is the Euro Braille charset) to the en-us-g2.ctb or 
en-ueb-g2.ctb translation table when running liblouis:
de-eurobrl6.dis,en-us-g2.ctb

A third common option is to produce output in Unicode Braille using the 
unicode.dis file.

Thus the three useful display tables are these:

us-table.dis - American 6-dot Braille character table,
de-eurobrl6.dis - Euro Braille table originating from the German 6-dot Braille 
table,
unicode.dis - Producing output using the Braille code block of the Unicode 
standard. Most up-to-date screen readers and Braille displays can cope with 
these character codes but many embossers cannot.

Now about the Spanish Braille translation tables in liblouis. First of all, I 
am not an expert of Spanish Braille. I can read and approximately pronounce 
Spanish texts written in grade 1 Braille but my poor knowledge does not extend 
to grade 2 and my Spanish does not go beyond the usual patterns used by 
tourists. So please treat anything I write here below in the light of my 
Spanish expertise. 

In the liblouis package (probably based on version 3.6), I found two main 
tables I could practically test. One is es-g1.ctb, the other is Es-Es-g1.utb. 
es-g1.ctb seems to have been created more recently (just a few years after the 
another).
Es-Es-g1.utb produces output according to the USA-Braille table. Thus if your 
screen reader/Braille display/embosser is set to Euro Braille, you may want to 
use this translation table in combination with the Euro Braille display table:
de-eurobrl6.dis,Es-Es-g1.utb

Although Es-Es-g1.utb's file extension perhaps implies the use of Unicode, but 
in my experience its output is purely 7-bit Ascii, and the other file, 
es-g1.ctb is the one whose output contains certain Unicode characters.

I used liblouisutdml for the trials (I just saved the Espana main page of the 
Spanish Wikipedia to an html file and fed liblouisutdml with it), and it seems 
as if the character definitions in es-g1.ctb weren't covering most of the 
commonly used characters, instead this table seems to deal only with special 
Braille indications. Ordinary Spanish text remains as it is, including the 
accented letters. These continue to be represented by their normal Unicode 
characters and the same applies to punctuation characters. However Unicode 
Braille capital signs are inserted before capital letters and Unicode Braille 
number signs before numerals and digit characters get converted into letters to 
suit the Braille rules.
I say "as if" because when I looked into es-g1.ctb, according to the include 
statements in there, all the latin letters, including the Spanish accented ones 
and punctuation should be handled by the table and I just don't know why this 
is not happening.
However, this is a mixed output that does not contain Braille characters only 
or by a correspondence table such as the Euro Braille or USA-Braille charsets.
Such output may be useful for individuals who are using their operating system 
set to Spanish and their screen reader/Braille display set to interpret 
ordinary Spanish text characters and besides that, their screen reader is 
prepared to handle Unicode Braille characters. But this output may be 
challenging for many embossers. Applying a display table to es-g1.ctb is also 
largely ineffective.

Perhaps trying liblouis directly without liblouisutdml would yield a different 
result but it would pose further challenges I tried to avoid. Namely, I should 
refrain from using unicode in the command line but then in what code page 
should a Spanish plain text be converted and how could I make sure the source 
text contains the right character codes. It seemed easier to use a certainly 
well-encoded HTML in UTF8 and let it through liblouisutdml.
But there may be a version problem involved. My windows build of liblouisutdml 
can only work with the last December version of Liblouis. Perhaps that liblouis 
version is no longer fully compatible with the latest Spanish tables. Thus the 
second part of this message about my experiments with Spanish Braille may not 
be relevant. Sorry for that.
But I hope the things said about the display tables above make some sense.
Best Regards, Norbert.

From: Juan Pablo Bello 
Sent: Monday, November 19, 2018 11:33 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx 
Subject: [liblouis-liblouisxml] Re: translating files to braille


wow, nice. I will be happy to translate the interface and aid with
music braille. However, to steer this back on topic, I have noticed
something that I just do not quite get, and its my main problem when
translating with liblouis.
When I create a brl or brf file and that does not interface directly
with my screen reader, I always get the wrong punctuation and symbols
for languages other than English. Does this have to do with display
tables? How are these created?
I am asking this because spanish does not appear to have a 6 dot brf
standard as English does and ... well, this presents major challenges
for forward translation. Curiously things do show up just fine when I
use NVDA though, why could this be?

2018-11-01 8:37 GMT-05:00, zvonimirek222@xxxxxxxxxx <zvonimirek222@xxxxxxxxxx>:

Hi Bhuc,
Can i translate this program to Croatian?
And, to test my translation,
Can you provide me a key?


-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> On Behalf Of Dang Hoai Phuc
Sent: Thursday, November 1, 2018 1:34 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx; Juan Pablo Bello
<juanpisjaws@xxxxxxxxx>
Subject: [liblouis-liblouisxml] Re: translating files to braille

Hi,

The Sao Mai Braille is a kind of word editor and Braille translation
software and we are more than happy to provide you the free license keys for
non-commercial use. As we are a non-profit organization and we would also
need to generate certain income to maintain and develop more features for
it. New features are added such as dealing with music notation and Braille
music translation.

Regards,

Phuc

On 31/10/2018 4:46 AM, Juan Pablo Bello wrote:
well, as for the screen reader part...
I use unicode.dis to test translations interactively in windows from
command line, so no issues there. Or I use the es-g1.ctb table in NVDA
as output and it works as expected.
The Sao Mai Braille (SMB) program sounds like just the type of program
I would pay for and even contribute into translating (if that has not
been done already) so I will fiddle with it this weekend.

2018-10-30 16:37 GMT-05:00, Samuel Thibault
<samuel.thibault@xxxxxxxxxxxx>:
Juan Pablo Bello, le mar. 30 oct. 2018 16:23:25 -0500, a ecrit:
well, not really sure of what is going on, since when I translate
files using my screen reader this does get represented correctly.
But how do you configure its braille translation exactly?

Though yes, I notice a differente using lou_trace when testing
english tables. For example, a capital C shows 1. Uppercase C 147
where as with the es-g1.ctb table it just shows 1.
Uppercase C 14
Well, es-g1.ctb is made to use 6dots only, yes. If something else is
desired then another table needs to be written.

Samuel
For a description of the software, to download it and links to
project pages go to http://liblouis.org


For a description of the software, to download it and links to project pages
go to http://liblouis.org

For a description of the software, to download it and links to
project pages go to http://liblouis.org



-- 
Juan Pablo Bello
Cel. 313-879-2884
For a description of the software, to download it and links to
project pages go to http://liblouis.org

GIF image

Other related posts:

  1. Home
  2. liblouis-liblouisxml
  3. Archive
  4. 11-2018