a problem with reporting the cell content when pressing f2.

[nvaccessAuto]

Reported by fatma.mehanna on 2011-07-08 09:45
hi,
nvda doesn't report the cell content as soon as i press f2 to start editing.
steps to reproduce:
1 open microsoft excel.
2 go to a1 cell for example.
3 type any kind of content in it text/numbers.
4 press f2 to modify the cell content.
expected:
nvda should report the cell content when i use the left and the right arrows to move between the cell content letters or numbers.
results:
nvda just reports the cell content as soon as i press f2, but it keeps silent when i start using the arrow keys to move.

[nvaccessAuto]

Attachment nvda.log added by fatma.mehanna on 2011-07-08 09:47
Description:

[nvaccessAuto]

Comment 1 by jteh on 2011-07-08 09:59
What version of Microsoft Excel are you using? Is this an English version of Windows? Do you have any languages other than English configured?

[nvaccessAuto]

Comment 2 by m11chen on 2011-07-08 11:17
Actually, I have also noticed this. When in the edit field of cell contents, sometimes NVDA would speak "blank" where there is a character when moving the caret. I'm not sure, but it seems to be more common for symbols such as parenthesis and such, especially when there is a formula in the cell. I don't think this actually used to happen when we had the NVDA Excel Editor dialogue before we got rid of it.

[nvaccessAuto]

Comment 3 by briang1 on 2011-07-08 16:37
What is needed then is something we can all edit in which makes it occur to see if its version specific or something.

[nvaccessAuto]

Comment 4 by m11chen on 2011-07-17 10:18
I am not sure, but perhaps this might have something to do with the color of the special characters in formulas? The reading of "blank" is a bit unpredictable, but the only one that I can get to reproduce every time consistently is the last parenthesis in the formula, for example if a cell contains the following formula:

=SUM(A1:A4)

If I press F2 and then home to move the caret to the beginning of the formula, pressing right arrow successively will have NVDA speak every character with no problem except for the last right parenthesis, where NVDA would speak "line feed" instead. But now if I press left arrow to go back through the formula, NVDA speaks "blank" for the first character "A" for "A1" and the right parenthesis appearing in the formula. And now if I press right arrow to go through the formula again, NVDA now speaks "blank" for the character "A" in "A1" and also "line feed" for the last right parenthesis.

Weird.

Maybe someone could reproduce this?

[nvaccessAuto]

Comment 5 by m11chen (in reply to comment 4) on 2011-07-17 10:19
Replying to m11chen:

I am not sure, but perhaps this might have something to do with the color of the special characters in formulas? The reading of "blank" is a bit unpredictable, but the only one that I can get to reproduce every time consistently is the last parenthesis in the formula, for example if a cell contains the following formula:

=SUM(A1:A4)

If I press F2 and then home to move the caret to the beginning of the formula, pressing right arrow successively will have NVDA speak every character with no problem except for the last right parenthesis, where NVDA would speak "line feed" instead. But now if I press left arrow to go back through the formula, NVDA speaks "blank" for the first character "A" for "A1" and the left parenthesis appearing in the formula. And now if I press right arrow to go through the formula again, NVDA now speaks "blank" for the character "A" in "A1" and also "line feed" for the last right parenthesis.

Weird.

Maybe someone could reproduce this?

By the way, I am using Excel 2003 on Windows 7 64-bit.

[nvaccessAuto]

Comment 6 by m11chen on 2011-08-21 02:10
Hi,

I have tested this with Traditional Chinese Windows XP and Traditional Chinese Excel 2003, and after pressing F2, nothing is spoken in the edit cell content text field when moving the cursor. As this does not happen with English version Excel, this means that it probably has something to do with the language setting.

[nvaccessAuto]

Comment 7 by mdcurran on 2011-11-26 12:34
This can be reproduced by changing the font of a cell to a Chinese font such as pMingLui or dfkai-cb, and then pressing f2 and trying to arrow through the text.
It is still possible to use review commands, its just not possible to read with the caret, therefore, display model/NVDA are getting conflicting info about the position of the caret / the position of display text chunks.
This answers why many Chinese users are having issues with this. However it does not seem to happen with a japanese font such as MSGothic.
Could fatma.mehanna please state the font being used which caused the initial reporting of this ticket?
I will take a good look at why the locations of the caret and text are broken.
Changes:
Milestone changed from None to 2012.1

[nvaccessAuto]

Comment 8 by fatma.mehanna (in reply to comment 7) on 2011-11-26 14:51
Replying to mdcurran:

Could fatma.mehanna please state the font being used which caused the initial reporting of this ticket?

the font is Arial. i tried to change the cell font, but the problem still exists.

[nvaccessAuto]

Comment 9 by mdcurran on 2011-11-28 08:21
da0f762 fixes the Chinese font issue at least. Perhaps the other issue is to do with RTL?

[nvaccessAuto]

Comment 10 by fatma.mehanna on 2011-11-28 16:38
i tested snapshot4807 and found the following:
the same font Arial, nvda reads all the cell content fine when i press f2, but it doesn't read the first letter. it reads it as a space.
steps to reproduce:
1 go to a1.
type fatma for example.
3 press f2.
4 use the arrow keys to move among the cell characters.
expected:
nvda should read the whole cell characters.
results:
nvda doesn't read the first character and sees it as a space.
can i send a log file?
thanks for your excellent work.

[nvaccessAuto]

Comment 11 by mdcurran on 2011-12-29 04:08
I cannot reproduce, but I do think I understand why it could happen.
Technical:
Currently the rule for the caret is that it must touch or corss the baseline of the character, and also starts before the horizontal center of the character. This works great everywhere except for when there is a small amount of whitespace to the left of the first character, where the width of this whitespace is the same or thinner than the caret itself. Thus when the caret is on (before) the first character, it looks as though the caret is before the whitespace.
The only way to solve this is to remove default support for block carets, and assume that a caret will always end before the center of the character, rather than begin. Then we could have a seprate rule for block carets which particular apps could choose to use.
I shall think about this one.

[nvaccessAuto]

Comment 12 by jteh on 2012-01-18 23:51
Changes:
Milestone changed from 2012.1 to near-term

[nvaccessAuto]

Comment 13 by fatma.mehanna on 2012-03-08 16:07
there is another issue i want to refer to regarding this ticket.
when i edit an arabic cell, nvda reads the cell content reversly so as long i press f2.
for example, when i type an arabic word in a1 cell and pressing f2 to edit it, nvda reads the total content of the cell in a reverse way.
i don't know if this issue is relative to ticket number 1601.
here is a log file to show what is going on.
note, when i move on the arabic characters, the characters are being displayed from right to left as they should be.
thanks.

[nvaccessAuto]

Attachment nvda.2.log added by fatma.mehanna on 2012-03-08 16:09
Description:

[nvaccessAuto]

Comment 14 by jteh (in reply to comment 13) on 2012-03-08 21:38
Replying to fatma.mehanna:

when i edit an arabic cell, nvda reads the cell content reversly so as long i press f2.

i don't know if this issue is relative to ticket number 1601.

Yes, this is #1601.

[nvaccessAuto]

Comment 15 by fatma.mehanna on 2013-04-01 07:53
hi,
the problem of reporting the first char as a space when i use f2 to modify the excel cell content still exists.
Also reporting the cell content in a reversed way for rtl languages still exists.
thanks.

[nvaccessAuto]

Comment 16 by mdcurran on 2013-04-02 05:58
fatma: Could you please attach an excel document with cells containing text that is
unreadable when reading after pressing f2.
If this happens for both English and Arabic, and both rtl and ltr, please provide different examples of this.
It would be good if perhaps you could provide this in two columns: the first column with cells containing an english description of the problematic text, and then the second column with cells containing the actual example text.
Thanks for this.

[nvaccessAuto]

Comment 17 by fatma.mehanna (in reply to comment 16) on 2013-04-02 09:02
Replying to mdcurran:

fatma: Could you please attach an excel document with cells containing text that is

unreadable when reading after pressing f2.

attached.

If this happens for both English and Arabic, and both rtl and ltr, please provide different examples of this.

examples for LTR andRTL was given with a description for each direction problem.

It would be good if perhaps you could provide this in two columns: the first column with cells containing an english description of the problematic text, and then the second column with cells containing the actual example text.

i provided a document with 4 columns, 2 of them for examples of rtl andLTR and the other 2 for description of each problem. there is a fifth column for a similar problem between RTL andLTR.

Thanks for this.

thanks for your keenness.

[nvaccessAuto]

Attachment editing problems in f2 mode.xlsx added by fatma.mehanna on 2013-04-02 09:03
Description:

[nvaccessAuto]

Comment 18 by mdcurran on 2013-04-09 04:28
I have started work to implement RTL support in NVDA, specifically for MS Excel when editing a cell.
As of displayModelRtlSupport,5985 it should be possible to correctly read an Excel cell containing Rtl content when editing, either with flat review or with the system caret. Also, the bug where NVDA would only announce a space for the first character (evenin English) should be fixed.
I have only tested this in Excel 2007 so far.
This also seems to fix flat review in Wordpad.
However, where there are font changes, or rtl and ltr on the same line (e.g. Arabic and English together) the order of these chunks may be jumbled or reversed.
Please test the code by downloading and running a try build I made of 5985 at:
http://community.nvda-project.org/try/displayModelRtlSupport/nvda_snapshot_try-displayModelRtlSupport-5985.exe

[nvaccessAuto]

Comment 19 by fatma.mehanna (in reply to comment 18) on 2013-04-09 09:46
Replying to mdcurran:

I have started work to implement RTL support in NVDA, specifically for MS Excel when editing a cell.

