compileTranslationTable.c defines 0xffff as a space character. It contains all dots, real and virtual. A table cannot redefine it. John On Wed, Mar 12, 2014 at 11:43:02AM +0000, Michael Whapples wrote: > I might have found the place in the liblouis code which causes this. I > could try a fix, but as you said using such a value in itself is a bit > of a hack and the fix will thus be a bit of a hack (basically if that > character is used for something else then it might be wrongly handled by > such a fix). > > Michael Whapples > On 12/03/2014 11:38, Keith Creasy wrote: > >Michael. > > > >Great work finding the problem. > > > >Using 0xff to demark segments seems like a hack really. For one thing it > >assumes I suppose that that value isn't used for something else. > > > >The problem is the need to translate in context but keep the Braille > >associated with the correct text node. At the moment I can't think of a > >fool-proof way of doing that without such a delimiter. > > > >Maybe John can do something that prevents LibLouis from stripping the > >delimiter. > > > >-----Original Message----- > >From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx > >[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Michael > >Whapples > >Sent: Wednesday, March 12, 2014 7:22 AM > >To: liblouis-liblouisxml@xxxxxxxxxxxxx; brailleblaster@xxxxxxxxxxxxx > >Subject: [liblouis-liblouisxml] LibLouis bug with largesign > > > >Hello, > >In tracking down the bug where liblouisutdml is putting the wrong Braille > >content in brl nodes, I have now worked out the actual code which is > >causing this issue. > > > >Basically what seems to be the problem is that LibLouisUTDML processes a > >paragraph by adding each text segment of the paragraph into a single > >buffer, separating the segment with \xffff characters. Once the buffer > >contains the full paragraph text it translates it in one go, and then > >splits the text into the segments by searching for \xffff. > > > >The problem is that if one has text which gets processed by a largesign > >optcode rule either side of the \xffff end segment separator (eg. "and > >\xffffthe") then liblouis will remove the \xffff from between the > >largesign translations. Thus now when liblouisutdml takes the translation > >and splits it into segments for inserting into the appropriate brl nodes > >it will miss one of the split points. > > > >Could someone point me at the code in liblouis which strips the characters > >between largesign words. Then I could make a fix fairly quickly. > > > >I guess a longer term question I want to raise is whether this way of > >processing paragraphs is really a good plan? > > > >Michael Whapples > >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 > > 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