Disable pass1only for liblouis braille output

[LeonarddeR]

Note: This issue needs an external fix at the moment, liblouis/liblouis#133 . I opened this issue to document cases why using Liblouis multipass is desired.

Steps to reproduce:

1. Set braille output table to Dutch (Netherlands)
2. Open notepad, and type: "1b3d5"

Expected behavior:

Output is: ⠼⠁⠠⠃⠼⠉⠠⠙⠼⠑

Actual behavior:

Output is: ⠼⠁⠃⠼⠉⠙⠼⠑
It is not clear how to read this. It is not possible to see where the numbers end and the letters start. In this example, you may be able to guess that there is a b and a d, not a 2 and a 4. However, In strings like 12cde67hij, you certainly won't be able to see where the letters start.

Technical background

NVDA sends text to the liblouis braille translator using the pass1Only mode flag. From liblouis/liblouis#133:

trace_translate , the general translation function in lou_translateString.c calls translatePass for pass2, 3 and 4. translatePass does currently not update the output positions.

Specifically, this leads to the problem that cursor routing is said to break in NVDA as the braille character to output position mapping is broken. I wasn't able to reproduce this using the example above, though.

CC @josephsl @dkager

[LeonarddeR]

Relevant information from #2439 (comment)

(Side question: why does NVDA disable the multi-pass facilities when forward translating?)

Because multi-pass breaks the input/output position mapping. I have had grand ideas of completely rewriting that position mapping code for a while, but I've never gotten to it. Arend Arends contributed a patch for this, but it hasn't been integrated yet and I believe there are some outstanding concerns

[feerrenrut]

If I understand correctly, this is blocked by liblouis/liblouis#133 however once that issue is addressed this would be a fairly high priority fix.

[LeonarddeR]

@feerrenrut: This is true. However, I recall @jcsteh saying that it is desired to have a fair amount of unit tests, especially for edge cases. As for literary braille tables, I'm only know the Dutch table pretty well, so contributions (str's) from others are more than welcome.

[jcsteh]

In this case, it'd be best to add any tests to liblouis. If it's tested well there, I don't think we need additional tests in NVDA. If you can come up with some examples that break, it shouldn't be too hard to add tests for them. When you say your example doesn't seem to break, did you test mapping in both directions; i.e. that routing routes to the correct case and also that moving the cursor with the keyboard moves the braille cursor to the right place?

[LeonarddeR]

When you say your example doesn't seem to break, did you test mapping in both directions; i.e. that routing routes to the correct case and also that moving the cursor with the keyboard moves the braille cursor to the right place?

Yes. For characters spanning multiple cells (e.g. numbers), cursor automatically ends up at the right most braille cell.

[dkager]

The Dutch table is quite well tested, but only for forward translation. We should add tests for input/output mapping. I think the lou_checkyaml tool allows for this already.

[LeonarddeR]

I tried to reproduce my str in JAWS, and it seems like they do use multi pass for liblouis.

[LeonarddeR]

@BueVest suggested to make this a GUI configurable option. Although I disagree with the idea to make this GUI configurable, I belief it should be considered to make this a hidden option. This will allow us and liblouis folks to test possible brokenness in liblouis using NVDA.

Thoughts @michaelDCurran, @dkager, @jcsteh, @josephsl and others?

[josephsl]

Hi, I’d say a private function or a config key should be provided for this and others, and let this be a volatile key (reset when NVDA restarts). Thanks.

[LeonarddeR]

@josephsl commented on 25 Oct 2017, 20:26 CEST:

let this be a volatile key (reset when NVDA restarts). Thanks.

Tend to disagree with this. Though an option in the gui is too much, this won't be a proper solution for people like @BueVest.

[BueVest]

Tend to disagree with this. Though an option in the gui is too much, this won't be a proper solution for people like <https://github.com/buevest> @BueVest. Agree. A volatile key will still leave Braille unusable to Danish and Polish users, possibly others.

[zstanecic]

How about adding multipass in the options and making it documented with the description for the normal user? Maybe it messes up the imput for the polish grade one table?

