Martin J. Dürst <duerst@...>
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
|
|
I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length.
If you would like to read by sentences, you can install my SentenceNav add-on.
HTH
--Tony
toggle quoted messageShow quoted text
On 11/18/2021 11:07 PM, Martin J. Dürst wrote: Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
|
|
In browse mode, you can set the line length. The default is
one-hundred carachters. I suppose it would be possible to have a read by
sentence option but I don’t know if there is any .demand for that. And it
would conflict with sentences in which there are links and you have NVDA set to
read every link on its own line.
Gene
toggle quoted messageShow quoted text
-----Original Message-----
Sent: Saturday, November 20, 2021 7:43 PM
Subject: Re: [nvda] More flexible line length in browsing
mode
I
believe in browse mode lines are defined visually, I don't recall NVDA
setting that would define line length.
If you would like to read by
sentences, you can install my SentenceNav
add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J.
Dürst wrote: > Hello everybody, > > I have been using NVDA on
and off for a few weeks. It's really a great > help. I'm new to this
mailing list, so please forgive me if I'm asking > something
old. > > When reading text from a Web page, the text is read in
"lines", and > the user presses arrow-down for each line. NVDA has a
setting for line > length, which is at 100 characters originally. So
well, so good. > > What I find somewhat confusing, and possibly a
place for improvement, > is that often a "line" ends a word or two before
the end of a > sentence, or includes a word or two of a new sentence. I
suspect that > quit a bit of thought must have gone into this, but I
haven't found > any details yet. > > I would really
appreciate if somebody could explain why "lines" end at > arbitrary
positions in sentences, and are not done a bit more flexibly > so that
they more often end at the end of a sentence. > > If this has been
discussed already, I would appreciate pointers. Also > if there's some
scientific paper about the issue. > > I have tried to think about
why things are as described above, and > have come up with various
possible reasons. If any of these reasons > applies, please just tell
me. > > - There is already a setting/add-on for this, just use
it. > > - Having more variable line lengths would make it more
difficult to read > Web pages (e.g. because the intervals
between the presses of the down > arrow would be more
irregular). If that's the case, then I haven't yet > had
enough practice to notice it. > > - Finding better positions to
split text into lines is a much harder > problem than it
looks. It is difficult to find actual sentence > boundaries in
text (not all periods are sentence endings), and > long
sentences without punctuation are also difficult to split. > > -
Finding better positions to split is possible, but good
algorithms > are too slow. Text-to-speech conversion already
uses quite a bit > of processing power. > > -
Finding sentence boundaries is quit language dependent, and
therefore > difficult to implement in a general
way. > > - The overall architecture of NVDA (and other screen
readers) makes > it too difficult to implement such a
feature. > > - Some other screen readers already do a better job at
this, but we > at NVDA just have not had time to get around to
do something here. > Help is appreciated. (I might want to
help.) > > - That's how screen readers always have done it, and
everybody is > used to it, and so changing it isn't a good
idea. > > If there are any other actual or potential reasons, please
tell me. > > Many thanks in advance for your help. > >
With kind regards, Martin. > > >
> >
|
|
As Gene noted, the line length in NVDA is a simple number - and it doesn't look to see if it can "just add the last word of a sentence". I can see that it might be advantageous though, I would suggest the best thing to do is create an issue on our tracker at: https://github.com/nvaccess/nvda/issues requesting the feature.
Kind regards
Quentin.
toggle quoted messageShow quoted text
On Sun, Nov 21, 2021 at 1:20 PM Gene < gsasner@...> wrote:
In browse mode, you can set the line length. The default is
one-hundred carachters. I suppose it would be possible to have a read by
sentence option but I don’t know if there is any .demand for that. And it
would conflict with sentences in which there are links and you have NVDA set to
read every link on its own line.
Gene
-----Original Message-----
Sent: Saturday, November 20, 2021 7:43 PM
Subject: Re: [nvda] More flexible line length in browsing
mode
I
believe in browse mode lines are defined visually, I don't recall NVDA
setting that would define line length.
If you would like to read by
sentences, you can install my SentenceNav
add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J.
Dürst wrote: > Hello everybody, > > I have been using NVDA on
and off for a few weeks. It's really a great > help. I'm new to this
mailing list, so please forgive me if I'm asking > something
old. > > When reading text from a Web page, the text is read in
"lines", and > the user presses arrow-down for each line. NVDA has a
setting for line > length, which is at 100 characters originally. So
well, so good. > > What I find somewhat confusing, and possibly a
place for improvement, > is that often a "line" ends a word or two before
the end of a > sentence, or includes a word or two of a new sentence. I
suspect that > quit a bit of thought must have gone into this, but I
haven't found > any details yet. > > I would really
appreciate if somebody could explain why "lines" end at > arbitrary
positions in sentences, and are not done a bit more flexibly > so that
they more often end at the end of a sentence. > > If this has been
discussed already, I would appreciate pointers. Also > if there's some
scientific paper about the issue. > > I have tried to think about
why things are as described above, and > have come up with various
possible reasons. If any of these reasons > applies, please just tell
me. > > - There is already a setting/add-on for this, just use
it. > > - Having more variable line lengths would make it more
difficult to read > Web pages (e.g. because the intervals
between the presses of the down > arrow would be more
irregular). If that's the case, then I haven't yet > had
enough practice to notice it. > > - Finding better positions to
split text into lines is a much harder > problem than it
looks. It is difficult to find actual sentence > boundaries in
text (not all periods are sentence endings), and > long
sentences without punctuation are also difficult to split. > > -
Finding better positions to split is possible, but good
algorithms > are too slow. Text-to-speech conversion already
uses quite a bit > of processing power. > > -
Finding sentence boundaries is quit language dependent, and
therefore > difficult to implement in a general
way. > > - The overall architecture of NVDA (and other screen
readers) makes > it too difficult to implement such a
feature. > > - Some other screen readers already do a better job at
this, but we > at NVDA just have not had time to get around to
do something here. > Help is appreciated. (I might want to
help.) > > - That's how screen readers always have done it, and
everybody is > used to it, and so changing it isn't a good
idea. > > If there are any other actual or potential reasons, please
tell me. > > Many thanks in advance for your help. > >
With kind regards, Martin. > > >
> >
-- Quentin Christensen Training and Support Manager
|
|
Martin J. Dürst <duerst@...>
Hello Tony,
Sorry to be late with my answer. We will definitely look at your SentenceNav add-on.
Regards, Martin.
toggle quoted messageShow quoted text
On 2021-11-21 10:43, Tony Malykh via groups.io wrote: I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length. If you would like to read by sentences, you can install my SentenceNav add-on. HTH --Tony On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|
Martin J. Dürst <duerst@...>
Hello Gene,
Many thanks for your mail. We want to try and find out whether there is a difference between various ways of reading text (fixed one-hundred characters or somewhat more flexible). Of course, if there's a link, and NVDA is set to read that separately, I guess we will read that separately.
Regards, Martin.
toggle quoted messageShow quoted text
On 2021-11-21 11:20, Gene via groups.io wrote: In browse mode, you can set the line length. The default is one-hundred carachters. I suppose it would be possible to have a read by sentence option but I don’t know if there is any .demand for that. And it would conflict with sentences in which there are links and you have NVDA set to read every link on its own line. Gene -----Original Message----- From: Tony Malykh Sent: Saturday, November 20, 2021 7:43 PM To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length. If you would like to read by sentences, you can install my SentenceNav add-on. HTH --Tony On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|
Martin J. Dürst <duerst@...>
Hello Quentin,
Many thanks for your reply. Creating an issue is a good idea, but we first want to try to implement and test it ourselves. We will look at Tony's SentenceNav add-on for some ideas on implementation.
Also, if you can give us a pointer on where the code for breaking text into lines of equal length is, that would be fine. If there is another list for such questions, please just tell us.
Regards, Martin.
toggle quoted messageShow quoted text
On 2021-11-22 15:38, Quentin Christensen via groups.io wrote: As Gene noted, the line length in NVDA is a simple number - and it doesn't look to see if it can "just add the last word of a sentence". I can see that it might be advantageous though, I would suggest the best thing to do is create an issue on our tracker at: https://github.com/nvaccess/nvda/issues requesting the feature. Kind regards Quentin. On Sun, Nov 21, 2021 at 1:20 PM Gene <gsasner@...> wrote:
In browse mode, you can set the line length. The default is one-hundred carachters. I suppose it would be possible to have a read by sentence option but I don’t know if there is any .demand for that. And it would conflict with sentences in which there are links and you have NVDA set to read every link on its own line.
Gene -----Original Message----- *From:* Tony Malykh <anton.malykh@...> *Sent:* Saturday, November 20, 2021 7:43 PM *To:* nvda@nvda.groups.io *Subject:* Re: [nvda] More flexible line length in browsing mode
I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length.
If you would like to read by sentences, you can install my SentenceNav add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|
I don't quite get why we need a line length mode anyway. It would be good if NVDA could honour the lines on the screen, even in the virtual buffer. I like the screen layout support, where links appear where they should, so why not make this work for formatting as well? All the best Steve -- To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribeComputer Room Services 77 Exeter Close Stevenage Hertfordshire SG1 4PW T: +44(0)1438-742286 M: +44(0)7956-334938 F: +44(0)1438-759589 E: steve@... W: https://www.comproom.co.uk
toggle quoted messageShow quoted text
-----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Martin J. Dürst Sent: 24 November 2021 08:25 To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode Hello Gene, Many thanks for your mail. We want to try and find out whether there is a difference between various ways of reading text (fixed one-hundred characters or somewhat more flexible). Of course, if there's a link, and NVDA is set to read that separately, I guess we will read that separately. Regards, Martin. On 2021-11-21 11:20, Gene via groups.io wrote: In browse mode, you can set the line length. The default is one-hundred carachters. I suppose it would be possible to have a read by sentence option but I don’t know if there is any .demand for that. And it would conflict with sentences in which there are links and you have NVDA set to read every link on its own line.
Gene -----Original Message----- From: Tony Malykh Sent: Saturday, November 20, 2021 7:43 PM To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode
I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length.
If you would like to read by sentences, you can install my SentenceNav add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|
Its an interesting question and one I haven't thought about. I find it a good idea to allow the maximum line length to be changed but is there a technical reason it is better to set a maximum length in the browse mode buffer than have the length determined by the screen width, as is the case in the presentation of the underlying HTML page?
Gene
toggle quoted messageShow quoted text
On 11/24/2021 3:36 AM, Steve Nutt wrote: I don't quite get why we need a line length mode anyway.
It would be good if NVDA could honour the lines on the screen, even in the virtual buffer.
I like the screen layout support, where links appear where they should, so why not make this work for formatting as well?
All the best
Steve
-- To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribe
Computer Room Services 77 Exeter Close Stevenage Hertfordshire SG1 4PW T: +44(0)1438-742286 M: +44(0)7956-334938 F: +44(0)1438-759589 E: steve@... W: https://www.comproom.co.uk
-----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Martin J. Dürst Sent: 24 November 2021 08:25 To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode
Hello Gene,
Many thanks for your mail. We want to try and find out whether there is a difference between various ways of reading text (fixed one-hundred characters or somewhat more flexible). Of course, if there's a link, and NVDA is set to read that separately, I guess we will read that separately.
Regards, Martin.
On 2021-11-21 11:20, Gene via groups.io wrote:
In browse mode, you can set the line length. The default is one-hundred carachters. I suppose it would be possible to have a read by sentence option but I don’t know if there is any .demand for that. And it would conflict with sentences in which there are links and you have NVDA set to read every link on its own line.
Gene -----Original Message----- From: Tony Malykh Sent: Saturday, November 20, 2021 7:43 PM To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode
I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length.
If you would like to read by sentences, you can install my SentenceNav add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|
It's something that Window-Eyes always allowed you to do. You could set a line length, but if you set it to 0, it would honour the HTML structure. All the best Steve -- To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribeComputer Room Services 77 Exeter Close Stevenage Hertfordshire SG1 4PW T: +44(0)1438-742286 M: +44(0)7956-334938 F: +44(0)1438-759589 E: steve@... W: https://www.comproom.co.uk
toggle quoted messageShow quoted text
-----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Gene Sent: 24 November 2021 12:49 To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode Its an interesting question and one I haven't thought about. I find it a good idea to allow the maximum line length to be changed but is there a technical reason it is better to set a maximum length in the browse mode buffer than have the length determined by the screen width, as is the case in the presentation of the underlying HTML page? Gene On 11/24/2021 3:36 AM, Steve Nutt wrote: I don't quite get why we need a line length mode anyway.
It would be good if NVDA could honour the lines on the screen, even in the virtual buffer.
I like the screen layout support, where links appear where they should, so why not make this work for formatting as well?
All the best
Steve
-- To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribe
Computer Room Services 77 Exeter Close Stevenage Hertfordshire SG1 4PW T: +44(0)1438-742286 M: +44(0)7956-334938 F: +44(0)1438-759589 E: steve@... W: https://www.comproom.co.uk
-----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Martin J. Dürst Sent: 24 November 2021 08:25 To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode
Hello Gene,
Many thanks for your mail. We want to try and find out whether there is a difference between various ways of reading text (fixed one-hundred characters or somewhat more flexible). Of course, if there's a link, and NVDA is set to read that separately, I guess we will read that separately.
Regards, Martin.
On 2021-11-21 11:20, Gene via groups.io wrote:
In browse mode, you can set the line length. The default is one-hundred carachters. I suppose it would be possible to have a read by sentence option but I don’t know if there is any .demand for that. And it would conflict with sentences in which there are links and you have NVDA set to read every link on its own line.
Gene -----Original Message----- From: Tony Malykh Sent: Saturday, November 20, 2021 7:43 PM To: nvda@nvda.groups.io Subject: Re: [nvda] More flexible line length in browsing mode
I believe in browse mode lines are defined visually, I don't recall NVDA setting that would define line length.
If you would like to read by sentences, you can install my SentenceNav add-on.
HTH
--Tony
On 11/18/2021 11:07 PM, Martin J. Dürst wrote:
Hello everybody,
I have been using NVDA on and off for a few weeks. It's really a great help. I'm new to this mailing list, so please forgive me if I'm asking something old.
When reading text from a Web page, the text is read in "lines", and the user presses arrow-down for each line. NVDA has a setting for line length, which is at 100 characters originally. So well, so good.
What I find somewhat confusing, and possibly a place for improvement, is that often a "line" ends a word or two before the end of a sentence, or includes a word or two of a new sentence. I suspect that quit a bit of thought must have gone into this, but I haven't found any details yet.
I would really appreciate if somebody could explain why "lines" end at arbitrary positions in sentences, and are not done a bit more flexibly so that they more often end at the end of a sentence.
If this has been discussed already, I would appreciate pointers. Also if there's some scientific paper about the issue.
I have tried to think about why things are as described above, and have come up with various possible reasons. If any of these reasons applies, please just tell me.
- There is already a setting/add-on for this, just use it.
- Having more variable line lengths would make it more difficult to read Web pages (e.g. because the intervals between the presses of the down arrow would be more irregular). If that's the case, then I haven't yet had enough practice to notice it.
- Finding better positions to split text into lines is a much harder problem than it looks. It is difficult to find actual sentence boundaries in text (not all periods are sentence endings), and long sentences without punctuation are also difficult to split.
- Finding better positions to split is possible, but good algorithms are too slow. Text-to-speech conversion already uses quite a bit of processing power.
- Finding sentence boundaries is quit language dependent, and therefore difficult to implement in a general way.
- The overall architecture of NVDA (and other screen readers) makes it too difficult to implement such a feature.
- Some other screen readers already do a better job at this, but we at NVDA just have not had time to get around to do something here. Help is appreciated. (I might want to help.)
- That's how screen readers always have done it, and everybody is used to it, and so changing it isn't a good idea.
If there are any other actual or potential reasons, please tell me.
Many thanks in advance for your help.
With kind regards, Martin.
-- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan
|
|