Re: NVDA Settings Documentation


Had to dig into C++ part of NvDA to figure this out:
This setting sets browse mode line length, so yes, it applies to when reading by line. Specifically, based on what I can tell, it will do its best to break at word boundaries. This is one of the reasons why links can "span" across multiple lines in browse mode.
In terms of documenting this, one way to improve this is taking Brian's suggestions into account: expand that section and give practical examples, like the following:

This field sets the maximum length of a line in browse mode (in characters) for reading by line purposes.
Unlike documents in programs such as Word and Notepad, browse mode documents do not have a specific line length or a new line character to denote ends of lines.
Because of this, you can set arbitrary line lengths between 10 and 250 characters, and NVDA will try to split lines at word boundaries.
A side effect of this setting is that links and other elements will be split onto multiple browse mode lines.

I'm sure we can make it better, but at least the one I wrote above might be a useful starting point and captures the discussion so far.

-----Original Message-----
From: <> On Behalf Of Gene
Sent: Tuesday, October 20, 2020 9:23 AM
Subject: Re: [nvda] NVDA Settings Documentation

We'll see what others say but I know it applies to moving by lines. If I do something else that causes a line to be read, such as move by screen, with page up or down, or move to beginning or end of a document or tab, I would think it would apply in all those contexts, but we'll see what others say.

The intelligent question is a very interesting one and One I haven't thought of. Based on my experience, I don't recall ever having words split when I read in browse mode and the document has no such splitting, I think it is intelligent.

Just how much of such discussions should be in the user guide depends on what the purpose of the guide is. Perhaps some of these stipulations should be in some sort of document for developers or a wiki rather than in a user guide.

I wonder if this or that effect of a command my not be considered when discussing it by those who really know details. A wiki might be a good way to address this. I just found this very interesting discrepancy:
If I set the line length to a short amount, moving using k to move by link will cause an entire link to be read, no matter how long. Moving by arrow or tab and shift tab, will cause the line length stipulated to be read with more of the link being read as I move in the link. Its an interesting discrepancy and one I wonder if those knowledgeable in the matter have given any thought about as to implementation and what is desirable.

-----Original Message-----
From: Brian Vogel
Sent: Tuesday, October 20, 2020 10:53 AM
Subject: Re: [nvda] NVDA Settings Documentation

On Mon, Oct 19, 2020 at 10:32 PM, Gene wrote:
I would compare it to Word Wrap in Notepad except that you define the number of characters before the wrap occurs.- Gene, that is a good analogy. But what I want to know is what "reading command context(s)" this has an effect on. I'm imagining only line-by-line reading, but . . .

Having something under the setting such as, "If a document has a line longer than the number of characters you set, for line reading it will be split into multiple virtual lines of the maximum length you specify."

I also wonder if it's intelligent as far as splitting at word boundaries, not hard and fast character counts. Mid-word splits would make things potentially very ugly.

That setting, naked as it is, is not something that's intuitive, clearly, just based on this topic. And I'm not saying that you're arguing that it is, just restating the need for some context regarding settings where the effect of same is in no way immediately obvious to the uninitiated (and even the initiated, much later on).


Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041

It’s hard waking up and realizing it’s not always black and white.

~ Kelley Boorn

Join to automatically receive all group messages.