search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.08k stars 625 forks source link

Add hyphenation support to braille using Pyphen #17010

Open LeonarddeR opened 4 weeks ago

LeonarddeR commented 4 weeks ago

Is your feature request related to a problem? Please describe.

NVDA braille has a word wrap feature that ensures full words are shown on the braille display. However, with mobile braille displays, this might require a lot of scrolling for longer words. The alternative would be disabling word wrap, but that means that it is not clear from braille whether you're at the end of a word or not, you'll just have to guess.

Describe the solution you'd like

Make word wrap a tristate function, allowing hyphenation using pyphen. Pyphen uses the same sources as Open Office. A difficulty is, how to choose the proper hyphenation table? It should probably be bound to the language of the braille table by default, but if text info prescribes another language, that language should be used instead. Another question is, should we hyphenate with the dash? How is a braille reader supposed to know that the dash is part of hyphenation rather than part of the real text? I guess this is just a matter of fact, when you want hyphenation, you will have the dash at the end of the braille display. If you don't want this ambiguity, just disable hyphenation altogether.

Describe alternatives you've considered

Use a basic form of hyphenation that just adds a hyphen/dash to the end of the braille display when the text continues after the current window. That can solve some confusion.

SaschaCowley commented 4 weeks ago

How is a braille reader supposed to know that the dash is part of hyphenation rather than part of the real text?

AFAIK this ambiguity exists in visual line wrapping where hyphenation is used to break up long words. I think there are few cases where this will cause real confusion, and if it does, the reader can turn off hyphenation to ensure that what they're reading is the original text only.

michaelDCurran commented 4 weeks ago

What about the case where a word breaks in the middle of a multi-cell contraction or after a capital sign. I think this would be pretty hard to read. Perhaps we should ensure that we are on a braille pos that maps to a raw (untranslated) pos that is greater than the raw (untranslated) pos for the previous braille pos. I.e. the first cell of multiple cells representing one untranslated character.

XLTechie commented 4 weeks ago

AFAIK this ambiguity exists in visual line wrapping where hyphenation is used to break up long words.

Yes and no. In visual writing, there is no chance that the hyphen will be mistaken for a contracted character sequence. It's always and only a hyphen. In braille it could be a few different things, depending on the table in use, and where it happens in the word.

SaschaCowley commented 4 weeks ago

@XLTechie I had not thought of that particular problem. I think @michaelDCurran's solution sounds reasonable, though perhaps doesn't cover all of the issues you raise (ex. the hyphen character being mistaken for a contraction).

XLTechie commented 4 weeks ago

I think at some point we just have to accept that people who have turned on hyphenation, have to be ready to put up with some ambiguity caused by it. It's not like you don't run into the same thing in paper braille.

So yeah, solving for the conditions Mick specified is probably the best we can do. If I had read his comment before I wrote mine, I wouldn't have.

LeonarddeR commented 4 weeks ago

Blocked by #17011