thanks so much, that's very appreciated.

As of displayModelRtlSupport,5985 it should be possible to correctly read an Excel cell containing Rtl content when editing, either with flat review or with the system caret.

unfortunately, as soon as you press f2, NVDA reads the cell arabic content reversly. Also, when you use flat review to read, NVDA reads reversely.

Also, the bug where NVDA would only announce a space for the first character (evenin English) should be fixed.
yes this is fixed for me. thanks.

I have only tested this in Excel 2007 so far.

i tested that using excel 2010.

This also seems to fix flat review in Wordpad.

yes. Thanks so much.

However, where there are font changes, or rtl and ltr on the same line (e.g. Arabic and English together) the order of these chunks may be jumbled or reversed.

this is true somehow, when you write arabic words at the first of line, and english words after, when you use flat review, NVDA reads the english words then the arabic ones, but not in a reversed way, so we can understand what is being read.

Please test the code by downloading and running a try build I made of 5985 at:

http://community.nvda-project.org/try/displayModelRtlSupport/nvda_snapshot_try-displayModelRtlSupport-5985.exe

tested.

[nvaccessAuto]

Comment 20 by mdcurran on 2013-04-09 11:18
Okay, think I have temprarily fixed rtl support in Excel 2010. Please try this try build:
http://community.nvda-project.org/try/displayModelRtlSupport/nvda_snapshot_try-displayModelRtlSupport-5987.exe

Technical info:
Office 2010 seems to use ScriptStringOut, where is versions below that call ScriptTextOut directly. Therefore I have temporarily disabled support for ScriptStringOut and we will fall back to ScriptTextOut / ExtTextOut.

When ScriptStringOut was accidentilly disabled last time, no one seemed to be affected except for Arabic users in Windows Explorer. But since we now better support Rtl with ScriptTextOut / ExtTextOut, hopefully this is no longer a problem anyway.

[nvaccessAuto]

Comment 21 by fatma.mehanna (in reply to comment 20) on 2013-04-09 14:04
Replying to mdcurran:

Okay, think I have temprarily fixed rtl support in Excel 2010. Please try this try build:

http://community.nvda-project.org/try/displayModelRtlSupport/nvda_snapshot_try-displayModelRtlSupport-5987.exe

tested, but sorry, with no success.
but i noticed something that i wanted to comment on, but it has been fixed, it is the open with submenu. when i used try rtl support display model version 5985, when i open the open with submenu, the submenu items was appearing as something like font name, font size, rtl, and some strange words. but with version 5987 it has been fixed.

Technical info:

Office 2010 seems to use ScriptStringOut, where is versions below that call ScriptTextOut directly. Therefore I have temporarily disabled support for ScriptStringOut and we will fall back to ScriptTextOut / ExtTextOut.

When ScriptStringOut was accidentilly disabled last time, no one seemed to be affected except for Arabic users in Windows Explorer. But since we now better support Rtl with ScriptTextOut / ExtTextOut, hopefully this is no longer a problem anyway.

[nvaccessAuto]

Comment 22 by mdcurran (in reply to comment 21) on 2013-04-09 21:58
Replying to fatma.mehanna:
Fatma: Could you please try the following so that I can gain a better understanding of the problem:

• Open the Excel file you attached to this ticket in Excel 2010.
• Start, or restart, NVDA try displayModelRtlSupport 5987. It is important its started after the test excel file is already opened.
• Make sure your NVDA log is set to input/output.
• Press f2 on the cell that contains the arabic text.
• Move around the cell with the arrow keys and home and end etc.
• Navigate the cell with flat review.
• Attach your log to this ticket.

A question: Is there any difference at all when reading Arabic text in Excel between NVDA main/2013.1 and displayModelRtlSupport? even if its not useful or correct, if there is any difference its useful for me to know. On my system testing with both Excel 2007 and 2010, the Arabic letters show up very differently between main/2013.1 and displayModelRtlSupport. There must be something different between our systems.
If you ever have the chance to test displayModelRtlSupport 5987 on another machine with Excel 2007 or 2003 that would be very much appreciated.

Also, are you testing on Win7, or xp?

[nvaccessAuto]

Comment 23 by fatma.mehanna on 2013-04-10 00:27
hi,
I'm using windows xp, but i managed to use the same snap with win7 on another machine.
Actually, there is no difference between 7 and xp regarding to this issue.
as for using 2013, i tried with 2013beta2, and i found no difference.
i will attach a log, using 5987 snap.

[nvaccessAuto]

Attachment test.log added by fatma.mehanna on 2013-04-10 00:31
Description:

[nvaccessAuto]

Comment 24 by mdcurran on 2013-05-02 05:23
More generalized work and discussion was continued in #1601 which has now been closed as fixed. Support for rtl cursor tracking when editing in Excel was merged into master 52c03c8.
Changes:
Milestone changed from near-term to 2013.2
State: closed