[liblouis-liblouisxml] Re: prototype code
- From: Michael Gray <mgray@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Wed, 16 Aug 2017 22:56:24 +0000
Is the target still embedded systems? If so, what kind of embedded
system?
The target is for Braille editing applications. While working with
BrailleBlaster, there seems a need for the input to be more flexible and
configurable, e.g. turning on and off certain modes like numeric passages and
capitalization processing so they could be overridden. There really should not
be any problems building for embedded systems as LibLouisAPH compiles in
standard C11.
Is the plan to eventually replace liblouis or is this only intended
for applications like BrailleBlaster?
As of now it is intended for applications like BrailleBlaster. It started out
as just test code for certain concepts I had been thinnking about for a long
while and was never going to release it. It came down to the fact the the
changes needed to resolve some of the issues of UEB were so much that it was
easier to refactor it from scratch than to overhaul LibLouis.
Ok, what are the shortcomings of the old API and how are these solved
in by the new API?
Because Braille editors like BrailleBlaster usually sees its input as some type
of markup language like XML, the new API (streaming control characters) better
matches this in the sense of inlining. This now allows for unlimited emphasis
definitions (they are modes now) whereas LibLouis's typeform buffer is limited
to its number of bits (which I ran out of). This also allows for unlimited
number of processing controls. For example, there is a `nocapital` control
that allows users to stop and start all capital processing in mid translation,
in case the want to do there own capitalization. Also there are controls for
numeric passage and nocontraction passage which UEB needed. Ironically, the
new API is a throwback to how the old TTYs used to work!
The API is still kind of monolithic/old-fashioned... I would prefer
that the translation options be placed in a single options structure,
which can then be used to initialize a translation engine which is
used in the translation-call (this implies that several different
translation engines could be active at any time).
It seems that you are swapping out the idea of translation tables with
translation engines. But I am considering something equivalent, thanks to the
fact that Spanish numeric mode is fundamentally different than UEB numeric
mode, and I hear the German capitalization worse(!?) than UEB.
What are the issues with the current translation process and how does
the new translation process solve these? Also, a somewhat formal
description of at least the new process would be _very_ nice!
The main limitation is that the current translation process tries to do most
everything in a few passes. Also there is not really any concept of mode; UEB
has along with grade 1 mode and numeric mode, shape mode and arrow mode. The
new process is still technically in development, thanks to the issues mentioned
above. The process itself might become something that is configurable in the
future. Because UEB translation is so complicated, it makes any process that
does it complicated as well. So all I will say for now is that the processes
for forward and backward translation works on the pipeline concept. See
translate_generic_forward() at the bottom of
https://github.com/MikeGray-APH/LibLouisAPH/blob/master/source/language/generic-forward.c
and translate_generic_backward() at the bottom of
https://github.com/MikeGray-APH/LibLouisAPH/blob/master/source/language/generic-backward.c.
Noticed that these are compile-time options only, i.e. macros? Do you
have a rationale for not using callbacks? The added overhead of
indirection is usually negligible compared to the cost of the memory
management code and would provide a lot more flexibility.
Callbacks will make things more complicated than they need to be, while not
really adding any useful new functionality, as macros work just fine. The main
purpose for the memory management functions is for debugging (see
https://github.com/MikeGray-APH/LibLouisAPH/blob/master/debug/memory.c and ;
https://github.com/MikeGray-APH/LibLouisAPH/blob/master/debug/memory.pl). For
release builds, they are not needed. All LibLouisAPH tests pass valgrind
--leak-check=full. Checking for memory leaks is nearly impossible when all
memory usage is done in a giant block of data. I should say that for
minimizing memory usage, I use special caching code if it becomes necessary. I
find that object caching works faster and uses less memory.
This sounds really sweet in my ears, but then I'm a fan of minimal and
complete interfaces in general... However, this also means that old
tables need to be converted, preferably there should be a mapping
between the old opcodes and the new ones (automatic conversion would
be great!).
The rules and filters in LibLouisAPH are really just an abstraction of the
translation opcodes in LibLouis. I do have a Perl conversion script which can
make the conversions for those opcodes, and I have done it for the EBAE tables.
The only difficulty is converting the emphases to modes, and the pass,
correct, and context opcodes; so there is still some manual stuff needed, and
it at best can only work as well as it did in LibLouis.. The converted EBAE
tables pass the tests almost as well as LibLouis.
There are several other changes under the hood which I did not get to in my
original email. For example, table handling is more controlled and defined,
allowing for controlled overriding of rules when specifying multiple tables.
All individual table files are compiled once no matter how they are used later.
Another example is that the no_translate bit functionality is gone, unknown
characters simply fall through. So Unicode Braille characters (that are not
referred to by any rules) can be put in the input instead (Unicode Braille is
the default output). This also eliminated the need for explicit character
definitions. There are more differences but I don't want to go too far down
the road for now.
MRG
www.aph.org
For a description of the software, to download it and links to
project pages go to
http://liblouis.org
Other related posts:
