Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add support for worldwide braille table #7848

Closed
Adriani90 opened this issue Dec 11, 2017 · 38 comments
Closed

Add support for worldwide braille table #7848

Adriani90 opened this issue Dec 11, 2017 · 38 comments
Labels
blocked/needs-external-fix component/braille

Comments

@Adriani90
Copy link
Collaborator

Adriani90 commented Dec 11, 2017 •
edited
Loading

Steps to reproduce:

  1. Connect a braille display with NVDA and write following:
    Turkish: nasilsin
  2. Try to read the words on the Braille Display

Expected behavior:

An universal Braille table as a result of issue #489 on Liblouis Repository shall be added to NVDA's Braille settings.

Actual behavior:

On the Braille Display there is a code generated (for this letter 'x0129') instead of displaying the letter itself.
The turkish letter is being correctly displayed on the Braille display, when NVDA's language is set on turkish and Output table is set on turkish. But when NVDA is set on german and automatic language Switch is enabled, the turkish table is not being automatically recognized when a sign like i appears in the text.

System configuration:

NVDA version:
2017.4

NVDA Installed or portable:
Both

Other information:

Windows version:
Windows 10 Build 16299.64

Name and version of other software in use when reproducing the issue:
All

Other questions:

Does the issue still occur after restarting your PC?
Yes

Have you tried any other versions of NVDA?
2017.3, 2017.1
@josephsl
Copy link
Collaborator

josephsl commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email

@josephsl
Copy link
Collaborator

josephsl commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@josephsl
Copy link
Collaborator

josephsl commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 11, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 11, 2017 via email •
edited
Loading

@Adriani90 Adriani90 changed the title Improve support for turkish braille table Add support for worldwide braille table Dec 12, 2017
@Adriani90 Adriani90 mentioned this issue Dec 12, 2017
Closed
@LeonarddeR
Copy link
Collaborator

I'm very reluctant to even consider adding the concept of a worldwide table to NVDA, simply because braille supports only 256 different patterns.

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 12, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 12, 2017 via email

@zstanecic
Copy link
Contributor

zstanecic commented Dec 12, 2017 via email

@Adriani90
Copy link
Collaborator Author

Well, my example is first of all for the Output Braille. We could do the same for imput Braille as well.

@Adriani90
Copy link
Collaborator Author

For example, Chinese Output would be correctly displayed when Output table is set on universal, as Long as the Output table for chinese is implemented in NVDA. The same for turkish, romanian and other languages.

@Adriani90
Copy link
Collaborator Author

But as far as chinese is concerned, I will test how it works together with other languages. Because I think this kind of alphabeths could indeed cause some issues.

@Adriani90
Copy link
Collaborator Author

@zstanecic, could you please describe the exact Problem? When I type dots 35 and then 46 they will be displayed as such on the Braille Display. I don't see a Major issue about that.

@zstanecic
Copy link
Contributor

zstanecic commented Dec 12, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 12, 2017 via email

@LeonarddeR
Copy link
Collaborator

Such a table would simply be unusable for input, as @zstanecic mentioned. THat's no problem though, since we can enable/disable a table for input/output separately.

I think that the most appropriate method would be implementing #290, then allow automatic language switching for braille tables.

Anyhow, I think further discussion doesn't make any sense if there's no consensus to implement this. Thoughts @derekriemer, @bramd, @dkager, @jcsteh, @josephsl?

@dkager
Copy link
Collaborator

dkager commented Dec 12, 2017

To summarize (and reiterate) my thoughts:

  • I don't think automatic language switching should change the braille table by default. I can read the word café with the Dutch and US Computer braille tables, but not necessarily with the French table. Yet café could be a French word.
  • The issue of Turkish characters not being brailled by the German table is for the liblouis team.
  • If the German braille standard does not include definitions for Turkish, I don't think the liblouis table should be updaed to include these. There would be no end to the languages you could braille with that German table, and in the end you won't know what the braille patterns mean anymore.
  • Finally, this issue looks like it needs some focus. What is being requested here?

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 12, 2017 via email •
edited
Loading

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 12, 2017 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 14, 2017 •
edited
Loading

Dear all,

after comprehensive testing I found out that there are many languages which treat signs like exclamation mark and so on in 8 dot computer braille differently. Because of that I propose following:

