Hi John, Regarding your fix in 1.3.9, you said:
I thought the best way to handle the repeated opcode if the cursor fell in a repeated section was not to execute it
This makes perfect sense to me. However, this doesn't seem to be happening.You added a condition which does a "break" instead of a "return" if the repeated section lies between compbrlStart and compbrlEnd:
I don't follow how breaking instead of returning causes this not to be executed, as it will just move on to the next part of the function. This piece of code seems to be causing problems with the input/output position maps as well. Would setting transOpcode to CTO_NONE be the correct solution? I'm having trouble understanding the purpose of this first switch statement in for_selectRule().case CTO_Repeated: if ((mode & compbrlAtCursor) && src >= compbrlStart && src <= compbrlEnd) break; return;
Thanks. On 16/01/2009 9:38 PM, James Teh wrote:
Hi John, I submitted a patch which you included in 1.3.9. The patch did the following:When handling input which is removed due to a "repeated" opcode, correctly update the mapping from input to output positions; i.e. the outputPos array and the returned cursorPos.Unfortunately, as explained in this thread: //www.freelists.org/post/liblouis-liblouisxml/patch-Correct-input-to-output-position-mapping-for-removed-repeated-text,3 it caused a rather nasty regression. I did come up with an alternative to this patch, but I'm not sure that was the right solution either. You noted that you had a more correct solution for this which you applied in 1.4.0. However, I noticed that you didn't remove my existing patch from 1.3.9. Furthermore, that still doesn't seem to fix the problem. Do you have any further ideas on this one? I can try to provide more test cases or explanation if needed. It can be a rather frustrating bug for NVDA users. Thanks!
-- James Teh Email/MSN Messenger/Jabber: jamie@xxxxxxxxxxx Web site: http://www.jantrid.net/ For a description of the software and to download it go to http://www.jjb-software.com