search

daisy / ebraille

Repository for developing use cases and standard for digital braille
16 stars 5 forks source link

Braille without any transcription errors #6

Closed ManfredMuchenberger closed 3 months ago

ManfredMuchenberger commented 2 years ago

As a braille display user, I want to be able to read e-books that show on a braille display as contracted six dot braille without any transcription errors. So basically I want to read the same quality of braille on my braille display that I can get as embossed paper braille from my library.

Detail: Currently, e-books only contain an ink print version of the text. Due to very complicated braille contraction rules and exceptions it is not possible for screenreader or braille display manufacturers to convert this text into error-free braille. This is a fact for German contracted braille and maybe also for other languages.

Proposal: Using a digital text file format that contains a pre-transcribed braille version of the text in Unicode braille characters.

franciscoONCE commented 2 years ago

Another excellent reason to incorporate Unicode characters into the new format.

avneeshsingh commented 2 years ago

What priority should be assigned to this use case? High, Medium or low?

ManfredMuchenberger commented 2 years ago

For us (SBS) Braille without any transcription errors is high priority, because it would be one of the main reasons for a new e-Braille format in german language (contracted german braille).

mhorspool commented 2 years ago

Presumably this means settling on a single encoding scheme, e.g. UniCode/Northamerican ASCII etc.

Braille without any transcription errors relies on transcribers a) being involved, and b) not making any mistakes, and I don't think we can stipulate this in the standard!

wfree-aph commented 2 years ago

Relates to braille-first file specification. Encoding must be consistent. Must all use Unicode or NA ASCII. May want to make that clear in the title and description.

franciscoONCE commented 2 years ago

NA ASCII (as any other ASCII-based set of characters, for that matter) is too limited. Unicode is preferrable for a wider internationalization of the project.

mattgarrish commented 1 year ago

All the publishing formats support Unicode, so I don't see any of their use as a problem here.

ManfredMuchenberger commented 1 year ago

All the publishing formats support Unicode, so I don't see any of their use as a problem here.

Yes Unicode will most probably be the best choice. I also don't see a problem here as long as we don't rely on generating the contracted Braille from plain text on the fly in the reading app/device.

wfree-aph commented 3 months ago

Since the first draft of the specification uses Unicode braille, we can close this issue as resolved.