On 2021-03-28 at 22:32 +0200, Samuel Thibault <[email protected]> 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 _______________________________________________ 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
