This was discovered on Linux; I have no idea if it also affects Mac.

Sometimes tdsr or pyte interprets console output as something other than UTF-8.

$ python3

print('\xe4')

You'll hear tdsr say a umlaut, and that's what was printed.
Use the review keys to review the line of output, and you'll hear
something completely different: sigma.
It turns out that the byte 0xe4 is sigma in the old CP-437 character set.

Next:

print('\u0134')

You'll hear j circumflex, which is what was printed.
Review the line of output by character, and indeed, capital j circumflex
is what is there.

So it's as though for unicodes under 0x100,
pyte (or something else) is treating their least significant byte as a
character in CP-437 and then translating them to UTF8 to be spoken,
whereas unicode characters >= 0x100 are handled properly.

Currently, all navigation commands are bound by the current screen. This makes it impossible to check what is not on the screen yet without using a screen reader to scroll.

Hello.

Thank you for creating a useful light weight multi platform screen reader.

I am running tdsr in termux https://turmux.dev on an Android 14 phone. It ran fine under Android 13.
However, when I tried running tdsr for the first time after upgrading to Android 14, I got:

~/tdsr$ ./tdsr --debug
Traceback (most recent call last):
File "/data/data/com.termux/files/home/tdsr/./tdsr", line 944, in
main()
File "/data/data/com.termux/files/home/tdsr/./tdsr", line 350, in main
synth.start()
File "/data/data/com.termux/files/home/tdsr/./tdsr", line 285, in start
self.pipe = subprocess.Popen(self.speech_server, stdin=subprocess.PIPE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/data/data/com.termux/files/usr/lib/python3.11/subprocess.py", line 1026, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "/data/data/com.termux/files/usr/lib/python3.11/subprocess.py", line 1951, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/data/data/com.termux/files/home/tdsr/speechdispatcher'

However, the speechdispatcher script is very much present:

~/tdsr$ ls -l /data/data/com.termux/files/home/tdsr/speechdispatcher
-rwx------ 1 u0_a218 u0_a218 1146 Feb 23 23:19 /data/data/com.termux/files/home/tdsr/speechdispatcher

Separately, both the tdsr and speechdispatcher scripts do run. If I do:

~/tdsr$ ./tdsr -s cat >test

I get:

stdsr, presented by Lighthouse of San Francisco
/tdsr$ s/tdsr $
x
sexit

If I do:

~/tdsr$ echo "sHello world!" |./speechdispatcher

My phone says "hello world!"

All that tdsr.log contains is:

2024-02-23 21:17:11,668 - tdsr - DEBUG - TDSR started

I've upgraded all termux packages with pkg upgrade. I removed the tdsr directory, and $HOME/.tdsr.cfg. I cloned tdsr fresh from the repository, and ran:

pip3 install -Ur requirements.txt

with no errors, but the results stay the same as shown above.
I've made sure that the termux app has been granted all the permissions that can be granted to it.

I'm currently not as fluent in Python as I would like to be, so am not sure how else to debug this. Since I suspect this to be a problem between Android 14 and termux, I can open an issue in termux's issue tracker. I'm hoping however to be able to provide more than asking someone there familiar with termux internals and Python to install tdsr, and to figure out what's going on. I don't know if the problem is that speechdispatcher can't be opened for some reason, or that the pipe between tdsr and speechdispatcher can't be open for some reason.

Below is the output from logcat when running tdsr. My educated guess is the last line is the key to the problem, but I don't know what to do with that bit of information.
If it makes sense to someone here, great. If not, then it will be available if I link to this issue from the termux issue I would create in the future if we can't resolve it.

02-24 16:33:40.335 27410 27410 W bash : type=1400 audit(0.0:56875): avc: granted { execute } for name="tdsr" dev="dm-63" ino=101827 scontext=u:r:untrusted_app_27:s0:c218,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c218,c256,c512,c768 tclass=file app=com.termux
02-24 16:33:40.339 27410 27410 W bash : type=1400 audit(0.0:56876): avc: granted { execute } for name="coreutils" dev="dm-63" ino=66664 scontext=u:r:untrusted_app_27:s0:c218,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c218,c256,c512,c768 tclass=file app=com.termux
02-24 16:33:40.339 27410 27410 W bash : type=1400 audit(0.0:56877): avc: granted { execute_no_trans } for path="/data/data/com.termux/files/usr/bin/coreutils" dev="dm-63" ino=66664 scontext=u:r:untrusted_app_27:s0:c218,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c218,c256,c512,c768 tclass=file app=com.termux
02-24 16:33:40.339 27410 27410 W env : type=1400 audit(0.0:56878): avc: granted { execute } for path="/data/data/com.termux/files/usr/bin/coreutils" dev="dm-63" ino=66664 scontext=u:r:untrusted_app_27:s0:c218,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c218,c256,c512,c768 tclass=file app=com.termux
02-24 16:33:40.339 27410 27410 W env : type=1400 audit(0.0:56879): avc: denied { search } for name="tests" dev="dm-63" ino=106 scontext=u:r:untrusted_app_27:s0:c218,c256,c512,c768 tcontext=u:object_r:shell_test_data_file:s0 tclass=dir permissive=0 app=com.termux

I'm providing the output of termux-info below in case it proves helpful:

~/tdsr$ termux-info
Termux Variables:
TERMUX_APK_RELEASE=GITHUB
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=7334
TERMUX_IS_DEBUGGABLE_BUILD=1
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:

sources.list

deb https://mirror.fcix.net/termux/termux-main stable main

root-repo (sources.list.d/root.list)

deb https://mirror.fcix.net/termux/termux-root root stable
Updatable packages:
All packages up to date
termux-tools version:
1.40.6
Android version:
14
Kernel build information:
Linux localhost 5.10.177-android13-4-00003-ga7208022a7ea-ab10815828 #1 SMP PREEMPT Fri Sep 15 16:40:54 UTC 2023 aarch64 Android
Device manufacturer:
Google
Device model:
Pixel 6a
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so

Any help in figuring out what's going on here, and getting to the bottom of this is much appreciated. I will be happy to run additional tests, and provide more information.

Hi.
Please test it against the new beta, macOS 13.0, and you will get constant crashes, especially while typing.

what about m1 macbooks?

critical error, after pulling the repo, and using nano, I get a crash.

tried all shells, but it's problem everywhere, macOS version, latest.

It's behavior that my muscle memory expects. I'd be happy to work on
a patch unless you have a strong objection.

any plan to include braille support?

Emacspeak already has a very robust protocol for implementing speech servers. It would be great to implement this for tdsr.
some reasons for doing this include:

1. Ability to use the same synths for emacspeak and tdsr.
2. Leveraging existing code for various platforms.
3. Ease of writing new speech synths for both packages.

looks like tdsr is broken. i follow all instructions. but allways get the error about foundation module not found

Howdy guys,

My name is chrys.
i see also work on a CLI screenreader for Mac and linux. That is also our current project.
maybe we can put us together to improve our forces? I think it would make sense.
We currently work on fenrir (also written in python).
https://github.com/chrys87/fenrir
its a little bit more structured and and in a more improved state (there is a plugin and driver infrastruture for example with a lot of functionalty). but for sure we can learn from each other or concentrate to a single project?
I also currently try to form a "dev team" for linux/ BSD/ MAC accessiblity relevant tasks.
Maybe somebody of you is interested in?
sorry for bothering you :) for sure you do it like me just for fun. But i also want to help a little and give the coimmunity some useful tools to improve the usiblity as visual impaired or blind people.
i m visal impaired, many of my frinds and my girlfrind are blind and need those tools.

