I can confirm seeing the behaviour described, here is an example (Halim confirm this is what you meant):
1. Set orca to use contracted Braille, I have set it to use the grade2 en-gb table and apply the settings.
2. Open gedit and type the following (without quotes):
"Here liblouis is doing something strange"
3. Observe where the Braille cursor is
Expected:
The Braille cursor should be immediately after the "e" of the word strange.
Actual:
The Braille cursor is in the position of that it would occupy if the Braille were not contracted, so is over to the right of "$l" marking used to notify in an edit type control.

One impact of this is that it is impossible to see whether there are spaces after the last word and if the cursor is after those spaces or not (I noticed this while writing this bug report as I had to answer the phone and when I came back I couldn't tell where I was by using Braille).

I am not sure whether this is a liblouis cursor positioning problem or an orca one as I don't know whether orca uses liblouis's cursor positioning in louis.translate (If it doesn't then orca might be able to achieve correct results by using that).

As for whether orca should try and translate as you type, I can see the argument that the current/unfinished word should not be translated, but altering this alone would not solve the cursor position issue (you will notice in my example that the cursor position gets further and further away from the correct position as you write the line).

Confermed.
I don't know how to determin the cursorpos but it sohould be adjusted
to real possition after pressing space.
this need not translating the word during typing.

(In reply to comment #2)
> Confermed.
> I don't know how to determin the cursorpos but it sohould be adjusted
> to real possition after pressing space.
> this need not translating the word during typing.
My thought was that orca could use louis.translate to perform the translation, passing in the cursor position and louis.compbrlAtCursor for the mode (IE. liblouis will know the cursor position, use computer Braille for the word the cursor is on and report back the cursor position in the returned tuple.

Orca developers/people knowledgeable of orca's internals, is my above description of how orca could do the cursor positioning how it is currently done?

I tried some experiments in python with liblouis:

import louis
louis.translate(['en-us-g2.ctb'], 'Hello world', None, 11, louis.compbrlAtCursor)
louis.translate(['en-us-g2.ctb'], 'Hello world', None, 12, louis.compbrlAtCursor)

I find for the first call to translate "world" is not translated and I believe cursor would be just after the word "world". The reported cursor position is 12 which would be right as we get one extra Braille cell for the capital sign.

The second call to translate has the cursor position outside the string, so "world" is contracted. However the cursor position is not correct (it returns 12) but that might be sensible as it is outside the input string.

So my conclusions are:
* Orca is not using the cursor positioning of liblouis
* If orca is using the cursor positioning of liblouis then it is using invalid cursor positions or I made a mistake about what my example should do in which case it would be a liblouis problem.

Anyone any thoughts?

(In reply to comment #3)
> (In reply to comment #2)
> > Confermed.
> > I don't know how to determin the cursorpos but it sohould be adjusted
> > to real possition after pressing space.
> > this need not translating the word during typing.
> My thought was that orca could use louis.translate to perform the translation,
> passing in the cursor position and louis.compbrlAtCursor for the mode (IE.
> liblouis will know the cursor position, use computer Braille for the word the
> cursor is on and report back the cursor position in the returned tuple.
> 
> Orca developers/people knowledgeable of orca's internals, is my above
> description of how orca could do the cursor positioning how it is currently
> done?

Orca's braille.py:contractLine method is the thing that does the contraction and it pretty much does what you describe above.

I think what we're seeing here might be two separate, but perhaps related, problems.  The first is that Orca seems to be setting the braille cursor position based upon uncontracted text, hence it seems to keep getting pushed farther and farther to the right.  I just opened bug #592517 for that.

The second is that when the caret is on a word boundary (e.g., a space just to the right of a word), the word to the left is contracted.  That seems to be the subject of this bug.  Halim - when I navigate existing text using the arrow keys, the word is only uncontracted when I'm on a character of the word.  As soon as I leave the word, the word becomes contracted.

If we go with the model that the word you are typing should be uncontracted until you type a word boundary (e.g., return, space, punctuation, etc.), should the navigation follow the same model?  That is, if you are on the right hand edge of a word, should the word uncontract?  Should the words on either side of where you are uncontract?  Etc.  I'm not sure what the model should be and whether it should attempt to distinguish between navigation and text editing.

right will this are seperate problem.
Your fix for bug #592517 has fixed the cursor positioning problem.
Regarding this bug it's difficult to handle navigation/typing stuff.
So I don't know if the current behaviour should be changed or not.
The most anoying problem (cursorpos problem) is fixed through 592517.

Hm. Reopening as I can't see any open non-developer question.

Hi Halim, Michael

Looking at our code for contraction, it is implemented correctly.

We might be able to specify exactly what we need, and then ask the liblouis people if they could implement a new mode.

Consider the string:
"this this this"

1. when we are within the first word, then the other two should be contracted.

2. what do we want to happen for when we are at the space between the two words?
Keep in mind that when we are writing a word the cursor will be on a space, i.e. not actually on a character.
This is the issue that Halim stated, he didn't want text to be translated while we are writing.

suggestion:
What do you think about having the first two words uncontracted, and the third one contracted?
I.e. when we are between two words, then the word to the left and word to the right are uncontracted, as soon as we move within a word, it is only that word that is uncontracted.

Any other suggestions?

Thank you.

(In reply to comment #7)
> Hi Halim, Michael
> 
> Looking at our code for contraction, it is implemented correctly.
> 
> We might be able to specify exactly what we need, and then ask the liblouis
> people if they could implement a new mode.
> 
> Consider the string:
> "this this this"
> 
> 1. when we are within the first word, then the other two should be contracted.
I agree with this.
> 
> 2. what do we want to happen for when we are at the space between the two
> words?
> Keep in mind that when we are writing a word the cursor will be on a space,
> i.e. not actually on a character.
> This is the issue that Halim stated, he didn't want text to be translated while
> we are writing.
> 
Can I just clear up, if your example string were a python string you mean the cursor is at index 4? I will continue assuming that is the case.
> suggestion:
> What do you think about having the first two words uncontracted, and the third
> one contracted?
Following my assumption of what you meant, I would say any insertion at that point is only altering the first word, therefore only the first word should be uncontracted.
> I.e. when we are between two words, then the word to the left and word to the
> right are uncontracted, as soon as we move within a word, it is only that word
> that is uncontracted.
Your description again raises the question of what is between words? Would having the cursor at index 5 be between the words? Following my logic up to now, any insertion at index 5 would only alter the second word, therefore only the second word would be uncontracted. Should we be between two non-word characters (eg. if there were two spaces between a word and the cursor were between the spaces) then we are not going to edit any word on insertion, therefore all words would be contracted.
> 
> Any other suggestions?
> 
> Thank you.
Does my idea of working by insertion point rather than by cursor (the two are related but sort of differ in their meaning) help in understanding this?

Hi Michael,

Yes, let us consider the example as a python string.

So what you are saying is:
While cursor is within a word, this is expanded (0-3).
When we are on the space to the right of the word (4 in our example), the word to the left is still uncontracted, and the word to the right is contracted.
When we move the cursor one to the right, (so we stand on the second t, index 5), first word becomes contracted, and second is uncontracted.

Note liblouis does not know if we are inserting or reviewing text, so it doesnt care if 
we are talking in terms of insertion/cursor  position.

Is this also the behaviour we want when reviewing text? (sounds like it is as a braille user myself, but then again i am not really a grade 2 user).

-Jon

You seem to have it exactly. The only thing I would add is there is one case where we can guarantee we are not going to be dealing with insertion, if the control is read-only. I would be tempted to say in this case, as the text cannot be change, orca should instruct liblouis to contract all text.

OK, now looking may be towards a fix, if it were to require an extra mode in liblouis, I think we are clear as to what it should do (at least from the python end). If the cursor index is within a word (I am going to redefine "within a word" in a minute) then that word is uncontracted.

New definition of in a word: We can extract a single word from a python string by using two indices (eg. the example we are working with, we get the first word with [0:4], second word [5:9] and third with [10:14]), so if the cursor value is within the inclusive range of the slice indices then we are within the word.

Try thinking of cursor always being at the join between characters rather than on a character (eg. like some applications do with the vertical bar type cursor).

I am on the liblouis mailing list, shall I have a word with the liblouis team about such a mode?
(In reply to comment #9)
> Hi Michael,
> 
> Yes, let us consider the example as a python string.
> 
> So what you are saying is:
> While cursor is within a word, this is expanded (0-3).
> When we are on the space to the right of the word (4 in our example), the word
> to the left is still uncontracted, and the word to the right is contracted.
> When we move the cursor one to the right, (so we stand on the second t, index
> 5), first word becomes contracted, and second is uncontracted.
> 
> Note liblouis does not know if we are inserting or reviewing text, so it doesnt
> care if 
> we are talking in terms of insertion/cursor  position.
> 
> Is this also the behaviour we want when reviewing text? (sounds like it is as a
> braille user myself, but then again i am not really a grade 2 user).
> 
> -Jon

:) glad that we are on the same page.
Yes, please ask them if they would consider the redefinition of their within a word, or add a new mode.
because their definition is very simular to ours, except we include the space to the right of the word as part of it, and they dont.

As for forcing the line to contract, I am personally not so sure, but as long as it is an optional thing, then it can be left up to the user.

But please make sure they understand these as two separate issues.

Thanks for communicating with them, and please let us know when you get a result.

I have asked the question, here is my posting on the list http://www.freelists.org/post/liblouis-liblouisxml/The-definition-of-the-cursor-being-in-a-word

blocking for now, since we have no control over external schedules (liblouis).

(In reply to comment #13)
> blocking for now, since we have no control over external schedules (liblouis).

I asked and the only I got was from John J Boyer who said he wants to hear from the NVDA developers on this first as they also use liblouis. He also said that the contracting of words currently works in liblouis the same as contracted Braille in JFW. I do feel this is wrong behaviour as while I am writing a word it gets contracted.

Unfortunately I haven't seen anything from the NVDA developers on the liblouis list about this. Perhaps when you feel it may be worth nudging them again on this, then let me know and I can ask again.

Closing blocked bugs because we need the issue fixed in the blocker.