This file describes the TODO items for the liblouis project.  	-*- org -*-

When a task is done and accepted, consider moving it into the NEWS

file, with a bit of extra info.

* 2.6

** Document the changes to LOUIS_TABLEPATH

** Extend and document the scripting language

http://www.freelists.org/post/liblouis-liblouisxml/Very-preliminary-documentation-of-scripting-language

* near term

** (google issue 9) bindings should provide variable to pick up table location at runtime.

** Fix the problem that LOUIS_TABLEPATH always looks in the standard PATH

even if that was not in the environment var

** fix bug described by squash_space.c

** Esperanto table should not be blacklisted, work out whats wrong and make sure it is usable.

* unallocated

** (google issue 16) infinite loop in lou_backtranslate.

** (google issue 6) italword opcode not documented

** (google issue 4) problem with contraction cursor position and compBrlAtCursor.

** Add java bindings

It would be nice to have some canonical java bindings. There are

several potential candidates:

- Bindings by Michael Whapples

- Minimal jna bindings by SBS

- port jni bindings from utdml

- new jna bindings by Bert Frees

** Enhance the API to handle pre-hyphenated text

This basically just means to port the code which is in the java

bindings to C so that it can be used from other bindings

** Add readline support to all the tools

** Use portable malloc from gnulib 

to get rid of the windows #ifdefs

** Enhance translation table compiler to issue warnings

[jb]: It should be an error to define the same single-cell dot pattern

for two different characters. I am considering issuing an error

message and rejecting the table if this happens.

[mh]: It would also be very helpful if we could issue a warning when a

character has been defined as two or more braille representations.

Could we have these as warnings, not errors please.

** followup to above enhancement, either at the terminal or when called by 

bindings, we should be able to give more useful feedback, i.e. could

not translate because table not found, or table found but has errors,

or characters undefined, etc. also see:

http://www.nvda-project.org/ticket/2448

** Optimize for use with large tables

When used with dictionary based tables liblouis is very slow. The

issue is probably that the hash key is not very well suited for this

use case and there will be tons of collisions, making the lookup

essentially linear.

There was a discussion about this on the mailing list

(http://www.freelists.org/post/liblouis-liblouisxml/Improved-hash-function-for-tables).

** apply the the patch by Igor B. Poretsky

** apply the jptest_patch