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 contracted braille via a braille keyboard #2439
Comments
Comment 2 by ragb on 2012-07-08 14:47
Anyway, this is realy something that I'd like to have in NVDA (or anywhere else), but is something not trivial, in my opinion. |
Comment 3 by Ahiiron on 2012-07-12 17:35 |
Comment 4 by MHameed on 2012-07-13 13:23 |
Comment 5 by nvdakor on 2012-07-13 16:36 |
Comment 6 by ragb on 2012-12-04 00:55 When implementing #808 I tried to use a literary braille table for back-translation. Of course the results were poor, since the goal for that ticket was computer braille input. In the meantime, I came with the following simple idea that might be a good starting point for this. (this requires familiarity with the work beeing developed on #808 and the !brailleInput branch). Instead of translating a character as soon as a braille keyboard command is entered, we can back-translated the braille dots only when a full word is entered, that is when a space bar is pressed (this can be argued). Moreover, if no space bar is pressed after a while, we can assume that the input is done and the back-translation should be sent to the operating system anyway (this requires a timer). This way we can translate full words (or more characters at a time) instead of just one. The test being entered is not spoken or shown in braille until is sent, but when typing braille one can't read it at the same time anyway. Steps for integrating this in #808 would be something like:
I implemented a scatch prototype (I need to merge it with new !brailleInput changes) and it seems to work reasonably with english grade 1 braille. With portuguese is a nightmare :(. I'm using 1 second for the described timer, but I believe this value most be configurable. I supose this is simliar to what VoiceOver on the Mac is doing, but I have no way to confirm it. However, I believe we can do much better and refine this simple algorithm, specially if liblouis evolves in back-translation. |
Comment 7 by jteh on 2012-12-04 01:18 |
Comment 8 by jteh on 2012-12-04 01:20 |
Comment 9 by ragb (in reply to comment 7) on 2012-12-04 12:58
I think there should be a way to stop the timeout, that is, only consider the word entered when the user presses space or enter. We could have too different options: either provide a command to stop the timer (some chord, per haps), or make possible to configure the timout to infinity (no timeout :)). However that rings another problem. If the user is writing a word and types something by mistake, he should be able to delete characters (using dot7, maybe), and type the right patterns to finish the word. This obviously makes the need for showing the user what's being entered...
Yes. I can't come with a good solution to this. Do you think having a custom braille region showing when the user is entering a word is possible? That region would contain the input being entered (in braille) and is to be updated whenever the user enters or deletes a braille character. I don't know if this brings a good user experience or not, but that is what I can think of. It's somehow resembles input composition. These are the difficult questions i don't have answers for, but they need to be considered. Me neither. However, I believe with some brainstorming we can come with better solutions from most of what is available (i.g. IOS). |
Comment 10 by nvdakor on 2012-12-04 15:06
|
Comment 11 by jteh (in reply to comment 10) on 2012-12-07 17:04
It's significantly simpler for notetakers to do this because the entire platform is custom designed. For a screen reader, there are three problems:
One other problem for NVDA is that liblouis can't tell us what individual special Braille cells mean. For example, it can't tell us that dots 3-4 is the "st" sign unless it's part of a full translation.
That's because of the timeout.
Out of interest, why is a timeout more of a problem for some languages than others? Your ideas about special dot decisions in liblouis would require some pretty significant changes both to liblouis itself and all of its tables. I'm not necessarily saying it's a bad idea, but it'd probably be a very long way off. |
If liblouis is to be used to do the backtranslation it may be a good idea to investigate how well it performs these days. I know the Dutch (nl-NL and nl-BE) tables aren't written for backtranslation and probably fail for the parts that use multi-pass rules. (Side question: why does NVDA disable the multi-pass facilities when forward translating?) |
liblouis is all we have. I take your point, though. I guess if it's really that bad, we'll have to push for improvements to the tables and/or liblouis before we can release this.
Because multi-pass breaks the input/output position mapping. I have had grand ideas of completely rewriting that position mapping code for a while, but I've never gotten to it. Arend Arends contributed a patch for this, but it hasn't been integrated yet and I believe there are some outstanding concerns. |
The next release of liblouis is planned for next Monday and should include the patches contributed by Arend, Bue, etc. I’d be happy to look into backtranslation for the Dutch tables, though if it requires extensive code changes it’ll have to wait till the new year. From: James Teh [mailto:notifications@github.com] If liblouis is to be used to do the backtranslation it may be a good idea to investigate how well it performs these days. liblouis is all we have. I take your point, though. I guess if it's really that bad, we'll have to push for improvements to the tables and/or liblouis before we can release this. (Side question: why does NVDA disable the multi-pass facilities when forward translating?) Because multi-pass breaks the input/output position mapping. I have had grand ideas of completely rewriting that position mapping code for a while, but I've never gotten to it. Arend Arends contributed http://www.freelists.org/post/liblouis-liblouisxml/Update-output-positions-during-multi-pass-forward-translation-only a patch for this liblouis/liblouis#133 , but it hasn't been integrated yet and I believe there are some outstanding concerns. — |
|
My sincere apologies. I can in fact reproduce this now that I'm running liblouis 3. Previously, I was running an outdated liblouis. I never considered the possibility that they might have regressed it in liblouis 3. :( Both this and the "hello!" case are due to bugs in the liblouis 3 UEB tables. According to this mailing list post, UEB backtranslation issues are being addressed at present. That post also requests people to report any backtranslation issues they encounter.
No. Later cells can still change the text of earlier cells. So, if the previous word was "tg" and you type "r", it has to try to erase the "g" and insert "ogether". Things get even more complicated if the user drops the cursor into the middle of a word. And those examples are without even trying to come up with obscure edge cases.
Well, you can do that without ending translation; UEB does support that (table bugs notwithstanding). Regardless, I've implemented this now. |
@jcsteh: Reported this earlier on IRC, but for refference. |
Deferring to 2017.1 due to outstanding issues. See #6449 (comment) for details. |
Consider fixing "Make Unified English Braille the default Braille code" #6952 as part of this issue. |
Hi, I propose putting that all under Liblouis 3.1.0 PR (#6935). Thanks.
From: Reef Turner [mailto:notifications@github.com]
Sent: Thursday, March 9, 2017 10:07 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Support for entry of contracted braille via a braille keyboard (#2439)
Consider fixing "Make Unified English Braille the default Braille code" #6952 <#6952> as part of this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2439 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkBfcJhQTN6n0Qr9Z9xEskWeV4dU1ks5rkOiEgaJpZM4GpUFG> .
|
…ues #2439, #6054, #6113, #6935) Beyond the main code in brailleInput to support uncontracted/contracted input, this includes the following changes: * The list of braille tables has been moved out of the braille module into a separate brailleTables module. Braille tables are now added with a function rather than directly adding them to the data structure. Aside from being necessary in order to specify and check whether a table is contracted, this also makes the data about tables more extensible in future. * As the data structure for braille tables has now changed and is no longer ordered, this was a good opportunity to sort the list of tables alphabetically when displaying them to the user. * Updated to liblouis master shortly after release 3.2.0. The post 3.2.0 commits include some important back-translation fixes for UEB. * brailleInput is now notified when reverting config or changing config profiles. This is necessary because brailleInput now maintains some state when the input table is changed. * brailleInput is now initialised before braille at startup. This is because braille depends on brailleInput to get the currently untranslated input. * Dot7 and dot8 are now universally bound to braille input specific scripts for erase and enter. Any braille display drivers that had bindings for backspace/enter for braille input have been adjusted accordingly. * In the User Guide, a "Braille" section has been added above "Application Specific Features". The "Braille Control Types and States" section has been moved to a sub-section of this, and a sub-section on Braille Input has been added. * Added a Unicode braille input table.
Hi, er, I think @jcsteh may have closed this but not referenced this issue directly. As far as implementation goes, it is part of NVDA since 2017.3. Thanks.
From: Adriani90 <notifications@github.com>
Sent: Thursday, December 6, 2018 1:20 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Support for entry of contracted braille via a braille keyboard (#2439)
I see that the discussion here is very comprehensive. Is this issue now solved? Or could someone give a short update on this?
Thank you.
@josephsl <https://github.com/josephsl> sephsl, @jcsteh <https://github.com/jcsteh>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2439 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkJgfc_AbztaBwEqPl3cnPzssV7pzks5u2YoDgaJpZM4GpUFG> .
|
Hi, Never mind about my last comment. Perhaps Adriani didn't see the issue was actually closed. Thanks. |
Reported by jteh on 2012-06-12 06:11
(Spun off #808.)
Supporting input of contracted braille is much more complicated than computer braille, as we need to determine when to translate a chunk of input, the user experience before translation of a chunk occurs, etc.
Blocked by #808
The text was updated successfully, but these errors were encountered: