Hi Peter, Have a look at chardefs.cti and en-us-g1.ctb That will show you how digit and litdigit should be used. The order in which character-definition opcodes are placed makes no diference. The back-translation problems are most likely due to the fact that not much consideration was given to back-translation when the tables were made. John On Mon, Dec 03, 2012 at 03:05:37PM -0800, Peter Lundblad wrote: > Hi John, > > That is the difference between digit and litdigt that I suspected > (although the description of digit in the manual doesn't actually > mention computer braille). > > What I am seeing is the following, with the Swedish grade 1 table > (Se-Se-g1.utb) > > 1. If the table is used as-is, translating: > Test 123. > yields > _test #abc. > and back again yields: > T5st 123. > > As you can see, forward translation works fine, but back translation > confuses the dots for the e for a five. That's because there are > digit ... > lines in the table (before the definitions for the latin letters). It seems > like\ > the digit lines get used in literary braille (because they cause the nubmer > sign to be > output). > > My first attempt to fix this is to replace the digit lines with litdigit. > Translating Test 123. now gives: > _test abc. > Missing number sign, despite litidigts being defined. > Backtranslation is correct: > Test abc. > (For the input). > Doing just a back translation of what would have been the correct output from > forward translation: > _test #abc. > correctly becomes > Test 123. > > What works, and what seems to be used for some other tables, is to > replace digits6Dots.uti with digits8Dots.uti and then add > the litdigit opcodes for the six dot digits. > > So it seems to me like both digit and litdigit is required to make nubmers > work properly in literary braille, even if the literary braille table > doesn't provide any other computer braille opcodes. > I don't know if that behaviour is intentional. > > I could send a patch to fix the Swedish table if you think this fix is > correct. IN addition, as I said in my previous mail, it looks like many other > tables have the same bug, it looks like including include digits6Dots.uti > doesn't have the effect that the authors intended. > I don't know the braille of all those languages, but having conflicting > letters and digits in back translation doesn't seem right to me. > So, should we attempt to fix this globally instead of a one-off for the > Swedish table? > > Thanks, > //Peter > > > > John J. Boyer writes: > > The digit and litdigit opcodes are explained in the liblouis > > documentation. digit gives the dot pattern to be used in cimputer > > Braille. litdigit gives the dot pattern to be used in literary Braille. > > > > John > > > > > > On Sun, Dec 02, 2012 at 11:02:38PM +0100, Mesar Hameed > > wrote: > > > Hi John B, > > > > > > I would also be grateful for a clarification on this issue. > > > Unfortunately I personally don't have any time to investigate this > > > anytime soon. > > > > > > Thanks, > > > Mesar > > > On Tue 27/11/12,14:30, Peter Lundblad wrote: > > > > Hi, > > > > > > > > I am looking at some grade 1 tables for back translation (using > > > > liblouis 2.5.1). > > > > I am seeing the problem that digits are confused for the first ten latin > > > > alphabet letters. This happens in a few tables, but let's use > > > > Se-Se-g1.utb as an example. > > > > > > > > Translating e.g.: > > > > Hello 123 hello. > > > > to braille works properly. Backtranslating the result (I use > > > > lou_allround) > > > > gives > > > > 85llo 123 85llo. > > > > > > > > As you can see, the letters a-j get interpreted as > > > > numbers despite not being preceded with a numsign. > > > > > > > > Now, the Swedish table includes digits6Dots.uti with lines > > > > like > > > > digit 0 245 > > > > There are no litdigit lines in this table. > > > > > > > > This is obviously not correct, and I actually wonder if most tables > > > > that include digits6Dot and also latinLetterDef6Dots.uti do so > > > > in error, since it causes this conflict. > > > > > > > > Changing to use litdigit fixes backtranslation for letters, but now > > > > there are no numsigns being output on forward translation. > > > > So it seems that we need digit lines to define the characters > > > > as digits and litdigit lines to not confuse digits and letters on > > > > back translations. I see other tables that do this, but then it seems > > > > like we ned to find 10 unused braille patterns to not conflict. > > > > I could get around this by having lines like > > > > noback digit 1 1 > > > > litdigit 1 1 > > > > ... > > > > > > > > I am not entirely sure about the interaction between digit, litdigit and > > > > other characters. Does anyone have a suggestion for how to > > > > fix backtranslation for Swedish and other tables that have this problem? > > > > (I've tested with the Polish grade 1 table, and, even if I am not > > > > familiar > > > > with Polish, it seems pretty obvious that backtranslation is broken > > > > in a similar way there as well.) > > > > > > > > Thanks, > > > > //Peter > > > > For 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 > > > > -- > > John J. Boyer; President, Chief Software Developer > > Abilitiessoft, Inc. > > http://www.abilitiessoft.com > > Madison, Wisconsin USA > > Developing software for people with disabilities > > > > For 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 -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com