[brailleblaster] Re: Thoughts on backtranslating braille to print
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 24 Jan 2014 18:57:38 +0000
Thanks Susan.
For now the plan is that users of BrailleBlaster can enter such things as
transcriber's notes in either text or Braille. I am sure the back-translation
is going to occaisionally be wrong but it is a simple thing to just correct it
on the text view when that happens. We do use back translation on a couple of
our devices and, yes, there are errors, but not often and we are trying to
make it better at least for English.
Implementing this should actually make the process of finding and fixing errors
easier. Many of the errors in the LibLouis tables we've found have really been
because whoever wrote the rules just wasn't thinking in terms of round-trip
translation and I guess it was never caught.
I'm sure there are a few ambiguities that are difficult to deal with and I'm
sure you know those better than I do. Hopefully we can eventually make a
translator that is smart enough to even figure those out.
Keith
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Susan Jolly
Sent: Friday, January 24, 2014 1:49 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Thoughts on backtranslating braille to print
As some of you know, I spent quite a few years working to develop accurate
backtranslators for EBAE and for Nemeth. Automating accurate interpretion of
braille is a difficult problem because all of the braille systems I am familiar
with have context-sensitive grammars and usually at least a few ambiguities as
well. Human braille readers are able to use common sense to resolve ambiguites
such as the EBAE translation of the word "bumblebee."
Humans are also aware of the implicit scoping rules for indicators.
If all one is interested in is a so-called roundtrip, that is, print to braille
and back to print, there are various strategies for retaining the necessary
information. BrailleBlaster uses LiblouisUTDML for this purpose.
MegaDots retains what it calls hints in order to provide an accurate roundtrip
for EBAE. I use my extended braille or what I sometimes call Dotless braille.
However, if one needs accurate backtranslation of braille which has been either
directly entered or for which there is no associated roundtrip information,
this requires the use of appropriate algorithms such as parsing based on the
grammar of the particular braille system. I've never been able to think of any
general method for backtranslating braille without a grammar. It may be that
it is possible to automate the development of a grammar from a translation
table but I haven't tried to do this.
I know that backtranslation software for certain braille systems is built into
braille displays. However, as far as I know, none of these apps have the
sophistication necessary for the accurate backtranslation of textbooks and
other complex documents that brailleblaster is intended to handle.
Based on my experience, I would consider the development of an accurate
backtranslation capability as a separate or follow-on project. I would also
revisit alternatives to the immediate need for this capability. For example, I
don't understand why transcribers can't enter transcriber notes in print.
After all, EPUB already has information, such as the contents of alt tags, that
is intended for a certain audience.
I'm glad to answer any questions about this issue.
Best wishes,
Susan Jolly
Other related posts:
