Samuel Thibault <[EMAIL PROTECTED]> writes: > Jason White, le Fri 28 Nov 2008 19:42:50 +1100, a écrit : >> I'll gladly submit a bug report. Even if it's using framebuffer >> console, BRLTTY should still work, right?
Jason, yes, BRLTTY works fine with kernel based framebuffer consoles. I am actually using this at work since a few days with a 1024x768 screen resolution (configured via fbset) and a 12x24 font (from console-terminus) to achieve a 85x32 terminal. This is useful since I happen to use a 88-cell braille display, and now that BRLTTY has configurable status cell emulation, I suddenly was able to conventiently add 5 more characters horizontally to my terminal setup. > but a framebuffer running bogl-bterm doesn't, because in that case that's > bogl-bterm that handles everything, and it doesn't expose the text to brltty. This is a problem we know about since several years now. The ultimate root cause of the issue is that the Linux kernel virtual terminal layer can only handle 512 different glyphs in a terminal at once. With hacks (composite fonts) this can be useful (to a limited extend) even with unicode characters, but to achieve full unicode support, user space terminal emulators (bogl-term and friends) had to be written. These terminal emulators do their own drawing on top of the Linux framebuffer interface and therefore allow for support of the full unicode range. Now we have a very typical accessibility problem that has come up in various variations in the past. Since a program does its own drawing and no longer uses the typical infrastructure for a given job, ATs fail. In this case, we can't really blame the people that wrote these tools since the Linux kernel is actually lacking a fundamental capability these programs provide. > There is a long thread about it on debian-boot. I didn't check into it, but I am sure the only real solution is for someone to step up and implement BrlAPI support for the most popular framebuffer terminal emulators. Sounds like a few days of work, depending on how good the internal infrastructure of the project at hand already is. Someone just needs to want to do this, allocate the timeslot and start doing it. Hey, christmas holiday time is near! P.S.: Actually, it could be a little bit easier to extend the existing "Screen" screen driver in BRLTTY or implement a new screen driver for communicating with bogl-term and friends. Its not like this hasn't already been done in the past. The "Screen" screen driver has been the only way to work with BRLTTY on all BSDs since there, the kernel totally lacks a way for user space to access the virtual terminal content. On Linux, we're actually lucky to have /dev/vcs*. Its just that it doesn't support full unicode. Take the chinese language for instance, /dev/vcs* couldn't be used to represent it, while BRLTTY now actually has tables for (all?) the chinese unicode characters. Users from that area would have to use bogl-term or similar anyway to even be able to have all their various characters representable, but BRLTTY currently can't speak to bogl-term yet. There are even arguments and reasons for a typical console braille user from a western country wanting to use a framebuffer terminal emulator to achieve full unicode support. While you often can represent most of the characters you see in your daily work with a 512-glyph font, there are situations (especially when surfing the web or reading documents that make use of unicode characters in general) where it would be desireable to be able to map a lot more than just 512 characters back to braille. Now that BRLTTY has full unicode support, we are in the situation that we could define a lot of useful mappings, but most of them are never going to be used because of this 512-glyph limitation. So as crazy as it might sound, the ordinary blind braille user might want to use a user-space framebuffer terminal emulator to get full unicode support in the console. -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/> .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