[josephsl]

Hi, or we should have a snapshot series with this option added for testing purposes. We should document this if and only if testing says it can be done safely, as this is mostly an internal change. Thanks.

[zstanecic]

Hi, If you can do it, do it, i am not against it. It will help us, to see, wich tables can be used with multipass. Maybe this will fix some ueb errors

[LeonarddeR]

@josephsl commented on 25 okt. 2017 23:01 CEST:

Hi, or we should have a snapshot series with this option added for testing purposes.

Not intending to be headstrong, but I also tend to disagree with this one:

1. There are currently people suffering from our use of pass1only, see Danish contracted eight dot braille doesn't show capital characters #7526. Having a snapshot series requires maintenance for testers and try build creators (i.e. they can't be updated automatically).
2. The issues with multi pass are probably quite hard to track down. It requires intensive testing from braille users, especially those using contracted braille. A hidden config option in official builds increases the likelihood that people will test this. I, for example, will from now on use multi pass by default. Pretty sure @BueVest and @zstanecic will join me in this. This is in the interest of both NVDA and Liblouis.

Side note: JAWS also uses multi pass in production.

[dkager]

I'm not even sure why pass1Only is a flag. What point is there in half a translation, other than working around bugs in the translator? No table I have seen so far properly "falls back" to not using multi-pass if it is disabled. So ideally, whatever is broken in liblouis should be fixed (yes, I know that's an unpopular task) and the evil flag should be removed.

[zstanecic]

Yes, i agree with you, as the multipass is implemented also in jaws on braille imput, and it works bettter with the unicode tables

[BueVest]

I have thought along the same lines. No tables can handle a fall-back to pass 1 only because there is currently no way that a table could detect that the flag is being used. Also, enabling a feature using pass 1 only may require quite a different approach than using multi-pass, so handling a fall-back properly may be rather difficult if not downright impossible. Personally, I think this flag should be for internal Liblouis debugging purposes only. As others have said, JAWS now uses multi-pass in production. So, the least we could do is to have the option to use it. Apart from the trouble the users are having, as a table author, I would much rather have complaints over faulty cursor positions and trying to fix those instead of having users complaining that the tables don’t work at all and switching to JAWS for that reason, not knowing that JAWS uses exactly the same tables.

[LeonarddeR]

@jcsteh: Would you be able to give your view on the last few comments? I belief you were a strong advocate of using pass1only.

@michaelDCurran: Given the concerns below, I belief it might be good to merge #7702 into master before the 2017.4 release, to at least give people switching capabilities inside a release version. After that, we could considering making multipass the default for next.

Note that, even though JAWS uses this in production, we don't know whether JAWS internally accounts for multi pass failure in a different way than we do.

[michaelDCurran]

I don't have a problem with getting this into Master for 2017.4, as by default the behavior has not changed, and the user has to take explicit action to get the new behavior.

[BueVest]

So, is it going to be merged in 2017.4?

[zstanecic]

Quoting @dcurran I don't have a problem with getting this into Master for 2017.4, as by default the behavior has not changed, and the user has to take explicit action to get the new behavior. There is one problem. Document in the user guide what multipass is, how this affect user, and how this option works. Put this in the advanced topic section of the user guide. W dniu 02.11.2017 o 09:04, BueVest pisze:

…

So, is it going to be merged in 2017.4? Fra: Michael Curran ***@***.*** Sendt: 26. oktober 2017 11:23 Til: nvaccess/nvda ***@***.***> Cc: BueVest ***@***.***>; Mention ***@***.***> Emne: Re: [nvaccess/nvda] Disable pass1only for liblouis braille output (#7301) I don't have a problem with getting this into Master for 2017.4, as by default the behavior has not changed, and the user has to take explicit action to get the new behavior. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7301 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AMFZiX1VfTOVtoF1xi-yMN_5RaIvW5ywks5swE-MgaJpZM4N942I> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7301 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKohk_43o6z0kc8ELmWcGUD6jhm0UpWeks5syXd9gaJpZM4N942I>.