[BRLTTY] Low-level BrlAPI questions

[Aura Kelloniemi]

On 2021-03-28 at 22:32 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Aura Kelloniemi, le dim. 28 mars 2021 12:05:46 +0300, a ecrit:
 > > Shouldn't both of them use size_t?

 > We could do this but that would change the ABI, better leave this for
 > next time we really want to break the ABI for a strong reason.
 > That being said, int is asserted to be at least 16bits, I don't think
 > we'd ever need to handle > 32767 characters.

Most likely not. I was just thinking about the fact that size_t is mostly used
to count bytes of memory usage. But you are right in that it can well be
delayed, if ever changed.

 > > - If the number of code points in text does not match regionSize,
 > >   brlapi__write does not write anything to the display.

 > ? Aren't you getting an exception?

Ah, I was calling brlapi__closeConnection after brlapi__write, and did not get
an exception. I added a call to brlapi__leaveTtyMode, and now I see it.

Would it require changing the BrlAPI protocol to be able to pass the exception
message to the client? It is a nuisance to restart BRLTTY and search the logs.

 > > - Proposal: Could brlapi__write be extended to allow passing text as NULL
 > >   (without triggering the current effect of releasing the display to the
 > >   parent client). In this case andMask should also be NULL, and orMask would
 > >   be used to write a dot pattern to the display.

 > In my memory I thought it was already the case, but apparently not. That
 > could possibly be more convenient indeed, see more below.

It actually is. I was accidentally also passing charset to __write, and that
is why it did not work. Now that I have exceptions enabled, there is more
reason and consequence in the world.

 > > - Why does brlapi__writeDots go through all the trouble of decoding the raw
 > >   dot pattern given by the caller to an UTF-8 sequence? It could just fill the
 > >   text field with spaces, memset andMask to zero, and use dots as orMask. I
 > >   have tested this, and it works.

 > It works for the braille output, but not for the text output, whenever a
 > braille device has one, that text will remain blank.

I have never heard of such a device. Wow. Are they just virtual devices, or
are there real ones as well? How does contraction and text display work
together?

 > That being said, that could be handled on the server side, when
 > text==NULL we could fill the text part with the unicode patterns.

That would be beneficial to the client programmer, but otherwise makes no
difference.

-- 
Aura