Samuel Thibault wrote:
Bill Haneman, le Thu 19 Oct 2006 00:19:04 +0100, a écrit :
Sorry, following up on my own email:
The unicode methods we use (we need these or their functional equivalents):
(easy ones first)
g_ucs4_to_utf8
g_utf8_strlen
g_utf8_offset_to_pointer
g_utf8_get_char
Bill Haneman, le Thu 19 Oct 2006 10:23:40 +0100, a écrit :
iconv should be fine for this
Actually, I don't think so - it doesn't include offset_to_pointer
That's something like:
long utf8_offset_to_pointer(char *str, long offset) {
iconv_t conv = iconv_open(wchar_t,utf-8);
Hi All:
I think a while back we had the discussion of rolling better i18n
support (e.g., a lot of the extra stuff that gnome-braille does) into
BrlTTY/BrlAPI, thus simplifying the setup and use of braille. It also
puts the functionality into the hands of people who are properly
resourced
Hi,
Willie Walker, le Thu 19 Oct 2006 09:03:13 -0400, a écrit :
I think a while back we had the discussion of rolling better i18n
support (e.g., a lot of the extra stuff that gnome-braille does) into
BrlTTY/BrlAPI, thus simplifying the setup and use of braille. It also
puts the functionality
the application to BrlTTY, and the application won't have control
on how it is browsed.
- In the application? Then, I don't see why it should be in BrlAPI:
that can be left in an upper layer like gnome-braille.
Samuel
___
gnome-accessibility-list mailing
Hi all
I have recently found out about gnome-braille, and what it is meant to
accomplish. Is there any intension of making this package
desktop-agnostic, so that other desktops like XFCE and KDE may also
benefit from its functionality?
--
Luke Yelavich
GPG key: 0xD06320CE
(http
Hi,
Luke Yelavich, le Thu 19 Oct 2006 08:40:04 +1000, a écrit :
I have recently found out about gnome-braille, and what it is meant to
accomplish. Is there any intension of making this package
desktop-agnostic, so that other desktops like XFCE and KDE may also
benefit from its
Samuel Thibault wrote:
As discussed a few months ago, gnome-braille depends on
- libgobject for contraction/language module management
- libglib for tricky stuff like unicode handling.
I don't have any objection to reworking this to remove
GObject, but it makes no sense to do that without
Sorry, following up on my own email:
The unicode methods we use (we need these or their functional equivalents):
(easy ones first)
g_ucs4_to_utf8
g_utf8_strlen
g_utf8_offset_to_pointer
g_utf8_get_char
g_utf8_next_char
g_unichar_to_utf8
(now the hard ones...)
g_unichar_break_type
Bill Haneman, le Thu 19 Oct 2006 00:19:04 +0100, a écrit :
Sorry, following up on my own email:
The unicode methods we use (we need these or their functional equivalents):
(easy ones first)
g_ucs4_to_utf8
g_utf8_strlen
g_utf8_offset_to_pointer
g_utf8_get_char
g_utf8_next_char
10 matches
Mail list logo
