Re: properties for exposing custom Braille descriptions

LibLouis has a file/table (unicode.dis) that is a literal translation of
Unicode chars to the appropriate dot patterns. It is meant to be included
in other files for translations. It appears to be included in at least the
UEB translation. It is referenced in many of the tests of other languages,
so probably it is used in them also.

    Neil


On Thu, Feb 7, 2019 at 9:14 AM Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Thanks Jason!
>
> We don't need a page per se. It should be sufficient to put some braille
> unicode characters in a text editor like gedit or notepad.
>
> --joanie
>
> On 2/7/19 12:07 PM, White, Jason J wrote:
> > I can perform the test on multiple platforms, including
> Linux/GNOME/Orca. Is there a test page already, or should I create one?
> >
> > On 2/7/19, 12:00, "Joanmarie Diggs" <jdiggs@igalia.com> wrote:
> >
> >     Indeed, for translation. But Unicode braille characters shouldn't be
> >     translated. So one question is: Is liblouis smart enough to not
> >     translate those? The second question is: Is the library used to
> >     communicate with the display (in my case that would be BrlTTY) smart
> >     enough to handle those characters?
> >
> >     I would hope that the answer to both questions is "yes." And I went
> to
> >     verify that this morning for my platform, but when I powered on my
> >     ancient braille display, it made all sorts of noises and gave up the
> >     ghost. :(
> >
> >     A quick test I did suggests liblouis *might* be translating those
> >     characters, but I'm not positive. Since you (Jason) happen to use
> Orca,
> >     and presumably have a not-dead refreshable braille display, could you
> >     please do the test for me to answer both the first question and the
> >     second question?
> >
> >     You should be able to answer the second question by disabling
> >     translated/contracted braille. That will cause Orca to send the
> >     characters directly to BrlTTY unmodified. If what's on the display
> >     matches the unicode braille dot patterns in the test text, then we
> know
> >     BrlTTY is good.
> >
> >     To answer the first question, re-enable translated/contracted
> braille.
> >     If those unicode braille dot patterns are still preserved, then
> liblouis
> >     is also good. If liblouis isn't good, we should fix that in liblouis,
> >     but that's something I can work around in Orca by looking for
> characters
> >     in the braille dot pattern range and not sending them to liblouis. As
> >     far as I am aware, I don't have control over what BrlTTY does with
> the
> >     characters I give it.
> >
> >     Thanks in advance for doing these tests. And sorry for having to ask
> >     you. My braille display picked a fine morning to kick the bucket.
> >
> >     --joanie
> >
> >
> >     On 2/7/19 9:06 AM, White, Jason J wrote:
> >     > Besides Apple, I think everyone is using liblouis at this point
> for translation. I don't know what Apple's Mac OS and iOS implementations
> use. I think it would be reasonable to expect everyone to support the
> Unicode code points for braille rendering.
> >     >
> >     > On 2/7/19, 09:04, "Joanmarie Diggs" <jdiggs@igalia.com> wrote:
> >     >
> >     >     Do we know if all the braille libraries used by the platforms
> support
> >     >     Unicode block?
> >     >
> >     >     On 2/7/19 8:57 AM, White, Jason J wrote:
> >     >     > Braille ASCII varies between countries, hence between the
> braille tables
> >     >     > loaded by screen readers – so it can’t be used to specify a
> desired
> >     >     > braille representation reliably.
> >     >     >
> >     >     >
> >     >     >
> >     >     > For example, if the author assumes North American ASCII
> braille, but the
> >     >     > user’s system is configured for one of the European codes,
> the result
> >     >     > won’t be what the author would expect.
> >     >     >
> >     >     >
> >     >     >
> >     >     > Only the Unicode block is unambiguous.
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > *From: *Peter Krautzberger <peter@krautzource.com>
> >     >     > *Date: *Thursday, February 7, 2019 at 08:43
> >     >     > *To: *"White, Jason J" <jjwhite@ets.org>
> >     >     > *Cc: *"public-aria@w3.org" <public-aria@w3.org>
> >     >     > *Subject: *Re: properties for exposing custom Braille
> descriptions
> >     >     >
> >     >     >
> >     >     >
> >     >     > Hi Jason,
> >     >     >
> >     >     >
> >     >     >
> >     >     > This question is mentiond in the list of questions at the
> end of the
> >     >     > page. My apologies if the page was not accessible enough to
> make it there.
> >     >     >
> >     >     >
> >     >     >
> >     >     > Speaking for myself, I'd very much hope that Unicode Braille
> would work.
> >     >     > But Braille ascii might be a useful consideration. As I
> understand it,
> >     >     > NVDA's prototype back in May pushed the raw value out (and
> Sina's test
> >     >     > files used grade 1).
> >     >     >
> >     >     >
> >     >     >
> >     >     > Best regards,
> >     >     >
> >     >     > Peter.
> >     >     >
> >     >     >
> >     >     >
> ------------------------------------------------------------------------
> >     >     >
> >     >     > This e-mail and any files transmitted with it may contain
> privileged or
> >     >     > confidential information. It is solely for use by the
> individual for
> >     >     > whom it is intended, even if addressed incorrectly. If you
> received this
> >     >     > e-mail in error, please notify the sender; do not disclose,
> copy,
> >     >     > distribute, or take any action in reliance on the contents
> of this
> >     >     > information; and delete it from your system. Any other use
> of this
> >     >     > e-mail is prohibited.
> >     >     >
> >     >     >
> >     >     > Thank you for your compliance.
> >     >     >
> >     >     >
> ------------------------------------------------------------------------
> >     >
> >     >
> >     >
> >     >
> >     > ________________________________
> >     >
> >     > This e-mail and any files transmitted with it may contain
> privileged or confidential information. It is solely for use by the
> individual for whom it is intended, even if addressed incorrectly. If you
> received this e-mail in error, please notify the sender; do not disclose,
> copy, distribute, or take any action in reliance on the contents of this
> information; and delete it from your system. Any other use of this e-mail
> is prohibited.
> >     >
> >     >
> >     > Thank you for your compliance.
> >     >
> >     > ________________________________
> >     >
> >
> >
> >
> >
> > ________________________________
> >
> > This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
> >
> >
> > Thank you for your compliance.
> >
> > ________________________________
> >
>
>
>

Received on Thursday, 7 February 2019 18:04:15 UTC