True Braille Editing using BrailleBack

1. Choose library Braille from the BrailleBack settings.
2. Try to edit anything
3. Wile the output for such things as menues, lists, text views, etc. are 
displayed as Braille editing requires the user to use "computer Braille" which 
isn't truly Braille at all and is in fact not used except as a fallback on 
devices that are Braille agnostic.

We would like to see true Braille editing using BrailleBack similar to the 
Braille editing available on the Braille Plus 18, which runs Android 2.3. We 
plan to use BrailleBack with this BrailleEditor on the Braille Plus 18.

We propose providing a similar implementation of the BrailleEditor for use as a 
part of the BrailleBack Input method. We have already done some testing and 
believe it can work and provide true Braille editing, including contracted 
Braille, on any Android device that supports BrailleBack.

The principle behind the implementation is to perform the translation 
dynamically based on Braille word boundries. The basic procedure for entering 
Braille is:

1. The user enters a Braille cell on the Braille keyboard.
2. BrailleBack receives the BrailleCell input and passes it to the 
BrailleEditor.
3. The editor receives the Braille input, finds the Braille word boundaries and 
the corresponding text boundries, performs the translation, and updates the 
current text through the InputConnection. The editor, through the Braille IME, 
also updates the Braille display accordingly.

Text updates are similarly handled in the editor.

A few possible issues remain and need solutions:

1. Sometimes the text is updated as a result of actions within the application. 
and other times it is the result of actions in the IME and the Braille editor. 
In either case onUpdateExtractedText is called. It is difficult to know where 
the update originated and thus whether the BrailleEditor needs to be updated or 
if it has already been updated by being the source of the change. W have worked 
around this for now but the solution is not particularly elegant.

2. The BrailleEditor needs access to the current translation table being used 
for output. Currently the method "getCurrTranslator" only provides access tot 
he "computer braille" table used to back-translate character input to Braille 
cells.

3. One less critical issue is that bakTranslate method does not return a 
translation result and thus does not provide the position mapping needed for 
dynamic editing. We have worked around this for now by backtranslating and then 
forward translating to get the position mapping. It would be better if the 
backTranslation method also returned a translation result.
Original issue reported on code.google.com by kcre...@gmail.com on 13 Dec 2013 at 3:47
google-code-export / eyes-free

True Braille Editing using BrailleBack #339
