[liblouis-liblouisxml] Re: digit vs. litdigit

  • From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Mon, 3 Dec 2012 21:24:36 -0600

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

Other related posts: