After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 338111 - Braille encoding problem with displaying accents correctly.
Braille encoding problem with displaying accents correctly.
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: braille
0.2.x
Other All
: Normal normal
: 2.18.0
Assigned To: Willie Walker
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-11 18:08 UTC by Rich Burridge
Modified: 2008-07-22 19:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rich Burridge 2006-04-11 18:08:29 UTC
As reported on the gnome-accessibility-list:

> > I just installed orca and it seems to work well. 
> > I only have one problem. The speech works well but the braille display 
> > doesn't displays accents correctly (I am french). On my braille display, 
> > I can recognize the UTF8 encoding of the letter but not the 
> > one-character braille representation of the character. 

Do you mean that you are getting the byte UTF-8 representation of
characters instead of characters themselves? (I.e. you are getting "é"
instead of "é" ?)

It looks like orca doesn't care about charsets. If it always gets UTF-8
text, brl_module_writeText() should rather do

	if (brl_initialized) {
		brlapi_writeStruct ws = BRLAPI_WRITESTRUCT_INITIALIZER;
		ws.text = str;
		ws.charset = "UTF-8";
		ws.cursor = cursor;
		brlapi_write(&ws);
	}

BTW, orca doesn't check the result of brlapi_*() function. It should, and
call brlapi_perror() on errors.

...

The problem is that orca doesn't tell brlapi the charset of the text.
Brlapi then defaults to the charset of the current locale, which is
fr_FR@euro hence ISO-8859-15 on your box, I guess.

An easy way to fix it for now is to use an UTF-8 locale for running
orca:
LANG=fr_FR.UTF-8 orca
Comment 1 Willie Walker 2006-07-25 23:41:00 UTC
Orca is always dealing with UTF-8 because that's what we're getting from the AT-SPI.  We probably should convert all strings to unicode internally and then back out to whatever encoding our external services (e.g., speech, braille, etc.) expect.  

We could potentially modify the braille module in Orca (the one written in C) to use the structure as suggested, but that may cause us to have a compile time dependency on BrlTTY.  A possible workaround would be to have us define the structure ourselves.
Comment 2 Willie Walker 2006-09-15 18:28:47 UTC
Here's more e-mail on the subject:

http://mail.gnome.org/archives/orca-list/2006-May/msg00086.html

"Actually, I think you should use brlapi_writeStruct(...) instead of 
brlapi_writeText(...). because with brlapi_writeStruct() you can 
specify that the characters sent to brrapi are encoding in UTF-8 while 
it's not the case with brlapi_writeText(). 
When I run orca with locale set to UTF-8, there is no problem because 
brlapi use the current locale. But when I run orca with the locale set 
to ISO, brlapi considers the UTF-8 characters as ISO and I get a bad 
braille output. "
Comment 3 Willie Walker 2006-09-29 12:59:11 UTC
I tried implementing the above suggestion - it looks like something is still missing.  When I use the above code, I end up with an error and a core dump from brlapi_readKey (not even related to the write):

BrlAPI exception: Invalid packet on Write request of size 0 (X�)
...
(gdb) where
  • #0 __kernel_vsyscall
  • #1 *__GI_raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 *__GI_abort
    from /lib/tls/i686/cmov/libc.so.6
  • #3 brlapi_defaultExceptionHandler
    from /lib/libbrlapi.so
  • #4 brlapi_readPacketHeader
    from /lib/libbrlapi.so
  • #5 brlapi_readKey
    from /lib/libbrlapi.so
  • #6 brlapi_io_cb
    at brlmodule.c line 99

I think I narrowed this down to the charset.  If I don't specify one, I don't get the core dump.  I'll contact the BrlAPI developers to see if they have any advice.
Comment 4 Willie Walker 2006-10-02 17:29:16 UTC
Here's a message from a BrlAPI developer (Samuel Thibault) regarding this work:

"Version 3.7.2 indeed had a bug on this, while future version
3.8 won't.  This is a bit unfortunate because I don't see any sane way
to detect whether the underlying brlapi server has the bug or not.  A
somewhat hacky way would be to call brlapi_setExceptionHandler for
setting up an exception handler that would detect that the exception
comes from a write request, in which case try to disable the charset
announcement.  That said, we plan to provide a python binding in version
3.8 of brltty, so maybe it is just pointless to try to fix this now in a
hacky way while you will probably use the python binding in the future."

As such, I think the approach to take with this bug will be to wait until the official Python bindings for BrlTTY/BrlAPI are available.  At that time, we can instrument Orca to attempt to import the official bindings (and use them) or fallback to our own if they are not available.  

Until then, the recommended approach for Orca will be what was recommended previously:  use an UTF-8 locale for running orca (e.g., "LANG=fr_FR.UTF-8 orca").
Comment 5 Willie Walker 2006-10-17 00:10:21 UTC
I just checked in some code to use the new Python bindings being provided by the BrlTTY folks for BrlTTY 3.8.  This code also uses the writeStruct method and should hopefully help resolve this bug.
Comment 6 Olivier BERT 2006-10-19 13:54:21 UTC
I tested the braille output with the last orca CVS version and a recent checed out one of brltty.
It's working properly for me regardless of the used locale : UTF-8 or ISO-8859-1.
Accents are well displayed on the braille terminal. 

Thanks,
Comment 7 Willie Walker 2006-10-19 13:56:21 UTC
Thanks for testing!  Closing as FIXED.