OK, I have filed a github issue. I didn't know that it was being used as
there is the issue system on the liblouis.org website.
Michael Whapples
On 21/04/2015 15:08, Bert Frees wrote:
Hum, we have to ask Mesar, he's the website guy, but we haven't seen him around
for more than a month.
Try filing a Github issue instead: https://github.com/liblouis/liblouis/issues.
Thanks,
Bert
Michael Whapples writes:
Hello,For a description of the software, to download it and links to
Yes, in the end I used the input positions as well for what we are doing.
As we have a work around, in a certain way may be a better solution than
using the output positions, and we have other priorities at the moment,
I cannot say whether we will be able to get to correcting this issue
anytime soon.
As it may not be dealt with immediately, I was going to enter a bug on
the liblouis website, however I had trouble logging in. I tried with my
google account, but it seems like google now use OpenID connect and
presents an error saying that OpenID 2.0 is no longer being used. The
AOL log in option just never seemed to go anywhere for me. I don't use
any of the other services so at some point I will register an account
with the other option.
Just thought it was worth letting you know that certainly the google log
in option no longer works, and may be the AOL option has issues as well.
Update of the web software may be?
Michael Whapples
On 20/04/2015 19:44, Bert Frees wrote:
Hi,For a description of the software, to download it and links to
As far as I know outputPos has been unreliable for a long while. Whenever I need
an input-output mapping I use inputPos. I never did an attempt to trace the bug
in outputPos, but I think it should be fairly easy to fix once you've found
it. Seems like you guys are on the right track.
Thanks,
Bert
Michael Whapples writes:
Yes, but that does not deal with all cases, like the multiple hyphenFor a description of the software, to download it and links to
example (eg. --- ).
The common thing seems to be whenever a pass2 rule is used output
positions is not adjusted.
I don't know that we can live without pass2 rules, or at least what the
current rules using pass2 do. If not using pass2 we would need to figure
out how to do the same thing with other opcodes.
Personally I am not sure if I like the multipass approach, but that is
what we have at the moment.
Michael Whapples
On 14/04/2015 20:18, Michael Gray wrote:
I have traced the problem to the last entry in the en-us.g1.ctb table:For a description of the software, to download it and links to
pass2 @3-56 @3
Removing this from the table will deal with the "r'S n" issue for now until I
get a chance to find a more permanent solution.
MRG
mgray@xxxxxxx
________________________________________
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] on behalf of Michael Whapples
[dmarc-noreply@xxxxxxxxxxxxx]
Sent: Tuesday, April 14, 2015 12:00 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Bug in en-us-g2.ctb
Well, the point still stands as your output positions for en-us-g2.ctb
are still wrong.
Also try a string of three hyphens:
---
This should also lead to an invalid output positions array with
en-us-g2.ctb.
The common thing I can find for both of these examples is that a pass2
opcode rule removes a Braille cell.
Michael Whapples
On 14/04/2015 15:11, Michael Gray wrote:
To clarify, I got the following with the en-us-g2.ctb table:For a description of the software, to download it and links to
r'S n
Translation:
r',s n
Output positions:
0 1 4 5 6
Input positions:
0 1 2 2 3 4
and with the en-ueb-g2.ctb table:
r'S n
Translation:
;r',s ;n
Output positions:
1 2 4 5 7
Input positions:
0 0 1 2 2 3 4 4
MRG
mgray@xxxxxxx
________________________________________
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] on behalf of Michael Whapples
[dmarc-noreply@xxxxxxxxxxxxx]
Sent: Tuesday, April 14, 2015 5:21 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Bug in en-us-g2.ctb
Further to this, I now think it is more general to pass2 rules. It seems
like pass2 rules do not correct output positions.
The following example also leads to an invalid output positions array.
Tables:
en-us-g2.ctb
Input:
---p
Translation:
--;p
Output positions:
0 1 2 4
Input positions:
0 0 3 3
I have not tested to see whether a pass2 which increases the length also
has similar issues.
Michael Whapples
On 14/04/2015 10:02, Michael Whapples wrote:
Hello,For a description of the software, to download it and links to
I have discovered a bug in en-us-g2.ctb where outputPos has incorrect
values.
The original phrase which highlighted this issue was:
ONLINE WRITER'S NOTEBOOK
The problem seems to be around the 'S where the outputPos seems to
imply an additional Braille cell to what is actually in the translation.
I have reduced this to the following example and what LibLouis reports
for the index arrays.
tables:
en-us-g2.ctb
Input:
r'S n
Translation:
r',s ;n
Output positions:
0 1 4 5 7
Input positions:
0 1 2 2 3 4 4
The output positions are not consistant with the other values LibLouis
is calculating and this leads to the last index in the output
positions being invalid.
Michael Whapples
project pages go to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
project pages go to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