First step: we have to find all languages which have the same mapping of latin letters, digits and common signs like percent, dollar, exclamation point etc. in braille and put them together in one table.
Second step: language specific signs (letters accents and diacrices, greek letters, cyrillic and hebrew signs and other alphabeths have to be included into the master table. Some of the other alphabeths might be 6 dot braille, but this would not be a problem because the sign displayed on the screen is not in conflict with any standard latin letter or sign. For example a cyrillic letter could be 6 dot braille if the most countries which use cyrillic letters use 6 dot unicode braille. Latin letters could be 8 dot computer braille. But to achieve this we have to sort the existing tables and look at the common aspects of each alphabeth.

Follow up: an optional universal worldwide braille output table integrated in NVDA braille settings.

Conditions:

  1. Documentation on the standard computer braille for each alphabeth which has been implemented in the master table must be published (i.e. latin = 8 dot computer braille; cyrillic = 6 dot braille) and description of signs must be provided. Additionally, a small tool for learning the implemented standards could be developed

  2. The standard braille which is used by most countries according to existing tables has to be implemented and has to be learned by users who want to read confortably more languages or who want to learn new languages.

I know that this is more related to liblouis than to NVDA. But I think in this case both projects have to work together. NV Access comitted itself to give people with visual disabilities access to technology and invormation. In this case, we would bring millions of users together.

I hope the community is open to start working on this. A project team could be built to work on on it.

@josephsl
Copy link
Collaborator

Hi,

Normally I and others don't take this drastic step, but it MUST be done. Closing as: wontfix, cantfix, externalfix.

The proposed vision is good. However, once reality check kicks in, it falls apart. First, not all people are natural multilingualists. Sure, we can use English or Latin alphabet as lingua franca, but it does not provide a strong justification to create a universal braille table. This is the very reason why I repeatedly asked folks to investigate tables for languages such as Chinese and others.

Second, braille standards do change. Some standards, particularly Unified English Braille, require months and years of consultation before ratified, and people would want strong conformity. In some languages (such as Korean), new standards are set by the government, while for others (such as UEB), it is a supranational organization that sets these standards. So what if one of these organizations implements an updated braille standard to a point where the universal table itself will be affected? This creates a domino effect in that other tables MUST be checked to make sure the universal table remains unbroken.

Third, not all braille standards are official standards. The American English Braille standard came out after years of negotiation. For now, grade 2 is standard, but some have defined their own grade 3 braille rules, which are mutually incompatible.

Lastly, be prepared to be bombarded with requests from other communities to have their braille tables included. Again this will create a domino effect where regressions must be checked.

For these reasons, I hereby close this issue until a very strong justification is presented. I'd like to request that, when you provide justifications for this issue, please refrain from talking about productivity, standards support, universal appeal and what not. If a justification is the fact that other screen readers don't have this feature, then we will not even consider that.

Thank you.

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 14, 2017 via email

@josephsl
Copy link
Collaborator

Hi,

I'll consider reopening this if and only if key stakeholders say it is good to proceed: @jcsteh, @dkager, @LeonarddeR. Thanks.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Dec 15, 2017 •
edited
Loading

I recommend against reopening this. The request for a worldwide, universal table should go to the liblouis project in the first place. I tend to be against implementing braille tables in NVDA that are not a part of Liblouis. The only valid reason to reopen this in my view, is when this particular request is honoured by the Liblouis team.

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Dec 15, 2017 •
edited by LeonarddeR
Loading

Dear all,

I have edited this issue accordingly and I have added issue liblouis/liblouis#489 on Liblouis repo. I suggest reopening this issue since the probability will be higher to stay on track. There is more atention being paid on opened issues than on closed issues. It will be up to NVDA Team to implement such a table in the Braille Settings among all other Output tables.

I thank you all for the wonderful discussion on this Topic and hope you understand what is actually the aim of this.

Best wishes, nice holyday and merry Christmas to all of you
Adriani

@LeonarddeR
Copy link
Collaborator

@Adriani90: I've edited your comment to properly refer to the liblouis issue you created. Please request another reopen if the Liblouis team acknowledges your request, but honestly, I think this won't be very likely as per the arguments @josephsl and others brought up above.

@jcsteh
Copy link
Contributor

jcsteh commented Dec 15, 2017 via email

@Adriani90 Adriani90 mentioned this issue Feb 18, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
blocked/needs-external-fix component/braille
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@LeonarddeR @dkager @jcsteh @josephsl @zstanecic @Adriani90