Table difference check for determining when the gaux file should be saved is too fragile

[henryso]

See #984 (comment)

[eroux]

This is even a bit more than that: the goal of saved_pos is to check if there's a difference between two y positions during the first run and the first run only, it should never write other positions.

The best would certainly be to just write "euouaeOnDifferentLines : true" in the gaux file (if and only if there's no such value in the gaux file already), and save positions all the time, or just forget about euouae positions if they're not used

[henryso]

It is possible to have more than one <eu> block, so it is a bit more complex than just storing a boolean.

[eroux]

it would be a boolean per index, not much more complex...

[eroux]

If we want to do it correctly, the most robust ways seems to be to store the resuts (and not the positions implying the results) in the .gaux file. For instance there should be a is_on_same_line per euouae block index, but also a var_brace_length per brace, etc. Plus an additional first_compilation_only flag that would be used for euouae line change. This would allow to store the length of the braces at each compilation if necessary (it may be neessary sometimes, especially in the case when the line before euouae block is ragged, which changes all glyph position), without having problem with changes in x or y positions that can differ between two compilations. It's quite a big change, and it's on code I'm not completely familiar with, so let's do it in 4.2, especially since the case where it may cause a bug are quite rare.

[henryso]

Do you have an example I can use to test the fix?

[eroux]

I'm not entirely sure, but I think if you make a slur or brace on the line before an euoae block, current code should fail if this line is ragged on the second pass...

[henryso]

Do you mean the line that will be made ragged if the euouae is on the next line or the line before that line?

[eroux]

the line that will be made ragged when the euouae block is not the next line yes

[henryso]

I cannot, unfortunately, reproduce the problem. There is no difference between my implementation of the more robust solution and the current algorithm. Should I push my changes anyway for review?

[eroux]

Yes please. I was also thinking about a few simplifications: the width of the different braces could be written at each compilation, while informations about the euouae block should not be overwritten after the first compilation... but maybe you already do that?

[henryso]

Should I create the pull request against develop or against a fix-987 branch in the main repository?

[eroux]

develop is fine

[henryso]

I don't think it's necessary to add an extra check for first compilation for the euouae block. Since we are only storing true/false now, it should become stable after the first compilation.