Alexander Epaneshnikov, le lun. 17 janv. 2022 00:12:37 +0300, a ecrit: > On Sun, Jan 16, 2022 at 03:09:04PM -0500, Dave Mielke wrote: > > [quoted lines by Alexander Epaneshnikov on 2022/01/16 at 22:45 +0300] > > > > >I think Dave, please correct me if this isn't the case - brltty doesn't > > >use an abbreviation table for brlapi clients. > > > > What are abbreviation tables? Do you mean contraction tables? If so, then, > > no, I don't think that the BrlAPI interface uses them. > > yes. contraction tables sorry. > should brlapi use contraction tables if just text is fed to brlapi? I think > yes.
Yes, but that won't fit orca's needs. For a start, Orca doesn't use writeText, it crafts a writeStruct, since it may have and/or masks to set. And that's for a reason: if it was brltty that were doing the contraction, Orca would have no idea how much text did fit on the display, and thus not be able to achieve proper text-window switching. This is just like text rendering on X: nobody uses the X server-based text rendering any more, and everybody uses e.g. pango to render on the client side with all sizing constraints information, then push the bitmap to the server. Similarly, for contracted text we should just let Orca perform the contraction and push the rendered dots to BrlAPI. Orca actually already supports that, you can enable it in its preference dialog. Possibly we'd want to synchronize options: when enabling contraction in brltty that'd enable it in Orca, and conversely and vice-versa. That's to be done on the Orca side. Samuel _______________________________________________ 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
