Hi Susan,
Please, forgive me for taking a rather practical approach to the subject
(smile).
It is true that we can't very well decide the formatting of an original
document from a Braille transcription. Nor can we control the formatting of
a document that we write in Braille and then back-translate, either on the
fly or later as one file. On a computer with a screen reader, formatting is
usually done by the native commands of the word processing program. A
Braille note-taker in text mode (as opposed to Braille mode) will usually
also have its set of commands for formatting. It will translate and
back-translate the text, either one word at a time or one line at a time and
take care of the formatting separately. Although this may have some
disadvantages, it is probably the best we can do with Braille as it is, and
it seems to work ok for practical purposes.
It is also true that many Braille systems have lots of ambiguities built
into them. In Danish 6 dots, for instance, you drop all "unnecessary"
capsigns. So, when writing Braille for back-translation, you will have to
mark all the capitals that you would normally skip. You will even have to
make an occasional extra letsign in places where you normally wouldn't. In
my experience, people are fine with these requirements. I have actually made
an extra 6 dots table to remove these "unnecessary" capsigns and make
"normal" none-back-translatable Braille. For the same reason, we use
contracted 8 dots Braille a lot in Denmark, much to the amusement of the
rest of the world.
As I see it, there are two disadvantages to using back-translation to check
the result of the translation:
1. An incorrect forward translation may very well still lead to a correct
back-translation.
2. Any detected errors may likely be with the back-translation itself and
not the forward translation.
Also, I am afraid I don't quite see your point about only using computer
Braille for text messages and not being able to use capital letters. I don't
think we (the Braille users) would want to be restrained in the use of a
thing like caps for something that could easily be perceived as "mere
technical reasons". A text without caps could easily make the author appear
more helpless than necessary, which is something most blind people don't
want to.
My point is to say that there is plenty to gain by making good
back-translation, even if it can't be perfect. People who use contracted
Braille anyway will also want to write contracted Braille if at all
possible, even if they have to make an extra effort while writing. I didn't
at all mean to discourage the work on back-translation with my previous
mail. I just meant to point out some of the challenges, which I think can be
solved with most Braille systems.
Best regards Bue
-----Oprindelig meddelelse-----
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] På vegne af Susan Jolly
Sendt: 24. juli 2015 20:51
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Braille Backtranslation
I've changed the title since I want to call attention to Bue's latest post
which gives an excellent explanation of why accurate braille backtranslation
is intrinsically difficult. There've been good discussions of
backtranslation earlier on this list but perhaps it is time for some
repetition.
Braille systems are designed to make braille transcriptions of print
documents as informative as possible while also being efficiently and
enjoyably human readable. The design focus is primarily on reading, not on
writing an equivalent to print.
As anyone familiar with a comprehensive document markup language such as
RTF, LaTeX, or XHTML+CSS, is well-aware, their source files are neither easy
to generate manually nor enjoyably readable. That's one reason for the
popularity of lightweight markup languages like Markdown which support only
a small subset of a comprehensive markup language.
One way braille systems attempt to be enjoyably readable is to use markup
only for inline formatting while using whitespace rendering for layout
formatting. Moreover, inline formatting in braille is generally restricted
to formatting that supplies semantic information. This means that most
braille systems are not designed to provide a facsimile representation of an
arbitrary print document.
Much of the concern on this list is with backtranslation of text, not of
formatting. Obviously the only ways a writing system restricted to 63
characters can represent more than 63 characters is through the use of
multi-cell characters and/or of semantic indicators which change the
interpretation of affected cells.
My opinion is that when implementing backtranslation it is important to
consider the purpose since the approach depends on the purpose and the
intended user community. One question is the trade-off between developing a
highly accurate backtranslator for a single braille system and reasonably
accurate ones for multiple braille systems. After all, the
context-dependence and ambiguity that can enhance human readability often
make backtranslation difficult.
One possible purpose is as a way of checking automated forward translation
by comparison with the print source document. This is more easily done if
the translation includes additional information in the braille file as
liblouisudtml does. My dotless or extended braille has the same purpose.
(Extended braille uses a unique character code for each semantically
distinct use of a braille cell rather than just for each braille cell.)
Another purpose is writing for oneself. One facile braille user I know likes
to use his braille display for writing while traveling. He's gotten used to
the quirks of its built-in EBAE backtranslator.
Another purpose is texting. I've seen posts on various braille lists that
suggest that some braille users like to use their braille displays for
texting from their smart phones. In this situation it seems to me that a
simple computer braille transliteration would be adequate. After all, many
sighted persons ignore capital letters when texting or even writing emails.
Another purpose is real-time backtranslation when directly entering braille.
This can either be spoken or displayed on what's sometimes called the "green
line" in commercial braille software. However, as Michael W. reminds us,
it's hard to know what to do when the context-dependent nature of a braille
system means the correct interpretation of a braille cell can't always be
known at the moment it is typed. I don't have a good solution to this issue
but my guess is that different users would have different preferences. I
will, however, point out that it might be useful to find out how T-9
predictive text or a "check spelling as you type" option in a word processor
is implemented.
Finally, a brief comparison of UEB with EBAE. UEB is supposedly easier to
backtranslate but it achieves this in part by a much more cumbersome use of
indicators. Moreover it avoids certain braille errors possible in EBAE
simply by declaring them not to be braille errors. However this change can
negatively impact print produced by backtranslation. For example, UEB
doesn't use the lettersign before the letter "a" when it is meant as a
letter rather than a word even though print typically makes an analogous
distinction for all letters.
Best wishes,
SusanJ
P.S. Here's evidence of the difficulty of backtranslating EBAE. Duxbury has
just announced that the latest version of DBT can convert EBAE (or what DBT
calls "pre-UEB") braille files to UEB. It works by backtranslation followed
by forward translation. Here's the key instruction. "After file import [of
a pre-UEB brf file], you will have an inkprint file (*.dxp) which has some
errors (formatting and translation). Locate the errors and fix them."
http://www.duxburysystems.com/v113_inst.asp?section=new
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
