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
Say all without unnatural pauses #149
Comments
Attachment paragraphOffsets.py added by pvagner on 2008-08-01 06:23 |
Comment 1 by jteh on 2008-07-31 22:19 |
Comment 2 by jteh on 2008-07-31 22:59 Unfortunately, determining where sentences begin and end poses a localisation problem. Different languages have different indications of sentence boundaries and some languages don't have a concept of a sentence at all. Aside from the problem of gathering rules for different languages, as usual, we can't make these determinations based on the NVDA language, as the user might be reading in a language other than their NVDA language at any given time. There is another option aside from reading by sentence or paragraph. Note that reading by sentence can introduce pauses that the synth would not otherwise introduce. For example, if the synth would normally not have paused after a full stop (.) for some reason, reading by sentence would introduce a pause which the synth would not otherwise have made. An alternative used by some screen readers is to end the current chunk of text only if that chunk ended with characters which would have indicated a pause. For example, if there are three sentences across two lines where the third sentence ends at the end of the second line, the chunk would end only at the end of the second line. This is rather complicated and would result in larger chunks of text than reading by sentence. It still suffers from the localisation problem above, as the pause characters would be specific to each language. |
Comment 3 by jteh on 2008-08-01 05:45 On further discussion, although less efficient, doing this by paragraph is simpler, less prone to error and does not suffer from the localisation problem I described. |
Comment 4 by pvagner on 2008-08-01 06:29 |
Comment 5 by aleksey_s on 2008-11-26 08:38 |
Comment 6 by aleksey_s on 2009-02-25 20:53 |
Comment 7 by pvagner on 2009-04-13 06:33 |
Comment 8 by jteh on 2009-06-23 05:33 |
Comment 9 by mdcurran on 2009-12-08 02:01 Changes: |
Comment 10 by pvagner on 2009-12-12 10:40 |
Comment 11 by briang1 on 2010-10-23 13:45 What we don't want is to have it made really sluggish due to all the pre processing though. |
Comment 12 by jteh on 2010-12-28 23:46 However, I've just realised that this will cause problems with regard to indexing. We're moving by line, so the indexes need to be for each line. Because sentences may cross multiple lines, this means that the indexes need to be inserted in the middle of an utterance. While synths supporting markup do allow this, NVDA doesn't currently support speech markup. Unfortunately, this means we probably won't be able to implement better say all until we implement speech markup. There may also be some synths that don't support markup (eSpeak, sapi4 and sapi5 do, but I'm not sure about newfon and audiologic for example). If this is the case, say all by sentence won't be possible for these synths. |
Comment 13 by aleksey_s (in reply to comment 12) on 2010-12-29 19:24
Why we can't move by sentence? Then markup support will not be required. This one should be configurable though.
Newfon currently does not support markup , but it is almost indifferent about say all by line or by sentence, since it doesn't assume sentence ending without full stop. |
Comment 14 by jteh (in reply to comment 13) on 2010-12-29 20:03
The same reason we don't already: most controls don't support it natively. For controls that use !OffsetsTextInfo, we could provide a base implementation of sentence offsets that uses the symbol framework, just like we do for line offsets. Unfortunately, this is not particularly efficient. At worst, it will require the entire text to be retrieved when calculating sentence offsets like we do for the base implementation of line offsets (which we thankfully rarely use). It can be optimised such that it might need to retrieve the text for multiple lines instead of the entire text, but in some cases, this could be worse, since it means multiple calls. Also, not all controls use offsets, and in these cases, there's nothing we can do. |
Comment 15 by aleksey_s (in reply to comment 14) on 2010-12-29 21:16
Again, if we can somehow distinguish lines in those controls, we can to it for sentences as well. If we can't, then really nothing we can do :-) |
Comment 16 by jteh (in reply to comment 15) on 2010-12-29 21:45
Note that you also have to move to the point where the sentence begins/ends, which might be in the middle of the line.
There are several reasons calls will increase:
No, we can't. As I said above, we have to move to the point where the sentence begins/ends. For controls that don't support offsets, there's no way to do this. It is incorrect to assume that characters and offsets are equivalent; there are actually real world cases where this is not true. |
Comment 17 by jteh on 2011-04-14 07:34 |
Comment 18 by jteh on 2011-04-17 21:35 |
Comment 19 by mdcurran on 2011-04-25 05:40 |
Comment 20 by jteh on 2011-04-28 06:38 |
Reported by aleksey_s on 2008-07-31 10:16
Currently, when reading text in e.g. notepad, nvda sends text to the synth by line. So, most synths decide this is an end of text and make end of sentence inflection. its ofcourse sounds bad when there are a long paragraph of text. So nvda must send text to the synth by another chunk of text (sentence or paragraph).
The text was updated successfully, but these errors were encountered: