Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
On Tue, 1 Feb 2022, Dave Mielke wrote: > 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. Those users certainly have a braille table with definitions for all the unicode characters they may encounter. I think the default should be for wide characters that have no braille representation (currently represented by a question mark) to span 2 cells with blank padding by default. At least in that case the total spacing will be right and things will properly align vertically. You still can get a full description of such characters with DESCHAR if needed. But if they're représented with the replacement character then there is nothing to gain by packing them tight. Nicolas___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
[quoted lines by Aura Kelloniemi on 2022/02/01 at 23:22 +0200] >What do you mean by "corresponding?" Do you mean that Linux should add padding >to a nearest narrow character. I meant on the lines above/below the wide character at the same column. >What if a line contains only wide characters? Then I'd think that there'd be no need for padding. > > 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. Group acess to tty, i.e. same as is used for the vcs devices now. >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). My positiion is that it needs to be as easy as possible so that other apps will actually use it. I favour a shared memory approach because that's general, i.e. not braille-specific. >Does this mean that chinise braille is implemented using Contracted braille in >BRLTTY? Yes. >If so, then standard braille glyph width of 1 cell holds as long as >contraction is disabled. No, because computer braille isn't typically defined for such languages. The very nature of the braille requires a contraction table approach. >But there are other options too – like padding at the >next word boundary (it works often in tables, but not always). Cells often contain more than one word. To me, it's impossible to get it right without actually knowing where a column starts. -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
On 2022-02-01 at 15:00 -0500, Dave Mielke 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: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
[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. >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 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. >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. -- I believe the Bible to be the very Word of God: http://Mielke.cc/bible/ Dave Mielke| 2213 Fox Crescent | WebHome: http://Mielke.cc/ EMail: d...@mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
Hello, On 2022-01-31 at 14:41 -0500, Dave Mielke wrote: > I guess we need to be able to live with the way Linux has done it even > though, in my opinion, it's the wrong way. Linux adds padding in the wrong > places, i.e. to the wide chracters. To achieve proper columnization, a > language that uses wide characters would introduce padding to the > corresponding single-byte characters where necessary. 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? 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). > No other platform has this strange issue so I think the best approach would > be to add a Linux screen driver parameter. Doing it that way wouldn't, at > least for the moment, make it settable from the preferences menu. I think this is feasible. People probably don't feel much need to toggle it very often. 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. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] again cut and paste problem with brltty and at-spi screen drivern
Hello, Halim Sahin, le mar. 01 févr. 2022 10:13:51 +0100, a ecrit: > yes it is ctrl+shift+v and xbrlapi is running as well. Ok. > I thought, that brltty is using its own clipboard Yes it is. > so that never worked here. Before the 6.4 release that wouldn't work indeed. But xbrlapi in version 6.4 got this: "The BRLTTY and X clipboards are synchronized." And normally that does work. Are you using the git master version? (there were a few bugs). Running xbrlapi with -v -n and posting the log corresponding to a brltty cut + xfce paste would help to know why that isn't working in your case. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] again cut and paste problem with brltty and at-spi screen drivern
Hi Samuel, yes it is ctrl+shift+v and xbrlapi is running as well. I thought, that brltty is using its own clipboard so that never worked here. But I don't need to have the clipboard merged so I thought that brltty uses it's own clipboard. BR. halim ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] again cut and paste problem with brltty and at-spi screen driver
Samuel Thibault, le mar. 01 févr. 2022 09:19:43 +0100, a ecrit: > Halim Sahin, le mar. 01 févr. 2022 08:48:06 +0100, a ecrit: > > > That being said, for pasting you should be able to just use > > > control-shift-V, which will directly paste from the brltty cutbuffer > > > into the application, without having to go through keypresses > > > simulation, thus much more robust. > > > > ctrl+shift+v doesn't paste anything. > > Is this a new feature after brltty 6.0? > > No, it's just the normal pasting shortcut of xfce-terminal. But perhaps > you changed it? To make sure which one that is, you can try to copy some text from another X application, e.g. pluma or gedit with control-C. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] again cut and paste problem with brltty and at-spi screen driver
Halim Sahin, le mar. 01 févr. 2022 08:48:06 +0100, a ecrit: > > That being said, for pasting you should be able to just use > > control-shift-V, which will directly paste from the brltty cutbuffer > > into the application, without having to go through keypresses > > simulation, thus much more robust. > > ctrl+shift+v doesn't paste anything. > Is this a new feature after brltty 6.0? No, it's just the normal pasting shortcut of xfce-terminal. But perhaps you changed it? Also, for this to work you need to have xbrlapi running. Samuel ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
