Hy,

Yesterday I sending this question with Liblouis mailing list, and look detailed more this issue.
I think I found a temporary solution, but I don't understand why happening this issue.
In normal hungarian Brltty table, the _ character is defined with /etc/brltty/hu.ttb file with following way:
char \x5F    (   4567 )  # ⡸ _ [LOW LINE]
When I replace with 4567 dot combination with 456 dot number and restart Brltty, the ly exception works fine with Orca and Liblouis trunk version.
I very surprised: Brltty default text table and Liblouis defined contraction tables some time not independent, and some time not possible using different dot numbers with a character or punctuation simbol?
How can tell Liblouis if enabled a screen reader with contracted braille feature, always send only the 456 dot combination without need editing the default Brltty used text table this simbol?
Brltty text table if possible we would like keeping international computer braille standard.

Possible determining absolute sure this is a Screenreader or Liblouis bug?

Attila
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

Created attachment 188803 [details]
A translated braille output file with Liblouis lou_translateString command

I doed a very simple test program to verify the translated braille output file after translation.
The text file contained only lyuk lyuk lyuk word.
My test code is following:
#!/usr/bin/env python
#!coding: utf-8
import louis
import sys
f=open(sys.argv[1], 'r')
szoveg=f.read()
f=open(sys.argv[3], "w")
szoveg=szoveg.decode('utf-8')
f.write(louis.translateString([sys.argv[2]], szoveg, None, 0)+'\n')

My test results if I turn off Orca contracted braille feature and opening the generated brf file:
1. If Orca running, I see wrong dot number with ly contracted exceptions.
2. If Orca not running, and I have text console, I see right only 456 dots. This is happening because in text console I setted Brltty preferences with six dot text style mode, but Orca owerwrite this setting with graphics session.

Other operating systems not happening problem when I opening this braille file, I see only 456 dots.

Attila

Hi Attila,

Does our latest changes to liblouis fix this issue?

Thanks.

Hy Mesar,

Yes, the committed hu-hu-g1.ctb table fix this issue, but this is a hungarian specific fix.
Since I reported the bug, underscore character dot combination is changed the new hungarian grade1 standard with 6-36 dot combination with contracted texts.
The ly and lly character pairs when happening Liblouis forward translation without unicode braille are marked with u+7f braille character, and this character defined with 456 dot combination both Liblouis hu-hu-g1.ctb table and hu.ttb Brltty braille table. The hu.ttb braille table this modification oldest time already committed.
So, if both two table containing 456 dot combinations the u+7f braille character, all works right.

I doed now a test, and experienced following result:
If I change the /etc/brltty/hu.ttb table with u+7f character dot combination from 456 to 4567 dot combination, restart Brltty and Orca, the ly and lly letter pairs dot combination changing with 4567 dot combination. In Liblouis the hu-chardefs.cti table defined the 456 dot combination the u+7f simbol, but Orca using this situation the 8 dot style Brltty testing dot combination this character.
I think Orca not have possibility to set always six dot style braille output. In console Brltty if the text style preferences are setted with six dot, Brltty send braille output with six dot combination mode. I verifyed this with hu.ttb braille table. When I turn text style with six dot mode in console, I see for example the é character with only 16 dot combination in console. If I turn off Orca with contracted braille, this situation Orca using Brltty hu.ttb table, but always eight dot mode.

NVDA how can do to toggling braille output mode with six dots or eight dots, depending what checkbox state checking user the proper dots related check box?

Attila

I believe that this problem is due to double translation.

1. orca gets the actual text, then sends it to liblouis
2. liblouis returns the dot combination for the string, which should be sent to the display as is.
3. But infact what is happening is that brltty is using its own tables to retranslate that which is handed over by step 2, and this is where the problem is occuring.

If the the liblouis and brltty tables agree on the translation of a given character, then a user will not notice when they switch between the graphical environment to a console.

alternatively, when orca hands over the already translated text to brlapi it should set a flag requesting brltty not to do another retranslation.

It might be intresting to discuss this on the brltty list to see if my understanding is correct.
 
nvda does not have any option for switching between 6 or 8 dot presentation, other than the user selecting a different computer or contracted table.
 
Thanks.

