On 2021-04-15 at 10:07 +0200, Samuel Thibault <[email protected]> wrote: > Aura Kelloniemi, le jeu. 15 avril 2021 07:58:23 +0300, a ecrit: > > Another option would be to introduce size values for the masks, in > > addition to > > the regionSize.
> I do not really see the use of being able to pass different sizes. > That's most probably a sign of a bug in the application output preparing > code, which the programmer would rather want to catch. You are probably right. The only case where the programmer may not care about the size of the output is when they want to just send some text on the display, and hope that it fits. For example brltty-ttb and apitest work this way in some situations. For these kind of applications it is useful to just write something, and get at least some part of the written text shown on the display. These are the cases where teh client programmer does not necessarily know (or want to know) how many characters their output contains, and in these situations they call brlapi__writeText, which pads/truncates the output as necessary. But this function cannot be called safely from languages that are Unicode only. > > Also, this does not need to break the protocol, because padding can be > > applied > > in the C client library. > No, because the display may have changed size in between, so the padding > will not be enough. Isn't this always the case? The display size can always change while the application renders the output or BrlAPI processes it. brlapi__writeText works this way – it does the padding/truncation on the client side. I guess that if the display size changes, the write operation either fails or is applied partially (or part of the display won't be refreshed). -- 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
