Date   

Re: NVDA 2020.4 Beta 1 now available

Jim Pipczak
 

Hi all,

 

I believe that the beta should be installed into its own directory and not overwrite the existing full version. Your thoughts would be appreciated.

 

Thanks,

Jim

 

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Quentin Christensen
Sent: Thursday, 17 December 2020 9:14 AM
To: nvda@nvda.groups.io
Subject: [nvda] NVDA 2020.4 Beta 1 now available

 

Hi everyone,

 

Lazily copying my tweet - so you get everything in one sentence: NVDA 2020.4Beta1 is now available for testing, including  new Chinese Input methods, an update to Liblouis, the elements list now works in focus mode, context sensitive help pressing F1 in NVDA dialogs & heaps more!

 

 

As usual, please do report any issues on GitHub.

 

Kind regards

 

Quentin.

 

--

Quentin Christensen
Training and Support Manager

 


Jim Pipczak
Access Technology Service Development Lead
Client Services
Vision Australia
14 & 17 Barrett Street Kensington VIC 3031

M: +614 3375 7598 T: +613 8378 1243 (I: 344243)
E: Jim.Pipczak@...
www.visionaustralia.org


Vision Australia is committed to supporting the blind and low vision community through COVID-19. Find out about our response and free support resources online at www.visionaustralia.org/COVID19.



Re: Nvda beta still not keeping the setting to run at startup.

 

This happens here as well. For no reason I can track down, It will not start up on reboot.




