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

Add English (U.S.) 8 dot extended computer braille table to the list #6836

Closed
dkager opened this Issue Feb 3, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@dkager
Collaborator

dkager commented Feb 3, 2017

This was recently added to liblouis, pending the relase of 3.1: liblouis/liblouis@b4e8793
The table name is en-us-comp8-ext.utb.

This requires:

  • Upgrade to liblouis 3.1 when it is released.
  • Add the table to the lists of output and input tables.

Also appreciated:

  • Scrutinize the table for errors and omissions.

Open questions:

  • What to call this table? There is no official standard. Will the suggested name "extended computer braille" confuse users?
  • Can this table supersede the current en-us-comp8.ctb table? It is a superset of the existing 8-dot table and thus backwards compatible. However, I hesitate because that would make it the default table and thus impacts a lot of users.
@josephsl

This comment has been minimized.

Show comment
Hide comment
@josephsl

josephsl Feb 3, 2017

Collaborator
Collaborator

josephsl commented Feb 3, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 3, 2017

Collaborator

Yes: you can read anything that can be displayed with the Windows-1252 codepage. Examples include bullets, the euro sign and accented letters.
@leonardder Can you say something about organization support?

Collaborator

dkager commented Feb 3, 2017

Yes: you can read anything that can be displayed with the Windows-1252 codepage. Examples include bullets, the euro sign and accented letters.
@leonardder Can you say something about organization support?

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 3, 2017

Collaborator
Collaborator

dkager commented Feb 3, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Feb 3, 2017

Collaborator

As a trainer at @BabbageCom, I've already met several people who would like an extended US 8 dot braille table due to the several missing characters in the current one. Even letters like é, ë and á do not have a braille character assigned in the standard table. In the Netherlands, we do not have an 8 dot Dutch table, so either people use the English or German 8 dots table. But as mentioned, the current English one has its drawbacks

Collaborator

leonardder commented Feb 3, 2017

As a trainer at @BabbageCom, I've already met several people who would like an extended US 8 dot braille table due to the several missing characters in the current one. Even letters like é, ë and á do not have a braille character assigned in the standard table. In the Netherlands, we do not have an 8 dot Dutch table, so either people use the English or German 8 dots table. But as mentioned, the current English one has its drawbacks

@josephsl

This comment has been minimized.

Show comment
Hide comment
@josephsl

josephsl Feb 3, 2017

Collaborator
Collaborator

josephsl commented Feb 3, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 3, 2017

Collaborator

IMO this is a subject for discussion within liblouis. This issue is intended to track progress while that discussion is going on.

As for the screen reader side, this table implements a compromise of what the major screen readers for Windows are currently calling U.S. English 8-dot braille. As the table mentions I was unable to find any official standards for one-to-one mappings of characters beyond ASCII, nor did inquiries at screen reader vendors reveal any specification documents.

Collaborator

dkager commented Feb 3, 2017

IMO this is a subject for discussion within liblouis. This issue is intended to track progress while that discussion is going on.

As for the screen reader side, this table implements a compromise of what the major screen readers for Windows are currently calling U.S. English 8-dot braille. As the table mentions I was unable to find any official standards for one-to-one mappings of characters beyond ASCII, nor did inquiries at screen reader vendors reveal any specification documents.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 4, 2017

Collaborator

See also here for discussion on the liblouis mailing list.

Collaborator

dkager commented Feb 4, 2017

See also here for discussion on the liblouis mailing list.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 6, 2017

Contributor
Contributor

jcsteh commented Feb 6, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 6, 2017

Collaborator

There are duplicates, and even some multi-cell patterns (ligatures). But backtranslation should be unambiguous through the use of the noback opcode.

Collaborator

dkager commented Feb 6, 2017

There are duplicates, and even some multi-cell patterns (ligatures). But backtranslation should be unambiguous through the use of the noback opcode.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 6, 2017

Contributor
Contributor

jcsteh commented Feb 6, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 6, 2017

Collaborator

There should be no multi-cell patterns that allow to be backtranslated. For single-cell patterns, there should always be zero or one matches for backtranslation.
I say "should" because there doesn't seem to be a utility in liblouis to formally check this.

Obviously, forward translation is neither unambiguous nor only single-cell.

Collaborator

dkager commented Feb 6, 2017

There should be no multi-cell patterns that allow to be backtranslated. For single-cell patterns, there should always be zero or one matches for backtranslation.
I say "should" because there doesn't seem to be a utility in liblouis to formally check this.

Obviously, forward translation is neither unambiguous nor only single-cell.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Mar 6, 2017

Collaborator

Re #6935

Collaborator

dkager commented Mar 6, 2017

Re #6935

jcsteh added a commit that referenced this issue Jul 7, 2017

New braille translation tables: Danish 8 dot computer braille, Englis…
…h (U.S.) 8 dot extended computer braille, Lithuanian, Slovenian 8 dot computer braille. (issues #6188, #6550, #6773, #6836)

Also, changed the description for "Slovene grade 1" to "Slovenian grade 1" for consistency.

jcsteh added a commit that referenced this issue Jul 10, 2017

New braille translation tables: Danish 8 dot computer braille, Englis…
…h (U.S.) 8 dot extended computer braille, Lithuanian, Persian 8 dot computer braille, Persian grade 1, Slovenian 8 dot computer braille. Incubates #7364 (issues #6188, #6550, #6773, #6836, #7367).

jcsteh added a commit that referenced this issue Jul 11, 2017

Instead of adding a separate English (U.S.) 8 dot "extended" computer…
… braille table, use that table to replace the existing English (U.S.) 8 dot computer braille table. Re #6836.

jcsteh added a commit that referenced this issue Jul 11, 2017

Instead of adding a separate English (U.S.) 8 dot extended computer b…
…raille table, use that table to replace the e

xisting English (U.S.) 8 dot computer braille table. Incubates #7364 (issue #6836).
@Brian1Gaff

This comment has been minimized.

Show comment
Hide comment
@Brian1Gaff

Brian1Gaff Jul 23, 2017

Brian1Gaff commented Jul 23, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jul 23, 2017

Collaborator

Does this inclusion explain the error I'm getting in recent Next snaps when
running the installer from the next archive?

It would be really helpful if you could post the error, along with steps to reproduce if you have them.

Collaborator

dkager commented Jul 23, 2017

Does this inclusion explain the error I'm getting in recent Next snaps when
running the installer from the next archive?

It would be really helpful if you could post the error, along with steps to reproduce if you have them.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jul 24, 2017

Collaborator

If you have once installed Next and than run a master installer, this error is expected. From what you said on NVDA devel, I assumed this was the case. Are you sure you get these errors in most recent next?

Collaborator

leonardder commented Jul 24, 2017

If you have once installed Next and than run a master installer, this error is expected. From what you said on NVDA devel, I assumed this was the case. Are you sure you get these errors in most recent next?

@jcsteh jcsteh closed this in #7364 Aug 1, 2017

@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Aug 1, 2017

jcsteh added a commit that referenced this issue Aug 1, 2017

New braille translation tables (#7364)
- New braille translation tables: Danish 8 dot computer braille, Lithuanian, Persian 8 dot computer braille, Persian grade 1, Slovenian 8 dot computer braille. (#6188, #6550, #6773, #7367)
- Improved English (U.S.) 8 dot computer braille table, including support for bullets, the euro sign and accented letters. (#6836)
- Changed the description for "Slovene grade 1" to "Slovenian grade 1" for consistency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment