-
-
Notifications
You must be signed in to change notification settings - Fork 631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for entry of computer braille via a braille keyboard #808
Comments
Comment 2 by sthibaul on 2010-10-28 11:17 |
Comment 3 by jteh (in reply to comment 2) on 2010-10-28 22:27
Yes, but many users use native (non-BRLTTY) NVDA drivers. That said, we do let BRLTTY pass key presses through to the OS as an interim solution. |
Comment 4 by orcauser on 2011-02-13 12:21 For example dot 1, in an english translation table is the letter a, but the same dot using the arabic translation table is the letter alif. Some arabic users have also requested for this feature. Thank you. |
Comment 5 by jschmude on 2011-04-26 21:27 |
Comment 6 by jteh on 2011-04-26 23:35 |
Comment 7 by waelzakareya on 2011-11-01 14:49 |
Comment 8 by zhaoyu on 2012-05-01 03:11 |
Comment 10 by jteh (in reply to comment 8) on 2012-06-12 06:15
This is a separate issue from this ticket, as this ticket relates to NVDA's native support for this. Your issue suggests BRLTTY isn't handling the braille input keys. Please ensure you're running the latest version of BRLTTY. Failing that, please test this with BRLTTY in a command prompt without NVDA running. If it doesn't work there, NVDA is not the cause. This is probably better discussed in a new ticket or on the nvda-dev email list. |
Comment 11 by jteh on 2012-10-19 07:49 |
Comment 12 by jteh on 2012-10-24 05:48 In high level terms (we can get to fine details later), there are several parts to this work:
|
Comment 13 by jteh on 2012-10-24 05:51 |
Comment 14 by ruifontes (in reply to comment 12) on 2012-10-24 12:00
You have Braille keyboard stand alone from Arpo, or Harpo, from Poland, named BraillePen; from ONCE, Spanish association of blind, I don't remember the name of the keybord and from Handytech. |
Comment 15 by ragb (in reply to comment 12) on 2012-10-24 13:48
As Rui Fontes Pointed out on comment:14, there seems exist some of these keyboards. Anyway, I don't think separating input and output imposes much more complexity than keeping the support only on the braille-display system, they seem somehow independent. With this, someone could probably find a way to use the qwerty keyboard to do braille input. So I'm for the separation of conserns from braille input and output. Of course braille display drivers have to implement the input gesture creation and so on.
Agreed.
Agreed. Not so good user experience.
This is similiar from what voiceover does on OSX. We select the language and if you want computer braille, uncontracted or whatever (it is not so well designed but the overall idea is good, we can do much better).
If liblouis had some way to determine table language, contraction, etc (further than naming convention) it woud easy implementation. But we can simply hardcode that. However there is the problem of existing many contraction tables for the same language, not only grade 1 and 2. For instance in portuguese there are two "standards" of braille contractin(althoug one is quit old but some people use and there is an unoficial liblouis table for it). O course option 1 would be easier, but I do believe we should try option 2, if we can think of a good user experience for this.
Boring part... :). |
Comment 16 by ragb (in reply to comment 13) on 2012-10-24 13:54
I'm not quit sure if we should do this. On one hand, it is fgood and elegant to have these combinations standardized, makes documentation easier and all maintenance. However, must notetakers and braille displays have their known set of combinations, either but the notetaker usage pattern or writen in the manuals, for other screen readers (i.g. Focus displays). Having too much different combinations from what users are used too may be sort of confusing. Even with some counter-arguments, I'd go for standardizing these cords, if possible. |
Comment 17 by jteh on 2012-10-24 23:33 One problem this doesn't solve is that some languages seem to have more than three grades. German seems to have computer braille and grades 0, 1 and 2. For these languages, the categories computer braille, uncontracted and contracted aren't sufficient, which creates somewhat of a problem. Maybe we need to have a variable number of grades per code, but that makes the UI for choosing grades inconsistent and thus difficult to manage. There may even be languages where computer braille isn't even a valid concept, which will cause serious problems for input. In that case, I guess input just has to use the first grade. Regarding cords, most displays have other buttons they can use for their own combinations. However, perhaps there are displays that only have braille keys. In that case, I guess they can choose not to use the unified cords support. I'm still not sure whether to map individual cords to separate gestures or not. Pure dots will all be mapped to one gesture and script, but cords may all have somewhat different functionality, so it may make sense to map them all to separate gestures so we have separate scripts for each cord. That one is tricky. |
Comment 18 by ragb (in reply to comment 17) on 2012-10-27 14:17
That's the problem for portuguese. Grade 1 is uncontracted, grade 2, contracted, and there is the other contracted standard (call it grade 3, as it doesn't seem to have and name for it).
Hmm. Ticky. But yes, grade 1 may work as fallback solution.
Yes. And there are some displays (as the braillenote) which intercept some cords and don't send them to the screen reader.
If I had to choose I'd say one gesture only. Because 1. With singular gestures with would had many duplicate mappings in everydisplay and 2. If some display wants to use a cord for diferent porposes then the standard, it could intercept it before creating a standard cord gesture. But as you say, that is quit tricky. |
Comment 19 by jteh (in reply to comment 18) on 2012-10-29 07:06
Is grade 3 part of the same braille standard or is it separate? For example, English U.S., English U.K. and UEBC all use the same computer braille table, but have different grade 1 and 2 tables. If the Portuguese contracted tables are actually separate standards, perhaps they should be treated as separate braille codes which happen to share the same computer braille and uncontracted tables.
Woops. I forgot these would have to be mapped for each display. I'd sort of imagined they'd be global, but you're right, it doesn't work like that. (Don't you love it when you forget how your own code works?)
That'd actually be easier to handle with multiple gestures, not one single gesture. Or am I misunderstanding you? |
Comment 20 by ragb (in reply to comment 19) on 2012-10-29 19:26
To be honest I don't know for sure. However, the portuguese braille standard entity (here in Portugal) is dead or something similar, which in practice means that there isn't anyone to tell if it is or not. I'll try talking with some people (mainly old guys that remeber the time when someone cared from actual braille standards) to know what they have to say.
Hmm, maybe you know it, it is me that don't :). We can bind the common gesture on the base braille display class, for instance, and then simply create these gestures on the concret classes. Of course this part means changing every display driver to create the same gestures when having dot patterns and space bar. Key names are different for most displays. bah... Boring.
No, you are right. Single gesture implies making almost a duplicate of the binding code again, which doesn't make sence. If some driver wants to override a cord gesture it can replace in the gesture map. |
Comment 21 by jteh on 2012-11-08 02:53
Things I'm not sure about:
|
Comment 22 by nvdakor on 2012-11-08 03:46 |
Comment 23 by ragb (in reply to comment 21) on 2012-11-09 13:52 The design seems quite good IMO. Just some comments.
I'd prefer a property. Dot 0 seems like dot1 but counting from zero (that is kind of funny but might confuse us developers more than anyone else).
Do you think we need specific gestures for brailleDisplays? Can't just a braille display send these gestures without subclassing, say "bk:space+dots"» Maybe I'm not getting it.
Agreed.
As I' understand it it will be bound tho space+dots gesture. If so, that makes sence, however having space+dot1+dot2, etc. gesture makes the pssibility to bind diferent scripts.
I thing braille displays should make that choice.
Hmm. If the display creates general gestures for chords (space+dot1+dot2) I think we can have some global object where to bind the scripts. Does that make sence?
But if it generates two gestures, don't have the problem of some keypress originating two diferent actions at the same time?
I'd vote for that. If some display want specific bindings it could still do it, when creating gestures. For chords I0m not sure. |
Comment 24 by jteh (in reply to comment 23) on 2012-11-10 03:06
It could be -1 or even the string " ". Of course, there'd be a SPACE constant anyway. It also just occurred to me that space alone probably needs to be mapped to the dots script, so having it as a property is kinda weird.
The idea behind specific gestures is that it can be overridden for a particular braille display if necessary. More explanation below.
No. NVDA tries all identifiers and stops at the first one that produces an action. That's how keyboard layouts work. A keyboard gesture has two identifiers; e.g. kb(desktop):NVDA+1 and kb:NVDA+1. This way, you can override for a specific layout, but you can still have generalised bindings. I realise this is a bit confusing, but it allows for a lot of flexibility. :) |
Comment 25 by ragb (in reply to comment 24) on 2012-11-10 13:23
Yes, makes sence. Even dot0 works, is just a matter of ones preference.
No, that is really nice. I'm looking now properly at |
Comment 26 by jteh on 2012-11-28 05:15 |
Comment 27 by ragb (in reply to comment 26) on 2012-11-28 14:17
I have some plans to do it but as things stand now I can't tell you when I might be able to start. So I'd say who comes to it first. |
Comment 28 by ragb on 2012-11-30 20:38 Thinking about this, I believe a quick prototype is quite simple to implement, at least for proof of concept. As it is rainning alot here and I can't much more I'm doing it right now. Will publish a branch shortly. |
Comment 29 by jteh on 2012-12-02 23:56 I'm beginning to wonder about the term "chord". Technically, a chord is just pressing any combination of keys; i.e. more than one key. So, even dot1+dot4 is a chord. Where did the usage of chord to mean space+dots actually come from? Is there any formal reference defining this? If not, I'm tempted to call that "chord" variable "isSpaceDown" or similar. Out of interest, when sending characters, is there any reason you didn't use In core.resetConfiguration, it probably isn't necessary to reset brailleInput, since it doesn't have any state at this point. |
Comment 30 by nvdakor on 2012-12-03 04:40 |
Comment 31 by ragb (in reply to comment 29) on 2012-12-03 12:58
Hmm. I'm not sure of this. This implementation as the benefit that we can have various gesture identifiers, that is:
The benefit I see is making it compatible with previous gesture maps, but that means some gestures confluct with braille input. The implementation is easier on the braille display driver side. But as I say, I'm not quite sure of this. I'm just stating arguments in favor of my implementation :). I can give some in favor of yours too :).
I think I've seen it on some braille notetaker manuals and such. But in truth !isSpaceDown, or !spaceBar or whatever sounds better and avoids confusion.
Two main reasons:
Hmm, your right. |
Comment 32 by jteh (in reply to comment 31) on 2012-12-03 22:15
This was discussed in comment:14 and comment:15. Separating Braille input and output requires a separate input gesture class.
You can do that with a separate gesture class as well. Braille displays that want Braille input will inherit from both. There's a bit of weird coupling in the gesture classes, but it still allows input to be used separately.
Ah. I wouldn't have thought Windows allowed this for any method, but if it works correctly with your method, that's fine. The only problem I see is that in future, we'll need to handle modifiers as well. |
Comment 80 by jteh (in reply to comment 79) on 2013-01-24 13:52
Oh. I think I know what you're getting at. The idea is that the driver should be able to override Braille input keys if they wish. However, if the driver doesn't map them, it will use global mappings. Currently, there is no global mapping of space+dots combinations, but the idea is that there should be eventually.
It works because the identifier is always output in Python set order. When handling gesture mappings containing the plus sign, NVDA normalises them into Python set order. So, as long as the driver returns identifiers in Python set order, they match. |
Comment 81 by jteh on 2013-01-24 13:56
The order Python uses for sets is indeterminate, but it will always be the same for a set containing the same values. We use this so that gesture identifiers match no matter what order you put their parts in. |
Comment 82 by jteh on 2013-01-24 13:58 |
Comment 83 by ragb (in reply to comment 76) on 2013-01-24 14:01
I think nothing is preventing it. Do you think we should document the displays that support input somehow specially (or those who still don't)? Anyway this can be handled separately. |
Comment 84 by halim (in reply to comment 82) on 2013-01-24 14:06
Can the brailledrivers add their own bindings as well? In other words, I like the current approach :-). |
Comment 85 by ragb (in reply to comment 82) on 2013-01-24 14:09
Hmm yes. Probably there are more drivers with those, further from !braillenote. I can take a look into it. |
Comment 86 by ragb on 2013-01-24 14:36
What do you think? |
Comment 87 by halim on 2013-01-24 14:46 However, I am not sure about the global keybindings. |
Comment 88 by aliminator on 2013-01-24 14:50 Theoretically, a global key binding should not differ from the ones of all (currently three) braille displays. |
Comment 89 by ragb (in reply to comment 87) on 2013-01-24 15:00
They are all inconsistent. Although we may end up changing usual keybindings (and so get some users confused) I believe we should leverage this oportunity to get all consistent, as much as possible. this is not easier in code (having most stuff globally), but even in documentation we only have one place to change. |
Comment 90 by aliminator on 2013-01-24 15:40 |
Comment 91 by nvdakor on 2013-01-24 18:07
|
Comment 92 by jteh (in reply to comment 84) on 2013-01-25 00:59
Are they documented for the display as a whole or for individual screen readers? How do they account for differences in screen reader concepts? In general:
That said, there seems to be a fair amount of resistance to global bindings. |
Comment 93 by jteh (in reply to comment 83) on 2013-01-25 01:20
I've already done this. Merged in be2e0fd. |
Comment 94 by ragb (in reply to comment 93) on 2013-01-25 11:33
Oh, yes, you did. I'm doing so much context switches these days :). Do you think I should open a ticket to handle global bindings? Although some resistance, I'm not convinced the current situation is anyway better.
Thank you :). |
Comment 95 by jteh (in reply to comment 94) on 2013-01-25 22:54
Please do. Personally, I prefer global bindings, but I don't actually own a display with Braille input keys, so it's probably unfair to enforce my opinion here. :) |
Comment 96 by jteh (in reply to comment 70) on 2013-01-30 07:00
This is fixed in liblouis 2.5.2, which is now in NVDA. |
Comment 97 by bdorer on 2015-07-24 21:08
|
Reported by mike.reiser on 2010-08-04 17:13
Nvda should be able to handle the input of braille from a braille keyboard on displays sutch as the refreshabraille 18, and translate it back to text so that people can type in braille if they wish and it still comes out in text. This is done by system access and other readers.
Blocked by #601
Blocking #1003, #2439
The text was updated successfully, but these errors were encountered: