Bar spacing in Lua - #1764
Conversation
- Replicates bug gregorio-project#959 and gregorio-project#1734. - Two bars in a row are spaced differently than before.
…able and \GreBarSyllable; this also fixes a very minor bug in syllable_clearing
…SyllableBeforeEUOUAE. - \GreLastOfLine was previously used to anticipate forced line breaks and clef changes. This is now done in Lua. - It was also called by \GreLastSyllableBeforeEUOUAE to change the syllable-final skip before an euouae. But the syllable-final skip is always dropped at a line break, so making \GreLastSyllableBeforeEUOUAE into a no-op seems to have no effect; in particular, the test euouae.tex still passes.
Deprecate syllable_first_type().
|
There are currently 37 tests failing. Consecutive bar syllablesThis is the biggest category. If there are two bar syllables in a row, the first syllable's nextbegindifference did not equal the second syllable's begindifference (issue #1734, case 2). However, it's not really clear what the right behavior is. A bar syllable depends on both the previous and next syllable, so when there are two bar syllables in a row, what should be done? The intent of the old code seemed to be to initialize both bar syllables so that the bar is aligned above the text, then adjust the first bar syllable, then adjust the second bar syllable. That's what the new code does. Better in my opinion
Don't know if better or worse
Punctum mora adjustmentIn my opinion these are all better. New code uses actual width of punctum mora and space before it
When punctum mora occurs before a clef change, and there is no break, the old code didn't use correct punctum mora adjustment.
A syllable that has nabc that extends beyond a punctum mora doesn't need a punctum mora adjustment.
Bars with no text (added after 9d45861)When a bar syllable has no text, there's an empty text box whose position sometimes affects spacing before and after the syllable. Now the text box is centered directly under the bar. In my opinion better:
Other featuresIn my opinion these are all better. Syllable clearing for bar syllables is more accurate
Old code computed eolshift using the width of a custos, even when the custos was disabled or flatted.
Old code adjusted for alteration in the next syllable, even if it's on the next line
In clef changes, old calculation uses wrong nextbegindifference (issue #1724 case 1 and #1191)
Tests that revealed new bugs
Miniscule or no difference, except in debugging marks
Tests that need a closer look
|
…nderneath the bar so that it doesn't interfere with the spacing before and after the syllable. Fixes tests fix-845 and breaks fix-928-unison-no-break and flexus-stroke (but for the better).
|
Just doing a first pass review to categorize this by milestone. If I've seen things correctly, this doesn't change any user facing code and so could be put into a 6.3.0 release. @davidweichiang can you confirm that's the intention? |
|
Correct, this shouldn’t have any user facing changes except very slight changes in spacing. |
Changes I'm willing to accept:gabc-output/glyphs/bars.gabc Changes that look problematic to megabc-output/empty-syllables.gabcI don't like how close the 3 gets to the 2 in this one. They seem to combine into a single word when they are clearly separate words in the source. The 10/11 space works better. Other notesgabc-output/bugs/fix-928-unison-no-break.gabcThis is definitely better, but there are still custos (and a barline) outside of the staff, so this test is still revealing a bug that needs fixing. Do we have an issue for that? gabc-output/glyphs/bars.gabc
|
How about 6-7? I'll dig into this a little bit. I thought there should be interwordspacetext and it doesn't look like there is. |
|
A brief update on empty-syllables.gabc: (a) As noted above, there are some oddities in how spacing between two consecutive bar syllables is computed (including issue #1734 case 2, but maybe others). In the Lua implementation, I didn't try to replicate these. (b) Syllables ordinarily have a space after (syllablefinalskip), which is often negative. In the new bar spacing algorithm, a bar overrides the previous syllable's syllablefinalskip. However, there are some cases where the previous syllablefinalskip is retained, but the bar spacing is still computed as if the syllablefinalskip were not there. This includes when the previous syllable is a bar. In the Lua implementation, I did try to replicate these. In the case of empty-syllables.gabc, these two choices combine in a bad way, and I agree that it must be fixed. Since both (a) and (b) both look like bugs to me, I would rather fix it by reducing the cases where (b) occurs than by replicating (a). If you (@rpspringuel) agree, I'll look into how to do that. |
|
The above commit suppresses (b) in the case of two consecutive bar syllables. empty-syllables.gabc now looks like this, which is unexpectedly even: 
No new tests fail, but it's possible some of the failing tests got better or worse. |
I think these are just overfull hboxes, right? |
|
I went ahead and accepted empty-syllables.gabc as well as some of the ones that we agree are ok. I believe you're okay with the others, too, but will leave them for final discussion. gabc-output/glyphs/high-bars-2-lines.gabc: consecutive bar syllables are now closer together, but not too close gabc-output/glyphs/bars.gabc: The comma under the first quarter bar looks worse to me. The 2nd line and following lines start with a bar (which I didn't realize was possible) and the bar sits considerably closer to the clef. It used to be that the 2nd line's first bar was almost (but not quite) aligned with the 1st line's first bar, but now they look very different. tex-output/bugs/fix-1503/fix-1503.tex: clef change sits closer to the clef tex-output/nabc-skip-alterations/nabc-skip-alterations.tex: note with nabc sits farther from bar or clef change, better? |
|
For the test The second difference ("the bar sits considerably closer to the clef") is because of a change in how no-text bar syllables are handled. In both implementations, there is a zero-width text box. In the old TeX implementation, this box was placed like any other text box (midway between the neighboring text boxes). In the new Lua implementation, this box is placed directly under the bar (where it will not impact neighboring syllables). If I recall correctly, there was a case where the old placement was creating needless space and the new placement was better. (If you want, I can try to remember what case that was.) This difference is another such example; the old implementation shifts the zero-width text box to the left, creating extra space at the beginning of the line. I believe the new way makes more sense and propose not to change it. |
|
I went ahead and accepted the changed results of the |
|
I'm a bit busy with the start of School this week and next. I'll get back to looking at this stuff in a couple of weeks. |
2 participants
This follow-up to #1720 moves both the old and new bar spacing algorithms to Lua, as well as a few other computations. The result is that much of the redundant information in .gtex files can be eliminated.
Remaining to-do items: