Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cell position and value merged with Excel or other tables and German and french eSpeak #555

Closed
nvaccessAuto opened this issue Feb 11, 2010 · 20 comments
Labels
bug component/i18n existing localisations or internationalisation
Milestone

Comments

@nvaccessAuto
Copy link

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.

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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"

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

Comment 6 by Bernd on 2011-02-26 15:17
Closing the ticket as fixed because the problem no longer exists.
Changes:
State: closed

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

Comment 9 by jteh on 2011-04-22 05:59
Changes:
Milestone changed from None to near-term

@nvaccessAuto
Copy link
Author

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 button". >>

I admit it would be very unpleasant to get a reading chopped by numerous between controls and contents.
But the question then comes:
Once NVDA has identified the presence of a table, would it not be possible to temporarily (from beginning to end of the table) switch to this multiple utterances mode ?
And instead of a why not using a as it is done to indicate uppercase characters?

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

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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?

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

Comment 16 by Daniel Langeron on 2011-05-05 17:38

  • I have obviously no intention to assert that in some cases would require 2 spaces as thousands separator.
    However, after further checking I can confirm that with SVOX Pico (FR) using two spaces does not work in Word (from 100 000 the numbers are read digit by digit)
  • I also confirm that the use of a third space fixes this problem.
  • So if eSpeak (FR) works correctly with these two spaces it is possible that the persistent problem with SVOX Pico is due to a defect of the synthesizer itself.
    SVOX Pico users will therefore be forced to use a workaround as described earlier in this post (regular expressions in the dictionary of the voice).
  • Can you give me the e.mail address of a contact at SVOX, if you have one?

Thank you for your support.
Daniel

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

Comment 19 by jteh on 2011-05-19 07:05
This should be fixed by e991e9e.
Changes:
Milestone changed from near-term to 2011.2
State: closed

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug component/i18n existing localisations or internationalisation
Projects
None yet
Development

No branches or pull requests

1 participant