[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Samuel Thibault]

Nicolas Pitre, le mer. 15 avril 2026 11:22:34 -0400, a ecrit:
> On Wed, 15 Apr 2026, Aura Kelloniemi wrote:
> > On 2026-04-15 at 01:47 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> >  > Nicolas Pitre, le jeu. 09 avril 2026 23:12:06 -0400, a ecrit:
> >  > > Done — the protocol now handles grapheme clusters with a three-layer 
> >  > > approach (single codepoint, continuation cells, overflow area) and the 
> >  > > cell width field covers the whole cluster. See the updated design 
> >  > > document attached.
> > 
> >  > I'm a bit afraid of the complexity of the dynamic allocation of the
> >  > overflow entry. I agree that adding a limitation to 8 combining
> >  > codepoints brings static limitation, but conversely there have been
> >  > vulnerabilities found due to unbound combining codepoints management,
> >  > and for easier adoption, the protocol should be quite simple.
> > 
> > IMHO, if there is a static limitation, it should be futureproof – i.e. insely
> > big – like 16 or 32. But of course bumping the protocol version sometimes
> > should be acceptable.
> 
> There are no static limitations,

But I'm saying that it'd be simpler for the code to introduce a
limitation so that we can use non-dynamic arrays etc.

As mentioned earlier in the thread, the known requirement for Tibetan is
8 cobminers. So leaving room for 16 or 32 should be plenty for all
reasonable uses.

Samuel