On 9/22/22 18:24, peter dalgaard wrote:
Tomas Kalibera has related that he has some scars from fighting with some unexpected
interactions between UTF-8 and the GraphApp library that is used for RGui and I think he
said that screen readers were involved. I wouldn't be surprised if this is a leftover
issue. (This is obviously a kind of issue that non-blind users don't "see" :-)
).
Yes, that's almost surely related. GraphApp uses very different code for
handling Windows messages in a multi-byte locale and single-byte locale,
so switching to UTF-8 changed a lot. The multi-byte version hasn't been
used that much before, and hence a number of bugs showed up after the
switch.
Would it work for you to use the terminal application (the "DOS box", or
whatever it is called these days) until the issue gets fixed?
In general, I would expect your go-to guy for blindness-related issues to be
Jonathon Godfrey (cc'ed). Perhaps he can offer some advice.
There were two issues reported already with other software controlling a
running window of Rgui, one was fixed in 4.2.1 (SendInput() for text
injection didn't work in a multi-byte locale). Another hopefully was
fixed in the application (it was using WM_CHAR messages to inject text,
but that is not the right way to do this and fixing that to work as
before would bee too difficult; the way recommended by Microsoft is
SendInput, which now works).
It would be good if we could debug and fix this, on either end. For that
we need to find out how the concrete screen reading applications
communicate with Rgui window. Ideally I would have a tiny example which
I could build and run on my Windows machine, without any special
hardware, which would demonstrate the problem. Or, at least if the
source code is available and we could have a look. Even if the
application is closed source, the Windows messages could be captured by
some tracing software to debug the protocol, and one could try writing
an example/reproduction of the problem based on that.
Hopefully someone reading this could help with producing such an
example, and then I could try investigating why it stopped working and
fix, if possible.
In principle, we cannot yet assume that all Windows systems are new
enough to support UTF-8 as the system encoding (also called ACP in
Windows), so R support for running on Windows in a single-byte locale
still cannot be removed, it will almost surely stay at least in 4.3. So,
what I could definitely do is create an alternative build of Rgui which
will use single-byte locale (like the older versions of R) even on new
Windows systems. That alternatively build might be removed later if we
decide to require UTF-8, but, temporarily it might help. Still, I hope
we can debug and fix this to work properly when R is running with UTF-8
as the native encoding.
I hope for now you can get away with 4.1.3. In principle, building Rgui
to run R using single-byte locale is trivial (one just changes the
manifest file for Rgui), so if a temporary solution was needed very
fast, one can just do that and have a custom build before any new R
release. Also, well, an older version of Windows 10 (or even older
Windows) that don't support UTF-8 as the native encoding would do the same.
Best
Tomas
-pd
On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel <r-devel@r-project.org>
wrote:
Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this is the
right place to ask about it. If it's not, I'm hoping someone can point me in
the right direction.
I'm blind and have been using R for about 11 years now. The base build
available on CRAN is quite accessible and works pretty well with screen-reading
software such as JAWS for Windows and NVDA. R-studio is not accessible which
appears to have something to do with the version of QT it uses, but that's not
relevant as I don't use it.
Recently I installed R 4.2.1 (I tend to upgrade two or three times a year and
this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest version more
or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R cursor
and behaves as though the cursor is near the top left of the R application
window. Practically, this means I can't tell what characters I'm passing over
when cursoring left and right, nor can I hear what character is being deleted
when the backspace is pressed. Most importantly, I can't tell where the
insertion point is. This is a major regression in the ability to work with and
edit the command line in the R console. There are ways of actually viewing the
command line but the way I work is frequently calling up a previous command and
making a change so as to not have to type the whole command again.
I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out exactly when
things went awry and the issue first appeared in R 4.2.0.
Looking through the release notes, the only things mentioned that seem likely
to be relevant are the following:
• R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle had a
different layout and can no longer be used.
and
• R uses UTF-8 as the native encoding on recent Windows systems (at least
Windows 10 version 1903, Windows Server 2022 or Windows Server 1903). As a part
of this change, R uses UCRT as the C runtime. UCRT should be installed manually
on systems older than Windows 10 or Windows Server 2016 before installing
R.
I can't really see how changing to utf-8 as the native encoding would produce
the behaviour I'm seeing, so I am guessing that the change in TCL/TK might be
the culprit.
I'm hoping that someone will be able to help shed some light on what's going on
here.
Thanks a lot,
Andrew.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
