When I say brf does not make sense for back translation, I meant in the sense of what brf means in the configuration file. Of course back translation of a BRF makes sense to do.
To expand on why the setting formatFor brfdoes not make sense for back translation, is that the formatted nature of the BRF has little meaning to the back translation. The formatted nature heere being results of having a page size and thus number of cells per line and lines per page, these properties not affecting the back translation.
How would brf differ from textDevice for back translation?If I attempt to make sense of what works. The value textDevice (I guess browser, although I have not tested it) will lead to HTML or whatever document format is given in backFormat. With the value utd, the back translation is in UTD. So this implies formatFor affects the output, how can Braille specific formats (eg. brf) affect a back translation, which by definition is not Braille?
Michael Whapples On 29/05/2014 08:53, John J. Boyer wrote:
brf certainly makes sense for back-translation. I've gotten mesages from people who are using it. John On Thu, May 29, 2014 at 08:01:50AM +0100, Michael Whapples wrote:Thanks. So if I understand that correctly, these greater formatFor values relate to formatted formats and UTD is a way of getting it formatted? I am not sure whether BRF, PEF, etc really make sense in back translation anyway, so may be they just need to be invalid values and lbu_backTranslateString might be better to exit with an error. Michael Whapples On 29/05/2014 00:25, John J. Boyer wrote:The intention is to base all formats except textDevice and browser on UTDML. This is because in the case of volumes, for example, utd provides a first pass over the material, which is then intended to be used in determining volume size, etc. In all formats except textDevice and browser utd provides the basis for including images and different cell sizes. Do not change this code. It would result in a major rewrite. If utd is working for a given document the problem is in the conversion modules, such as utd2volumes or utd2brf . John On Wed, May 28, 2014 at 06:08:23PM +0100, Michael Whapples wrote:Hello, I have been working to correct the back translation from the java bindings of liblouisutdml. This has revealed a related bug, which probably will affect C applications using back translation in liblouisutdml. Basically the specific bug is that if one uses a value other than textDevice, browser or utd for the setting formatFor in the configuration file (IE. in my testing I used the value brf), then back translation fails, liblouisutdml seems to use the function utd_back_translate_braille_string. I have tracked the cause of this bug down to the following lines. In the file readconfig.c in function read_configuration_file at line 1424 we have: if (ud->format_for > utd || (ud->mode & louisDots)) Inside the block relating to that if statement we get: ud-format_for = utd; Can someone explain why this code is being used and what it is meant to be achieving? Michael Whapples For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.comFor a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
