Dave Mielke writes:
> [quoted lines by Raphaël POITEVIN on 2021/03/22 at 11:51 +0100]
>
>>It seems not working on my Active Star.
>
> Yes, because the ht key tables don't include the common chords
> subtable. Perhaps this could be done. I don't perso0nally have access
> to an ht device so I'm a
[quoted lines by Raphaël POITEVIN on 2021/03/22 at 17:23 +0100]
>I mean if it's an easy job
How easy or hard any given task is depends on what skills any given person has.
So, for example, it's impossible for me to assess how easy or hard it'd be for
you to do it.
>maybe could I contribute.
Dave Mielke writes:
> I never tell anyone not to try something. That person had better be
> prepared, though, to be told that it wasn't done right. :-)
I never had a look in BRLTTY neithe documentation nor code. I mean if
it's an easy job maybe could I contribute. :-)
Regards,
--
Raphaël
[quoted lines by Raphaël POITEVIN on 2021/03/22 at 12:42 +0100]
>Is it difficult?
I don't know as I haven't had a good look at doing it yet.
>Maybe can I try to do it.
I never tell anyone not to try something. That person had better be prepared,
though, to be told that it wasn't done right.
Dave Mielke writes:
> Yes, because the ht key tables don't include the common chords
> subtable. Perhaps this could be done. I don't perso0nally have access
> to an ht device so I'm a little reluctant to mess with those tables
> myself. It'd sure be a nice addition to 6.4, though.
Is it
[quoted lines by Raphaël POITEVIN on 2021/03/22 at 11:51 +0100]
>It seems not working on my Active Star.
Yes, because the ht key tables don't include the common chords subtable.
Perhaps this could be done. I don't perso0nally have access to an ht device so
I'm a little reluctant to mess with
Hi,
Dave Mielke writes:
> Oops! I forgot to say that it's a chord. In other words, it's
> Space+Dots46+ either Dot7 (for text) or Dot8 (for dots).
It seems not working on my Active Star.
Regards,
--
Raphaël
www.leclavierquibave.fr
___
This message
Dave, Thank you very much for such a rapid response!
-Original Message-
From: Dave Mielke
Sent: Monday, March 22, 2021 10:06 AM
To: fley...@yandex.ru; Informal discussion between users and developers of
BRLTTY.
Subject: Re: [BRLTTY] Unicode Braille
[quoted lines by Dave Mielke
[quoted lines by Dave Mielke on 2021/03/22 at 03:00 -0400]
>Assuming that your braille device has a braille keyboard, you can also set it
>from there. Use Dots46 +Dot7 (for Translated via Text Table) or +Dot8 (for
>Dots via Unicode Braille0.
Oops! I forgot to say that it's a chord. In other
[quoted lines by Sergei V. Fleytin on 2021/03/22 at 09:05 +0300]
>Does BRLTTY supports Unicode Braille input and output?
Yes, it does.
>If Unicode Braille is supported for input, which table one should use?
It doesn't rely on a table. Instead, you change the Typing Mode setting within
the
Hello!
Does BRLTTY supports Unicode Braille input and output? If Unicode Braille is
supported for input, which table one should use?
Thanks in advance.
Sergei.
___
This message was sent via the BRLTTY mailing list.
To post a message, send
[quoted lines by Dave Mielke on 2020/10/23 at 07:44 -0400]
Well, I decided. The latest code moves the braille pattern check after the text
table lookup but before looking for a defined replacement character.
So, now, anyone who wants to have different representations for the braille
pattern
[quoted lines by Dave Mielke on 2020/10/22 at 10:14 -0400]
>The support for them is in the core. The order is to look for braille patterns,
>and then in the text table. I suppose we could look in the text table first,
>thus making it possible for the table to define them.
This can be done, but
On Thu, Oct 22, 2020 at 10:14:22AM -0400, Dave Mielke wrote:
> [quoted lines by Nicolas Pitre on 2020/10/22 at 01:00 -0400]
>
> >I think he wants to distinguish a braille 'a' from the regular letter
> >'a'. Right now they're indistinguishable unless you use DESCCHAR on the
> >whole screen.
>
>
[quoted lines by Nicolas Pitre on 2020/10/22 at 01:00 -0400]
>I think he wants to distinguish a braille 'a' from the regular letter
>'a'. Right now they're indistinguishable unless you use DESCCHAR on the
>whole screen.
That's what I thought, but I'm not convinced that that's a good idea.
>My
On Thu, Oct 22, 2020 at 01:00:38AM -0400, Nicolas Pitre wrote:
> On Wed, 21 Oct 2020, Dave Mielke wrote:
>
> > [quoted lines by Lars Bjørndal on 2020/10/21 at 21:23 +0200]
> >
> > >I'm working on a project where I need to be able to quickly distinguish
> > >between normal letters and braille
On Wed, 21 Oct 2020, Dave Mielke wrote:
> [quoted lines by Lars Bjørndal on 2020/10/21 at 21:23 +0200]
>
> >I'm working on a project where I need to be able to quickly distinguish
> >between normal letters and braille patterns in the range 0x2800-0x28FF on
> >the braille display, with BRLTTY in
[quoted lines by Lars Bjørndal on 2020/10/21 at 21:23 +0200]
>I'm working on a project where I need to be able to quickly distinguish
>between normal letters and braille patterns in the range 0x2800-0x28FF on
>the braille display, with BRLTTY in the console. On
>my system, 0x2801 is displayed as
Hi, list!
I'm working on a project where I need to be able to quickly distinguish
between normal letters and braille patterns in the range 0x2800-0x28FF on
the braille display, with BRLTTY in the console. On
my system, 0x2801 is displayed as dot 1, like a normal a. It's ok if it's
displayed as a
19 matches
Mail list logo
