[BRLTTY] Russian braille tables and orca issue

Samuel Thibault samuel.thibault at ens-lyon.org
Mon Jan 17 19:09:57 EST 2022


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


More information about the BRLTTY mailing list