You are right.
Temporary I activated Brltty preferences my braille display, and change text table preference with hu.ttb to hy.ttb. When I restart Orca, I see invalid characters, not Liblouis hungarian contracted texts.

Attila

Created attachment 220784 [details] [review]
A possible fix

Well, now the situation is following:
If in Brltty preferences different table are choosed with Orca selected Liblouis contraction table, Orca contracted braille output is wrong after saved the Brltty preferences the new table. So now when contracted braille are enabled, contracted braille output presenting result the braille display depending with Brltty actual braille table.
For example, if I choose in Brltty preferences the is or another table, but hu-hu-g1.ctb the selected contraction table, I see entire wrong output when Orca running, because Brltty table the braille characters dot combinations is different the Liblouis table.
The problem is reproducable for example with en-us-g1.ctb table. If contracted braille are enabled, I write for example a number and press space character, hr.ttb braille table I not 3456 dot combination see with the numbersign indicator.

If I apply this patch in src/orca/braille.py the Liblouis translate function execute line before self.contractionTable variable, this problem not happening, because Orca final sending contracted braille output format is unicode braille, not Liblouis ascii braille.
Mesar, my summary is correct?

If this solution not good default to apply Orca side now (Liblouis side all Liblouis braille tables need including braille-patterns.cti table file to users possible reading unicode braille), possible doing a check box with toggling braille translation braille format Liblouis ascii braille and unicode braille.
For example an example check box label is enable unicode braille output.
Joanie, what your openion this change?

Attila

Better not to hack around it in orca/nvda/android screenreader, they would all need a simular change.
I have posted an enhancement request here:
http://www.freelists.org/post/liblouis-liblouisxml/unicode-braille-output-when-no-dis-defined

If we cant get the change in liblouis, we can then approach the brltty people.

Mesar

Created attachment 221734 [details] [review]
Fix for bug 651264 - Make sure braille is not double translated first by liblouis then by brltty.

The above attachment solves the problem nicely for me.
Attila can you also please test?
the current stable liblouis does not expose the ucBrl flag so this only works against svn trunk for now.
Hopefully liblouis stable is not too far away.

Mesar, Fix is not full perfect yet.
If I set Brltty table for example with hy.ttb, normal texts are right presenting, but indicators not, for example Orca end of line indicator in Gedit application.
I think this indicator Orca marking with $l character.
Look following debug.out part:
PREPARATION TIME: 0.0010
generate braille for focused app.name='gedit' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' (args={'formatType': 'focused', 'role': <enum ATSPI_ROLE_TEXT of type Role>, 'mode': 'braille', 'recursing': True}) using '(includeContext                           and (ancestors                                + (rowHeader and [Region(" " + asString(rowHeader))])                                + (columnHeader and [Region(" " + asString(columnHeader))])                                + (radioButtonGroup and [Region(" " + asString(radioButtonGroup))])                                + [Region(" ")])                           or []) + [Text(obj, asString(label + placeholderText), asString(eol))]                + (required and [Region(" " + asString(required))])                + (readOnly and [Region(" " + asString(readOnly))]) + (nodeLevel and [Region(" " + asString(nodeLevel))])'
GENERATION  TIME: 0.0018  ---->  includeContext=False
GENERATION  TIME: 0.0011  ---->  label=[]
GENERATION  TIME: 0.0008  ---->  placeholderText=[]
GENERATION  TIME: 0.0005  ---->  eol=[u' $l']
GENERATION  TIME: 0.0042  ---->  required=[]
isReadOnlyTextArea=False for app.name='gedit' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations=''
GENERATION  TIME: 0.0052  ---->  readOnly=[]
GENERATION  TIME: 0.0047  ---->  nodeLevel=[]
COMPLETION  TIME: 0.0236
generate braille results:
TypeError when trying to write text
BRAILLE LINE:  '⠁⠇⠍⠁ $l'
     VISIBLE:  '⠁⠇⠍⠁ $l', cursor=1

Clear seeing what the problem:
Orca sending alma text with unicode braille, this is right, but sending Orca indicators with non unicode braille.
Why have debug.out file the TypeError when trying to write text error message? You see too this error message when you creating a debug.out file?

Attila

I forgot to wrote:
$l indicator need presenting I think with 46-123 dot combination.

Attila