You may want to look at the ruby bindings. Those do use swig to create the bindings but swig can be used to generate java bindings as well.
Michael Whapples On 06/12/10 03:48, qubit wrote:
This is for JohnB or anyone else who wants to comment -- first, before I dig deeper into itex2MML, I went and got the latest version. John, is there a licensing reason you are looking at the older version, or was that just a convenient evaluation copy on your system? Anyway, I am now working from 1.4.5 Second, there are functions that will work easily for JNI or even JNA, but there is a main program that collects all kinds of options and sets global variables before translating the text. This is a C++ file -- I don't know if the rest of it is compiled as C or C++. Anyway, itex2MML is written to be a command line filter, not something loaded and kept resident. It isn't hard to reinitialize the globals each time brailleblaster calls the library, but I am wondering if in addition, brailleblaster would have any need to change these options. In particular, should I create library methods to mimick main() processing any of the same command line options? Brailleblaster wouldn't even need to change the option names, just pass them as an argument. Finally, if I'm going to hack apart the main program to make a reasonable interface to brailleblaster, wouldn't there be an easier approach of just running itex2MML unchanged as a separate process and have java feed it the right arguments and then collect the output stream? In short, should we hack into brailleblaster to link with a library, or just keep it pure java and run the filter to translate to MML? Little or no maintenance required to upgrade to new versions of itex2MML. This would slow the translation down, of course, but it would mean one less JNI. Am I barking up the wrong tree? Decisions. --le