You evidently tried to send an attachment.  This list, and lists in general, don’t accept attachments for security reasons.  You can upload the material to a file sharing service and send a link in a message.

 

Gene

-----Original Message-----

From: Eduardo Fermiano Luccas

Sent: Thursday, November 25, 2021 2:36 PM

To: nvda@nvda.groups.io

Subject: [nvda] first inprocess

 

Hello friends, it is with great affection that I send the first in process which was on January 20, 2017! I hope old users remember, and 2020 users like me, I hope you read this to see how the in process was introduced!

dear group members, can anyone provide me synths for my nvda running
on windows 7

thanks and regards,
sazid

I only played with the attachment a little bit but I’m not sure it does anything more than the method for dragging and dropping already available in NVDA. 

 

Gene

-----Original Message-----

From: Orhan Deniz via groups.io

Sent: Tuesday, November 23, 2021 2:18 PM

To: nvda@nvda.groups.io

Subject: Re: [nvda] accessible way of moving playlists to folders in spotify?

 

Yeah seems to have a nightmare with object navigation. At times I get an object has no location when using the review cursor and navigator to find the correct playlist.

On 23/11/2021 20:00, Sarah k Alawami wrote:

Since it is electron I doubt it will work. I have not had any luck using this add on for dragging dropping  stuff, at all. Not to say it does not work, but for me it has worked maybe 1 time out of the 10 or so I’ve used it.

 

From: nvda@nvda.groups.io mailto:nvda@nvda.groups.io On Behalf Of Orhan Deniz via groups.io
Sent: Tuesday, November 23, 2021 11:46 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] accessible way of moving playlists to folders in spotify?

 

It seems that when I try to mark a playlist, then drop it into the relevant folder I get a can't drop here error. I am not sure if this add on will work with spotify playlists, but I will give it more of a road-test.

On 23/11/2021 19:39, Brian Vogel wrote:

Orhan,

Just FYI, this add-on is compatible with 2021.3 and, in addition, does have help/usage information packaged with it that you can access via gaining focus the add-on in Add-Ons Manager (NVDA + N, T, A, Enter) then activating the Add-On Help button.
--

Brian - Windows 10, 64-Bit, Version 21H1, Build 19043 

The ignorance of one voter in a democracy impairs the security of all.

         ~ John F. Kennedy

 

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

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

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.