[BRLTTY] Problem with the character 'en dash' (U+2013) in output

[Didier Spaier]

Hello,

Le 23/01/2018 à 21:22, André-Abush Clause a écrit :
> Le 23/01/2018 à 20:48, Dave Mielke a écrit :
> 
>> When more than one character is mapped to the same glyph within the font, brltty can't
>> tell which of the possible alternatives the actual character is.
> OK. I didn't know this detail... Too bad for me. Thanks again for the explanation.

To elaborate on what Dave said, font creators often use the same glyphs
for similar looking characters, to save space in a console font in psf
format.

This is because the Linux console can only accept at most 256 glyphs per
font.

You can check the mapping table with this command if the font includes
one: psfgettable <font>

You can even check directly the mapping of a given character, like this:
didier[/tmp]$ psfgettable ter-120n.psf |grep U+2013
0x096	U+2013
So we know that in this font EN-DASH gets its own glyph.

Instead:
didier[/tmp]$ psfgettable ter-120n.psf |grep U+2192
0x003	U+25b6 U+2192 U+25ba
Shows that the RIGHTWARD ARROW shares its glyph with the BLACK
RIGHT-POINTING TRIANGLE and the BLACK RIGHT-POINTING POINTER.

To avoid the need for mapping, one could use a framebuffer, as then a
TTF font with thousands of characters can be usedbut that's a bit tricky
as brltty can only display discrete characters from their code.

As an aside, Araki Ken, developer of mlterm, claims that mlterm-fb can
now interface itself to brltty. I have installed a recent version, but
have still to test this feature. Dave, are you aware of that?

Other than that, there is also the possibility of
using orca + brlapi in a graphical environment.

Greetings,

Didier