[BRLTTY] Multi-column characters (was: Re: 6.5 soon)

[Aura Kelloniemi]

On 2022-02-01 at 15:00 -0500, Dave Mielke <Dave at mielke.cc> wrote:
 > [quoted lines by Aura Kelloniemi on 2022/02/01 at 21:43 +0200]

 > >What do you mean by corresponding single-byte characters? Are you talkig about
 > >characters which have a single-byte representation a particular character set
 > >or characters which have a single-column wide glyph?

 > Yes, it was a poor choice of words. I realized that after sending. I of course meant width of 1.

And my question was not complete. What do you mean by "corresponding?" Do you
mean that Linux should add padding to a nearest narrow character. What if a
line contains only wide characters?

 > >I wish Linux console would be fixed and upgraded for the 21st century so that
 > >it would have proper Unicode font support. More realistic probably is to get
 > >other terminal emulators to work with BRLTTY (or vice versa).

 > My opinion is that there should be a common shared memory rendering of the screen content. Then other platforms, e.g. Chrome OS, could also benefit.

I don't know how that would work permission-wise.

I have planned to suggest that brlapi provided a simple interface through
which terminal emulators could provide screen content to BRLTTY and accept
input events from BRLTTY. Terminal emulators could then load brlapi with
dlopen so that that the brlapi dependency would remain optional (which is
probably important for distribution packagers). But this topic deserves its
own thread.

 > >I think this is feasible. People probably don't feel much need to toggle it
 > >very often.

 > And what about my position that the default should be the way it is now? I want to make it easy for the actual language users.

I agree.

 > >Another question then is could we find a way to keep braille glyphs
 > >aligned on terminals that really support wide characters. I think this can be
 > >solved separately.

 > That'd be assuming a standard braille width, which isn't true. chinese braille, for example, is doing roughly what PinYin does, i.e. a given braille cell represents a discrete sound.

Does this mean that chinise braille is implemented using Contracted braille in
BRLTTY?

If so, then standard braille glyph width of 1 cell holds as long as
contraction is disabled. But there are other options too – like padding at the
next word boundary (it works often in tables, but not always).

-- 
Aura