UEB: Incorrect usage of passage mode

[rob-aph]

I have the following:

<math>
    <mn>9</mn>
    <mo>+</mo>
    <mn>4</mn>
    <mo>=</mo>
    <mo>?</mo>
</math>

Computed braille string:
⠰⠰⠰⠼⠊⠐⠖⠼⠙⠀⠐⠶⠀⠦⠰⠄

I tried fixing this myself, but no clude why passage mode is used here. If I use a variable instead of a question mark, it works as expected, using a single grade 1 indicator for the variable.

[NSoiffer]

Looking at it, there is definitely a bug in the code that says whether G1 Word mode is needed. A BANA rule about 2 or more whitespace chars triggers the passage mode.

There is a very similar example in GTM in section 3.6. For some reason, I skipped over adding tests from that section, so I'll add the examples from there to the tests and hopefully eliminate this bug and maybe some other bugs.

[NSoiffer]

This took a while to hopefully get right. After adding all the omission examples and redoing the code, there is now one test failure, but I think the MathCAT choice is better than the ICEB one...

In GTM, 9.7 (Statistical Functions), the second example is "Exp(R) = n/2 + 1" (where the division is a 2D fraction). GTM says the braille should be

⠰⠰⠰⠠⠑⠭⠏⠐⠣⠠⠗⠐⠜⠀⠐⠶⠀⠷⠝⠨⠌⠼⠃⠾⠐⠖⠼⠁⠰⠄

and MathCAT now finds

⠠⠑⠭⠏⠐⠣⠠⠗⠐⠜⠀⠐⠶⠀⠰⠰⠷⠝⠨⠌⠼⠃⠾⠐⠖⠼⠁

This is shorter and is consistent with two other examples (omission_3_6_7 and fraction_6_4_6) that use a word indicator later in the output.

@rob-aph: do concur that is better output, or at least on par with what GTM uses?

[rob-aph]

I believe the GTM braille for 9.7 is correct, because the R in parentheses could be interpreted as "Rather."

[NSoiffer]

When I implement #223, that would tell me the test result is MathCAT came up with is bad. You've given me early warning...