what do you think about to join and improve our forces?

i mostly hang around in IRC:
server:
irc.netwirc.tk
room
#a11y

cheers chrys

Just pulled in the latest version of TTDSR and am now unable to use it as it keeps saying that it cannot find the foundation module from line 4. I've reinstalled python3 using homebrew, deleted and cloned the tdsr repository and run the pip3 installation for requirements a few times now, but just cannot get tdsr to work anymore after this latest update. Found using MacOS 12.2.1 on a 2020 Intel MacBook Pro; all was working perfectly fine this morning until I checked for a tdsr update and pulled in the latest version.

Fairly simple. Pressing control does not interrupt speech, as you would expect. However, any other key does interrupt speech just fine. Fairly sure this worked under Monterey and earlier. Have checked that both pyte and pyobjc are both latest versions, from pip.

To see this in action, try to make TDSR read a single letter, either by
typing while character echo is on or while deleting a character. You'll
notice that the rate used is the default one, not the one set in the
configuration. This also happens when reading by character in something
like Nano.
A temperary workaround is to map all the ascii codes in your config to
multi-letter versions (for example 65 = eh), but that breaks the pitch
change for capitalization, and is also annoying.
macOS Ventura

tdsr crashes if the thing displayed on the screen is not well-formed UTF-8.
To reproduce: start tdsr, and run:
echo -ne '\xf3'
to see a traceback.

Spotted on both Mac and Linux.

Don't know of a really clean fix for this at the moment.

1. python2 -c 'print repr(raw_input())'
2. Type: ĉ
3. Press enter
   Output:
   '\xc4\x89'

Repeat this, pressing backspace after the ĉ.
Output:
'\xc4'

In the second case, I expect to get an empty string, and this is the case without tdsr.

A colleague is using TDSR while learning programming and it's been wonderful so far. Some of the commands he runs give a lot of output e.g pytest so I added a plugin architecture to specify custom shortcuts and parse the output to something nicer. So instead of all the irrelevant stuff from pytest it will now pull out the test count, the error message and the line of code that triggered it e.g. "1 failed, 5 passed, AttributeError: 'NoneType' object has no attribute 'group', code is results = parse_output(lines)"

You can check the diff of my fork, although it has some extra things like condensing symbols.

Is this something you'd be interesting in having? I understand if you want to keep TDSR simple but if you like the idea I can tidy it up a bit and make a PR :)

This isn't strictly about tdsr. I'm the author of WezTerm and I'm currently thinking about what a first-class terminal screen reader experience might look like.

I don't know much about screen readers or what the state of the art is for people that use them with terminal emulators.
I found TDSR when googling; it seems to be the most modern implementation.

I'm interested to hear about what's important for the experience, and what things are difficult or perhaps impossible to do in tdsr that might be possible to do in the terminal emulator itself.

Currently TDSR reads symbols one by one e.g for Pytest output the total tests is surrounded by equals symbols so TDSR reads "equals equals equals equals equals". Some screen readers tell you the count and the symbols e.g. "5 equals". It would be cool if TDSR did that too. I've made a commit on my fork and it works well. I could make it optional based on config if that's preferred. What do you think?