[BRLTTY] Low-level BrlAPI questions

[Aura Kelloniemi]

On 2021-04-15 at 12:24 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > > 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.

 > And it shouldn't :)

I feel a bit silly about this. I don't see any difference regardless of who
does the padding:

My thinking goes like this:

Scenario #1: Server does padding. Application renders the text according to
the display size (or does not care about the size, and just sends text). The
client forwards it to server. [Display size changes here.] The server receives
the text and notices, that the text and display sizes do not match. It can
either pad/truncate the text or signal an error. It can of course do both –
write what it can and tell that the write failed – just to make sure that the
application notices the size change.

Scenario #2: Client library does the padding. Application renders text,
forwards it to the client library, which pads/truncates it to fit the
estimated display size. [Display size changes.] The text arrives to the
server, which notices the size does not match. It has the same three options
as in scenario #1.

Scenario #3: The application does the padding. The application pads the text
to fit the display size, and forwards it to the client library, which passes it
on to the server. Again, if display size has changed, the server has the same
options as above.

The padding/truncation can also be done to make the text fit any region size,
not just the whole display size. When the display size changes, the region
size may or may not be invalidated as well – depends on the change and
application logic. In all the cases the best that can be done depends on the
application's requirements.

Samuel, am I missing something? Why do you think the library should not
pad/truncate text?

-- 
Aura