Closed nvaccessAuto closed 8 years ago
Comment 1 by coffeekingms (in reply to comment description) on 2010-02-11 16:55 Replying to heikofolkerts:
When using NVDA in Excel 2003 using the german default settings, the cell position and values are pulled together, so that it sounds wrong.
Example:
a1 = 300
a2 = 500
will be read like
a 1300
a 2500
It irritated me so much, that I first thought my formula was wrong.
The speach has to tread the cell position and the value separately.
This deffect makes excel allmost unusable without a braille display.
I believe that this is a duplicate of #320. jamie, what do you think? I have closed this temporarily as duplicate of 320. please reopen if I'm incorrect. Changes: Added labels: duplicate State: closed
Comment 2 by heikofolkerts on 2010-02-11 18:23 Yes, the description is also in #320. But I was requested to file the problem as a separate Bug from jti. The problem is major if not critical since it blocks real using of excel. Changes: Removed labels: duplicate State: reopened
Comment 3 by jteh on 2010-02-11 22:27 The problem is that eSpeak merges numbers that are separated by spaces for German. For example, "a1 500" is pronounced as "a1500". I assume this is correct for German numbering (in Australian/British/U.S.English, we use a comma as the thousands separator).
Unfortunately, even using a line feed character causes this problem. The only solution on our side would seem to be to completely separate speech chunks for these items, but this would affect much more than just Excel. It has always been NVDA behaviour not to pause between speaking the name, type, value, etc. of a control.
I think we're going to need to work with Jonathan (the eSpeak dev) to try to come up with a solution for this issue, which will probably require changes on both sides. As such, I don't think this is going to be fixed in short order. Changes: Changed title from "Reading of cell position and Value cause irritating speach output" to "Cell position and value merged with Excel and German eSpeak"
Comment 4 by heikofolkerts on 2010-02-12 20:08 The speech problem is not fixed to ESpeak. Eloquence e.g. produces the same effect when reading a1 500. But for eloquence a1 500 (two spaces) gives a correct result. A workarround could be to use a1: 500 and turn of the readout of the colon as a separate character.
Comment 6 by Bernd on 2011-02-26 15:17 Closing the ticket as fixed because the problem no longer exists. Changes: State: closed
Comment 7 by Bernd on 2011-04-22 04:53 Dawn me! I dubblechecked it with latest snapshot and the issue occurs. When I closed this tickets I had a chance to use Excel normally without merging coordinates with numbers larger than 100. Changes: Changed title from "Cell position and value merged with Excel and German eSpeak" to "Cell position and value merged with Excel or other tables and German and french eSpeak" State: reopened
Comment 8 by msuch (in reply to comment 7) on 2011-04-22 05:30 I would like to insist on the fact that this is not an eSpeak problem. The problem occurs as well with other french speaking synthesizer sice it is due to the fact that space can be a thousand separator in french (and maybe in german).
eplying to Bernd:
Dawn me! I dubblechecked it with latest snapshot and the issue occurs. When I closed this tickets I had a chance to use Excel normally without merging coordinates with numbers larger than 100.
Comment 9 by jteh on 2011-04-22 05:59 Changes: Milestone changed from None to near-term
Comment 10 by Daniel Langeron on 2011-04-25 16:50
J. Teh comments the ticket #1444 by saying:
<< #555 and #1444 occur because we send the information to the synthesiser to be spoken as one utterance. If we send it as multiple utterances, there will be pauses between the name of a control and its content, which is bad. We do not want to hear "OK
I admit it would be very unpleasant to get a reading chopped by numerous
It should also be noted that this inconvenience is not only present in Windows Office applications, but is also present while reading of tables in Web content (e.g. bank statements of personal accounts)
I understand that this problem, for the time being, only affects German and French users, but for them it seriously penalizes the use of NVDA !
Daniel
Comment 11 by Daniel Langeron on 2011-05-01 17:38 Pending the development of an integrated solution to NVDA, I checked whether it was possible to find a workaround to this difficulty while reading tables. I thought about using regular expressions in the dictionary of the involved voices (I checked with the French versions of e.Speak and SVOX Pico) The result of these tests was satisfactory.
I wrote each of the three following rules for each of the two dictionaries. First Rule 1/ Pattern field: ^Colonne ([Replacement field: Colonne \1 ..
Second Rule 1/ Pattern field: ^Ligne (0-9 2/)+) 2/ Replacement field: Ligne \1 ..
Third Rule 1/ Pattern field: ^([A-Z]+)([0-9]+) 2/ Replacement field: \1\2.. Note: For each rule, Case sensitive field not selected and Regular expression field selected. If you think that this method can be useful, just adapt translation of the words "Colonne", "Ligne", "Moins" (Column, Line, Minus) Daniel
Comment 12 by jteh on 2011-05-03 08:01 Does a double space between numbers work properly for synths other than eSpeak? e.g. 1 100
Comment 13 by Daniel Langeron on 2011-05-03 14:11
For SVOX Pico - French voice: Double space works with Excel spreadsheet (eg A1 123,45) regardless of the number. Double space works with a Word table (eg Line1 Column1 123,45) up to 99 999,99 but no longer works from and beyond 100 000,00 Also note that Triple space works with both Excel and Word whatever numbers. Daniel
Comment 14 by jteh on 2011-05-05 10:21 Erg. I might be willing to do double space, but triple space is a bit ridiculous. I'd argue that is a synth bug unless you can come up with a good reason for it doing this. That is, are there any cases where you would legitimately write numbers separated by two spaces and expect them to be treated as the same number?
Comment 15 by msuch (in reply to comment 14) on 2011-05-05 11:15 Replying to jteh:
Erg. I might be willing to do double space, but triple space is a bit ridiculous. I'd argue that is a synth bug unless you can come up with a good reason for it doing this. That is, are there any cases where you would legitimately write numbers separated by two spaces and expect them to be treated as the same number?
The thousand separator is one space. If there are more than one, numbers are separated. So 2 spaces are enough.
Comment 16 by Daniel Langeron on 2011-05-05 17:38
Thank you for your support. Daniel
Comment 17 by orcauser on 2011-05-05 19:02 Wouldnt solving bug #320 automatically work around these issues, especially since we have little control about various tts engines.
Thank you.
Comment 18 by jteh on 2011-05-05 21:42 @Daniel: I don't have a contact at Svox. Sorry.
@orcauser: Perhaps, but solving #320 is far more subjective and far more difficult. Even if we could do that for Excel, we couldn't really do it for tables elsewhere because the table cell is often an ancestor of the content. Anyway, that should be discussed further in #320.
Comment 19 by jteh on 2011-05-19 07:05 This should be fixed by e991e9ee1f16fb2440eb6203514addea15ae1e34. Changes: Milestone changed from near-term to 2011.2 State: closed
Comment 20 by del65 on 2011-12-17 22:27 I reopen this bug because the problem described here persists, at least with the Virginie French voice. Changes: State: reopened
Comment 21 by jteh on 2011-12-28 21:45 The synth you mention obviously doesn't treat numbers as separate when they are separated by two spaces. This is a bug in the synth. Changes: State: closed
Reported by heikofolkerts on 2010-02-11 16:31 When using NVDA in Excel 2003 using the german default settings, the cell position and values are pulled together, so that it sounds wrong. Example: a1 = 300 a2 = 500 will be read like a 1300 a 2500
It irritated me so much, that I first thought my formula was wrong.
The speach has to tread the cell position and the value separately.
This defect makes excel allmost unusable without a braille display.