On 2022-02-01 at 15:00 -0500, Dave Mielke <[email protected]> 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 _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