On 12/21/2020 5:30 PM, Kevin Cussick via groups.io wrote:
Hi all, OK not really much of a problem but this has being going on now for years and it would be nice to see a fix for this nvda did not keep[ my setting to run at startup. but anyway got it fixed I installed the beta last week but my computer was not shut down.   until last night and when I booted up to night nvda was not running fixed for now. just thought I would report.






Nvda beta still not keeping the setting to run at startup.

Kevin Cussick
 

Hi all, OK not really much of a problem but this has being going on now for years and it would be nice to see a fix for this nvda did not keep[ my setting to run at startup. but anyway got it fixed I installed the beta last week but my computer was not shut down. until last night and when I booted up to night nvda was not running fixed for now. just thought I would report.


Re: The f1 key not bringing up sections properly in nvda 2020.4 beta 1

Dave Grossoehme
 

Good Day:  Beings they are using the f5 key to refresh the window to make the correction.  Is it possible to refresh the window in your instructions for when the f1 is pressed?  I don't know if that would work or not, but just thinking about the logic of this, I thought I would throw it out there for an idea.

Dave


On 12/16/2020 8:34 PM, Quentin Christensen wrote:
Thanks for reporting this.  We can see the issue, but don't have a solution at this stage.  On the basis that it "often" works, and even when it doesn't, the experience is no worse than it was previously, it will likely be left as is for 2020.4.

If someone experiencing this can see anything interesting in the log and feels like writing up an issue on GitHub, feel free to tag me so I can follow it.  Although I could replicate it when I first read the message, I was in the middle of something else, and now I was going to have a look at it, I can't replicate it :)

Quentin.

On Thu, Dec 17, 2020 at 12:38 PM molly the blind tech lover <brainardmolly@...> wrote:
Yep I've noticed that too.


-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of hurrikennyandopo ...
Sent: Wednesday, December 16, 2020 8:30 PM
To: nvda@groups.io
Subject: [nvda] The f1 key not bringing up sections properly in nvda 2020.4 beta 1

Hi guys


has any one else notice in nvda 2020.4 beta 1 when you go into the settings of nvda say you pick a section then press the F1 key it is meant to bring up information on that section or the setting you are looking at.


It seems to work some times bringing up the right section and other times it brings up the user manual.


but it seems also if the user manual comes up while looking at say a
settings if it does not come up correctly press the f5 key and the
sections seem to come up correctly.


What I mean if the setting you are looking at then press the f1 key and
the user manual comes up instead of the section you are looking at press
the f5 key and the section you are looking at comes up correctly.


I tried this in a couple of different browsers with the same result with
the user manual coming up instead of the right section until you preess
the f5 key to bring it up. I will have to do more playing around with it.


I am guessing it should come up correctly on all settings you find to
find out more into on not just the ones with check boxs.


Gene nz
















--
Quentin Christensen
Training and Support Manager


Re: How to study Japanese with NVDA?

Clement Chou
 

Sorry, should clarify. Meant to say that it's not entrely true that an
iphone or iPad is the best way to study Japanese... because Japanese
language support is in NVDA. Typing is also much easier on a computer
though admittedly I haven't played around much with Kanji selection on
an iphone. :) The mobile devices help though once you have an
understanding of Japanese braille and want to read something on the
go.

On 12/21/20, Clement Chou <chou.clement@gmail.com> wrote:
Not true. Again, see messages above. Braille support for the Japanese
languages is supported by NVDA.

On 12/21/20, Josh Kennedy <joshknnd1982@gmail.com> wrote:
The best way to study Japanese with a braille display is by using an
iPhone
or an iPad. Apple has fully implemented Japanese into its braille tables
for
youth with braille displays.






Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Dan Miner
 

I’ll take a closer look at your add-on.

 

For my usage of “cut & paste”, I am usually only pasting into a terminal.  And I do like that review mark & copy mechanism  For the larger copy needs, I was just redirecting to a file and yanking it open in something like notepad.  But I recently ran across a Windows CLI utility  called clip.exe which can remove all of that or shorten up the steps.  Works withinMSYS2, Cygwin, and WSL (must be clip.exe or aliased somehow to drop the .exe).

 

My wish list is a bit different, I want faster navigation tools for the terminal like there was back in the late 80s and early 90s.  A DOS screen reader back then was a terminal navigation ninja.  At a minimum, I need “review: go to top of screen” and “review: Find first occurrence” plus “review: Find Next”  A real nice to have would be prompt tracking and using a key combo to go backward and forward along the “prompt blocks”.  Then there is good vim within the terminal support… *sigh*

 

                Dan

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Monday, December 21, 2020 9:59 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

So for pasting things, I implemented a function that pastes into command prompt window even when context menu is not available. You can get it in my Tony's enhancements add-on - you'd need to enable it in the options, it is disabled by default.

For copying things out of command prompt I would still try to use review cursor. Or for copying large amounts of data, like large output of some command, I have some scripts where on Linux side I save it to a shared folder, and on Windows I periodically check that shared folder and copy things to clipboard as they appear.

But yeah, I wish there was a single good terminal solution, that works for NVDA. I think too few blind people work in terminals, so things are what they are. Sometimes I am thinking, someone should just implmement a simple terminal from within NVDA - something that would be accessible to begin with - in the end there is no rocket science in terminals....

--Tony

On 12/20/2020 10:23 PM, Dan Miner via groups.io wrote:

Well, I’ll take a peek and see if I can make any sense of it.

 

As for why, I find myself in WSL, mSYS2 and Cygwin depending on the task I am trying to do or testing.  It would be helpful to have a consistent terminal for them all and MinTTY is the closest I know of.  Regarding using Cmd console, it doesn’t work in ways needed for anything that prompts for a password in the Cygwin-style.  So, ssh, svn and “native git” will fail horribly and hair loss is soon to follow.

 

I’m actually a Linux guy trying to adapt to developing on Windows and for Windows.  Thus, I keep running back to UNIX-like land when my blood pressure gets too high.  *smiley*

 

The WSL standard terminal (basically Cmd but not quite) has an accessibility bug and will not respond to ALT+spacebar to open the system menu.  I couldn’t turn on cut and paste until recently  because my object navigation skills in NVDA reached a level I could find the system menu in the terminal UI object structure and get the mouse over there and simulate a left lick on it.

 

Now if I could figure out why the terminal audible bell doesn’t work for any minty (WSL, MSYS2 or Cygwin)…

    Dan

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Sunday, December 20, 2020 10:40 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

But also, just curious, why can't you use normal command prompt if things are working fine there? If I remember correctly MSYS can run in command prompt.

On a side note, I have been suffering from poor editing experience in command line too, mostly over ssh connections, soI have been thinking about an add-on that would provide a better way to edit command in command line - it will try to identify current text in command line and open it up in a fully accessible edit box, then after editing it will update it back in the command line. So whenever I have some free time, I'll work on this.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io wrote:

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: How to study Japanese with NVDA?

Clement Chou
 

Not true. Again, see messages above. Braille support for the Japanese
languages is supported by NVDA.

On 12/21/20, Josh Kennedy <joshknnd1982@gmail.com> wrote:
The best way to study Japanese with a braille display is by using an iPhone
or an iPad. Apple has fully implemented Japanese into its braille tables for
youth with braille displays.






Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Tony Malykh
 

So for pasting things, I implemented a function that pastes into command prompt window even when context menu is not available. You can get it in my Tony's enhancements add-on - you'd need to enable it in the options, it is disabled by default.

For copying things out of command prompt I would still try to use review cursor. Or for copying large amounts of data, like large output of some command, I have some scripts where on Linux side I save it to a shared folder, and on Windows I periodically check that shared folder and copy things to clipboard as they appear.

But yeah, I wish there was a single good terminal solution, that works for NVDA. I think too few blind people work in terminals, so things are what they are. Sometimes I am thinking, someone should just implmement a simple terminal from within NVDA - something that would be accessible to begin with - in the end there is no rocket science in terminals....

--Tony

On 12/20/2020 10:23 PM, Dan Miner via groups.io wrote:

Well, I’ll take a peek and see if I can make any sense of it.

 

As for why, I find myself in WSL, mSYS2 and Cygwin depending on the task I am trying to do or testing.  It would be helpful to have a consistent terminal for them all and MinTTY is the closest I know of.  Regarding using Cmd console, it doesn’t work in ways needed for anything that prompts for a password in the Cygwin-style.  So, ssh, svn and “native git” will fail horribly and hair loss is soon to follow.

 

I’m actually a Linux guy trying to adapt to developing on Windows and for Windows.  Thus, I keep running back to UNIX-like land when my blood pressure gets too high.  *smiley*

 

The WSL standard terminal (basically Cmd but not quite) has an accessibility bug and will not respond to ALT+spacebar to open the system menu.  I couldn’t turn on cut and paste until recently  because my object navigation skills in NVDA reached a level I could find the system menu in the terminal UI object structure and get the mouse over there and simulate a left lick on it.

 

Now if I could figure out why the terminal audible bell doesn’t work for any minty (WSL, MSYS2 or Cygwin)…

    Dan

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Sunday, December 20, 2020 10:40 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

But also, just curious, why can't you use normal command prompt if things are working fine there? If I remember correctly MSYS can run in command prompt.

On a side note, I have been suffering from poor editing experience in command line too, mostly over ssh connections, soI have been thinking about an add-on that would provide a better way to edit command in command line - it will try to identify current text in command line and open it up in a fully accessible edit box, then after editing it will update it back in the command line. So whenever I have some free time, I'll work on this.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io wrote:

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: How to study Japanese with NVDA?

Josh Kennedy
 

The best way to study Japanese with a braille display is by using an iPhone or an iPad. Apple has fully implemented Japanese into its braille tables for youth with braille displays.


Re: Advice wanted: Accessible twain document cameras that work with NVDA?

Milos Przic
 

Hello,
Since February I have been using a book scanner. It is an Iris Book scanner. Basically it is a small device, as long as the width of an a4 size paper. You put it on a page and drive it across the page. You can scan the document as a pdf, multi-page pdf or jpg into its memory, but also you can install its software for OCR, which works pretty well with NVDA, coppy a scanned page to clipboard or wherever you want and just read in realtime. It is how I use it, though as I said you can also scan documents on an sd card and then do an OCR with whichever software you want. I use it with its software as I like reading in realtime, because if a page is badly scanned I can just repeat it and read again. Also, for my research assignments, I must go to libraries and stuff so carying the laptop and the scanner, as the Iris one, turned out very practical.
Best,
          Miloš


Re: Advice wanted: Accessible twain document cameras that work with NVDA?

 

Well I don't have suggestions for actual devices.

However I just would like to remind all, that due to covid international shipping is a joke and prices really high.

Last year while ordering rare christ mas shopping items I spent a lot, now even if you had the cash to pay for shipping chances are they would take time to get here then be stuck at the docks.

And now with the latest australia cluster the restrictions on borders have gotten a lot more harsher.

So now its longer.

Right now I wouldn't go international at least not right now.

On 21/12/2020 12:20 pm, Gene wrote:
I don't follow buy and sell lists.  Others may have suggestions.

This thread may be stopped soon so you may need to join the NVDA chat list to get suggestions.

Gene
-----Original Message----- From: Chris Smart
Sent: Sunday, December 20, 2020 3:54 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Advice wanted: Accessible twain document cameras that work with NVDA?

Hi Gene.


So far, I've only tried advertising on Blind Bargains, Twitter, and a
couple of assistive devices groups on Facebook.


Which mailing lists would you recommend?


thanks

Chris



On 2020-12-20 4:43 p.m., Gene wrote:
Have you tried on the buy and sell lists for blind people?  Such a scanner isn't just an ordinary scanner.  It is specifically designed for scanning books without damaging the binding.  I don't know how good using a camera is for long scanning jobs like books.

You might have better luck if you had information, if it is true, regarding the superiority of using a book scanner than a camera for scanning a book.

Then, there are sighted people who want to digitize their book collections and who want to use a book scanner.  there may be some place you might post an ad to get the notice of those who want to digitize their book collections..

Gene
-----Original Message----- From: Chris Smart
Sent: Sunday, December 20, 2020 3:13 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Advice wanted: Accessible twain document cameras that work with NVDA?

I have a barely used Plustech Opticbook 4800 flatbed scanner here. Does
anyone think I will ever find a buyer for it? Just about everybody's
scanning/OCR needs are being met by the various smartphone apps these
days. Trying to sell this is harder than trying to sell a non-interpoint
Braille embosser. LOL




On 2020-12-20 3:40 p.m., hurrikennyandopo ... wrote:
Hi Mo.


Have you got a cell phone or smart phone with a camera. On the phone I have hear I have apps that can take a picture then ocr it to text then I can save it to other places or plug it into the computer and take the files off it in text form it would depend on the camera on the phone usually a 8mp is recommended for saying taking a picture of a form then ocring it to text.


there are both free and paid apps that can do that and I guess it would depend on the platform of your phone and what is in the app store just another idea.


Gene nz



On 21/12/2020 3:11 am, Mobeen Iqbal wrote:
Hello Everyone.

I am wondering if anyone can help with the following. I am looking for a document camera as desk space is limited. I do not want a camera which is tied to any specific software if it can be helped. I have previously tried solutions from visionaid and the Perl camera from freedom scientific, but I was never able to get them working with any software other than the software the devices come with.

I have seen document cameras for sale on Amazon, but it's unclear from the description if any of them work with scanning software such as DocuScan, Free OCR, Kurzweil etc. I don't mind what software the camera uses as long as it's accessible and performs OCR, and the unit is reasonably well built and isn't too pricey. does anyone have any ideas?

Very best wishes,

Mo.























Re: Advice wanted: Accessible twain document cameras that work with NVDA?

 

Actually you can.

Now you can just get a multifunction device.

Everything from the lowest inkjet to laser will have scan, fax, etc.

They do have stripped down ocr software, some have full versions or full versions registered for it.

The cheapest units have no software at all.

On 21/12/2020 10:30 am, Rob Hudson wrote:
I love those scanners. Too bad I cant afford it lol.

----- Original Message -----
From: "Chris Smart" <ve3rwj@winsystem.org>
To: nvda@nvda.groups.io
Date: Sun, 20 Dec 2020 16:13:40 -0500
Subject: Re: [nvda] Advice wanted: Accessible twain document cameras that work with NVDA?

I have a barely used Plustech Opticbook 4800 flatbed scanner here. Does
anyone think I will ever find a buyer for it? Just about everybody's
scanning/OCR needs are being met by the various smartphone apps these
days. Trying to sell this is harder than trying to sell a non-interpoint
Braille embosser. LOL




On 2020-12-20 3:40 p.m., hurrikennyandopo ... wrote:
Hi Mo.


Have you got a cell phone or smart phone with a camera. On the phone I
have hear I have apps that can take a picture then ocr it to text then
I can save it to other places or plug it into the computer and take
the files off it in text form it would depend on the camera on the
phone usually a 8mp is recommended for saying taking a picture of a
form then ocring it to text.


there are both free and paid apps that can do that and I guess it
would depend on the platform of your phone and what is in the app
store just another idea.


Gene nz



On 21/12/2020 3:11 am, Mobeen Iqbal wrote:
Hello Everyone.

I am wondering if anyone can help with the following. I am looking
for a document camera as desk space is limited. I do not want a
camera which is tied to any specific software if it can be helped. I
have previously tried solutions from visionaid and the Perl camera
from freedom scientific, but I was never able to get them working
with any software other than the software the devices come with.

I have seen document cameras for sale on Amazon, but it's unclear
from the description if any of them work with scanning software such
as DocuScan, Free OCR, Kurzweil etc. I don't mind what software the
camera uses as long as it's accessible and performs OCR, and the unit
is reasonably well built and isn't too pricey. does anyone have any
ideas?

Very best wishes,

Mo.













.


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Dan Miner
 

*sigh* How about that... that seems to clear it up and arrow keys are reading the characters. I would have never thought of that one.

Would anyone have a clue of an explanation for why this works?

Dan

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tyler Spivey
Sent: Sunday, December 20, 2020 8:29 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

No, it wasn't.
I don't use mintty at all, but I just tried it and got the same result as you.
Press alt space, Options, change the cursor type from Line to Underscore.

On 12/20/2020 7:07 PM, Dan Miner via groups.io wrote:
Was my question confusing or unclear?

I’d research deeper but I’m still pretty new to NVDA and still unsure
where to look in the codebase. The fact that backspace reads the
deleted character is encouraging and suggests the support code in
MinTTY or Putty for NVDA may just need a bit of adjustment. I’d do it
myself but need a helping hand getting started and pointed in the right direction.

Dan
On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io
<dminer84=yahoo.com@groups.io> wrote:



Just wanted to check to see if I am doing something wrong but I am
having troubles editing shell commands with minty in any environment
that uses it so far (Git for Windows, msys2 and WSLTTY).

I just installed the latest versions of Git for Windows, msys2 and
WSLTTY in the last week And ran across a “consistent” problem. I am
using bash in its default configuration from these packages (Ubuntu
20.04.1 for WSL2).

The initial set up to reproduce problem (keeping it simple):

Type: echo hi

Without hitting return and intending to edit that line, changing hi
(all lowercase) to Hi (with a capital H).

Press left arrow and “space” is spoken” and if you continue hitting
the left or right arrows, you will always get “space” said. So, it
is easy to get lost as none of the under lying characters are spoken.
Thus, I hit the speak current character (Keypad 2) and I get an
inconsistent spoken output of “space” or the character under the
cursor. Typical instances it will alternate between the two states
and one time I got repeating twice. To clarify, it would say
“space”, “space” “h”, “h”, and cycle back to “space”. But in this
simple example and movement, it will likely just alternate back and
forth between “space” and the letter (“I” in this case).

A partial workaround I have found is using bash’s readline advanced
editing keys. If I use control+left arrow and move by word, NVDA
will speak the words as expected. However, I still have to deal with
arrow key problem and speak character issues within the word of interest.

Is anyone seeing this behavior? It has been going on for many
versions of NVDA (easily a year).

As sanity check, the standard cmd console behaves as expected with
these features.

Dan


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Dan Miner
 

Well, I’ll take a peek and see if I can make any sense of it.

 

As for why, I find myself in WSL, mSYS2 and Cygwin depending on the task I am trying to do or testing.  It would be helpful to have a consistent terminal for them all and MinTTY is the closest I know of.  Regarding using Cmd console, it doesn’t work in ways needed for anything that prompts for a password in the Cygwin-style.  So, ssh, svn and “native git” will fail horribly and hair loss is soon to follow.

 

I’m actually a Linux guy trying to adapt to developing on Windows and for Windows.  Thus, I keep running back to UNIX-like land when my blood pressure gets too high.  *smiley*

 

The WSL standard terminal (basically Cmd but not quite) has an accessibility bug and will not respond to ALT+spacebar to open the system menu.  I couldn’t turn on cut and paste until recently  because my object navigation skills in NVDA reached a level I could find the system menu in the terminal UI object structure and get the mouse over there and simulate a left lick on it.

 

Now if I could figure out why the terminal audible bell doesn’t work for any minty (WSL, MSYS2 or Cygwin)…

    Dan

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Sunday, December 20, 2020 10:40 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

But also, just curious, why can't you use normal command prompt if things are working fine there? If I remember correctly MSYS can run in command prompt.

On a side note, I have been suffering from poor editing experience in command line too, mostly over ssh connections, soI have been thinking about an add-on that would provide a better way to edit command in command line - it will try to identify current text in command line and open it up in a fully accessible edit box, then after editing it will update it back in the command line. So whenever I have some free time, I'll work on this.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io wrote:

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Tony Malykh
 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

But also, just curious, why can't you use normal command prompt if things are working fine there? If I remember correctly MSYS can run in command prompt.

On a side note, I have been suffering from poor editing experience in command line too, mostly over ssh connections, soI have been thinking about an add-on that would provide a better way to edit command in command line - it will try to identify current text in command line and open it up in a fully accessible edit box, then after editing it will update it back in the command line. So whenever I have some free time, I'll work on this.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io wrote:

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Tony Malykh
 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

But also, just curious, why can't you use normal command prompt if things are working fine there? If I remember correctly MSYS can run in command prompt.

On a side note, I have been suffering from poor editing experience in command line too, mostly over ssh connections, soI have been thinking about an add-on that would provide a better way to edit command in command line - it will try to identify current text in command line and open it up in a fully accessible edit box, then after editing it will update it back in the command line. So whenever I have some free time, I'll work on this.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io wrote:

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Tyler Spivey
 

No, it wasn't.
I don't use mintty at all, but I just tried it and got the same result as you.
Press alt space, Options, change the cursor type from Line to Underscore.

On 12/20/2020 7:07 PM, Dan Miner via groups.io wrote:
Was my question confusing or unclear?
I’d research deeper but I’m still pretty new to NVDA and still unsure where to look in the codebase.  The fact that backspace reads the deleted character is encouraging and suggests the support code in MinTTY or Putty for NVDA may just need a bit of adjustment.  I’d do it myself but need a helping hand getting started and pointed in the right direction.
    Dan
On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io <dminer84=yahoo.com@groups.io> wrote:



Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

The initial set up to reproduce problem (keeping it simple):

Type: echo hi

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.
Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

As sanity check, the standard cmd console behaves as expected with these features.

    Dan


Re: Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

Dan Miner
 

Was my question confusing or unclear?

I’d research deeper but I’m still pretty new to NVDA and still unsure where to look in the codebase.  The fact that backspace reads the deleted character is encouraging and suggests the support code in MinTTY or Putty for NVDA may just need a bit of adjustment.  I’d do it myself but need a helping hand getting started and pointed in the right direction.

    Dan

On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io <dminer84@...> wrote:



Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan


Re: How to study Japanese with NVDA?

Clement Chou
 

Sorry. I meant environments as in talking to people, Japanese websites
and programs, etc. My computer is set to English by default. All you
need to is install the Japanese language pack. There's no need to
switch display language or anything that complicated. Install the
pack, and make sure Japanese is one of your selected input languages.
You can use both languages side by side just fine. Installing the
Japanese language packs will also let you access the one core voices.

On 12/20/20, Daniel Gartmann <dgartmann@outlook.com> wrote:

That is very interesting.

When you say "Japanese environments". Do you mean a computer that is solely
in Japanese, or are you using a computer that comes with English?

Daniel


-----Oprindelig meddelelse-----
Fra: nvda@nvda.groups.io <nvda@nvda.groups.io> På vegne af Clement Chou
Sendt: 20. december 2020 19:29
Til: nvda@nvda.groups.io
Emne: Re: [nvda] How to study Japanese with NVDA?

I'm fluent in Japanese and use NVDA in Japanese environments regularly.
Japanese braille is indeed supported. So long as the braille display is
connected and the Japanese version of NVDA is instaled, it should work. I
had the base version of NVDA on my computer originally then slapped the
Japanese one on top of it. Feel free to contact me off list or ask the
student to contact me, and I'd love to try and help.
The command to switch between hiragana and katana is still
ctrl+capslock for hiragana and alt+capslock for Katakana. Typing in
Japanese is easy to do, provided you've studied Kanji and know the one you
want, because the descriptions of the candidate are all in Japanese of
course. NVDAJP's character description activated with numpad 2 on the
desktop keyboard layout is also very useful for learning what kanji is used
in a word.

For synthesizers, thereare tons of them out there, but I'd recommend either
any of the windows 1 core voices or protalker as a starting point since
they're both free.

On 12/20/20, Dan Miner via groups.io <dminer84=yahoo.com@groups.io> wrote:
I would like to know this as well because I am trying to teach myself
Japanese. As I understand it, the braille system is based on kana.
NVDA I believe uses the louis braille library and so it might be as
easy as loading that “code page” and converting the text into some
braille format just like we do for English. But it would be nice to
have automagic switching in a web page with a language markup on the
passages.

Anyway, I would like to know more about this too.
Dan


On Dec 20, 2020, at 6:52 AM, Marco Oros <marco.oros93@gmail.com> wrote:


OK.

Here is one problem:

Japanese has a japanese braille, but It is not implemented to NVDA,
because of three alphabets, which are used in Japanese.

About speech synthesizers, I know that Windows has some japanese
voices, but I don't know, how to new japanese keyboard layout.

I have asked this last question, because keys to switch keyboard
layout were changed. I think on japanese characters, not switch from
one language to another language. For example, I would like to switch
from Hiragana to Katakana and Romaji. About Kanji letters, You can
press twice time spacebar and select one kanji letter, press enter
and It'll be written down.

That's everything, which I know about japanese keyboard layout.

Last note:

I am from Slovakia, not from Japan, but I am interrested to various
languages.



Dňa 20. 12. 2020 o 14:32 Daniel Gartmann napísal(a):

Hello

I have been asked to help a blind University student who is studying
Japanese. The goal is to be able to read on a Braille display
connected to a Windows10 computer.

Anybody with experience in studying Japanese on a system in e.g.
English or some other language?

I have been told that in order for Japanese Braille to work
properly, the entire computer needs to be in Japanese. We are using
the computer either in Danish or in English.

I tried running a portable copy of NVDA from
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nvda.jp%2F&;data=04%7C01%7C%7C77a6cb0cd7be431412c608d8a5151a32%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637440857330956458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=P2rG7ihSEvs4MMSlzzVTo4Vi%2B3OT1URrqCLQTRckcgY%3D&amp;reserved=0,
but it didn’t start right away.

So, hope someone with experience in this would be willing to share
their knowledge.

Thanks in advance.

Daniel














Re: Advice wanted: Accessible twain document cameras that work with NVDA?

Gene
 

I don't follow buy and sell lists. Others may have suggestions.

This thread may be stopped soon so you may need to join the NVDA chat list to get suggestions.

Gene

-----Original Message-----
From: Chris Smart
Sent: Sunday, December 20, 2020 3:54 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Advice wanted: Accessible twain document cameras that work with NVDA?

Hi Gene.


So far, I've only tried advertising on Blind Bargains, Twitter, and a
couple of assistive devices groups on Facebook.


Which mailing lists would you recommend?


thanks

Chris



On 2020-12-20 4:43 p.m., Gene wrote:
Have you tried on the buy and sell lists for blind people? Such a scanner isn't just an ordinary scanner. It is specifically designed for scanning books without damaging the binding. I don't know how good using a camera is for long scanning jobs like books.

You might have better luck if you had information, if it is true, regarding the superiority of using a book scanner than a camera for scanning a book.

Then, there are sighted people who want to digitize their book collections and who want to use a book scanner. there may be some place you might post an ad to get the notice of those who want to digitize their book collections..

Gene
-----Original Message----- From: Chris Smart
Sent: Sunday, December 20, 2020 3:13 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Advice wanted: Accessible twain document cameras that work with NVDA?

I have a barely used Plustech Opticbook 4800 flatbed scanner here. Does
anyone think I will ever find a buyer for it? Just about everybody's
scanning/OCR needs are being met by the various smartphone apps these
days. Trying to sell this is harder than trying to sell a non-interpoint
Braille embosser. LOL




On 2020-12-20 3:40 p.m., hurrikennyandopo ... wrote:
Hi Mo.


Have you got a cell phone or smart phone with a camera. On the phone I have hear I have apps that can take a picture then ocr it to text then I can save it to other places or plug it into the computer and take the files off it in text form it would depend on the camera on the phone usually a 8mp is recommended for saying taking a picture of a form then ocring it to text.


there are both free and paid apps that can do that and I guess it would depend on the platform of your phone and what is in the app store just another idea.


Gene nz



On 21/12/2020 3:11 am, Mobeen Iqbal wrote:
Hello Everyone.

I am wondering if anyone can help with the following. I am looking for a document camera as desk space is limited. I do not want a camera which is tied to any specific software if it can be helped. I have previously tried solutions from visionaid and the Perl camera from freedom scientific, but I was never able to get them working with any software other than the software the devices come with.

I have seen document cameras for sale on Amazon, but it's unclear from the description if any of them work with scanning software such as DocuScan, Free OCR, Kurzweil etc. I don't mind what software the camera uses as long as it's accessible and performs OCR, and the unit is reasonably well built and isn't too pricey. does anyone have any ideas?

Very best wishes,

Mo.
















6781 - 6800 of 86626