Formatting Error in TeXShop after Line Break with Clef Change

[signumaltum]

I am encountering an error in using Gregorio (4.2.0) with TeXShop for Mac. Certain Gregorio files will corrupt if the file is Typeset twice or more. Specifically, an individual line will display with the pitches and clefs shifted up or down one to three steps. I have included a picture below of the corrupted line (the remainder of the piece displays normally). The display error is limited to only one line of the piece. The problem only seems to occur in files with multiple clef changes (a necessity for several pieces I’m typesetting). Based on some troubleshooting, it seems that the bug may be caused when a clef change with a breath mark (, ; :) occurs at the natural break of the line, e.g. (z0,c3). In this case, if I use the code (z0c3) after the word "angelo," there is no error. Notice the line with the text “qui volare voluit.”

Typeset once (correct):

Same file, Typeset twice (corrupted):

Here is the entire GABC:

%%
(c4) O(ev) glo(fv)ri(dv)o(c)sis(dv)si(de)mi,(ev) (,)* lux(gv) vi(gh)vens,(hg) an(fe~)ge(de)li,(ev) (,) qui(ed/c/dc) in(dde~)fra(ev) di(ev)vi(eh)ni(jvIHG)ta(hg)tem(fvED/ev) di(ev)vi(ede)nos(gc/dc/dwe) o(hg/hwjHG)cu(ghGFE)los(evDC/dwe) (e+f3) cum(gfg) mi(iv)sti(hg)ca(gv) ob(cgFE)scu(fv)ri(evDCBcv)ta(dbc)te(cv) om(jilJIji~)nis(hg) cre(cb)a(ef)tu(evDCB)re(cv) as(cv)pi(cv/fgf)ci(fvEC)tis(ebc) in(hv) ar(ji)den(ji)ti(hvGF)bus(gv) de(klwm)si(mvLK)de(lvJI)ri(jvIHGF)is,(gv) (,) un(hvGFfg~)de(ge) num(hvFE/fvEDC)quam(dbc) po(ghwi)tes(ivHGF)tis(gv) sa(iji)ci(hg)a(fg)ri:(gv) (z0;c4) O(egfjHG) quam(hvFE) glo(ijwk/lvKJI)ri(jvHG)o(hg)sa(fvEDev) (a+f3) gau(ceDC/dc~)di(bc)a(cv) il(C1D1fv/hvGF/gf~)la(e) ve(ghwi)stra(hvGF/gv) (z0c4) ha(ehgjHG/hvFED)bet(ev) for(ijwkJI/jvHGhg~)ma,(fvEDev) (,) {que}(dec) in(E1F1gv) vo(hg)bis(fvEDC) est(ded) in(dh)tac(ixkvJI/jvIHG)ta(hv) ab(ivGF) om(gf)ni(ed) pra(fg/hd)vo(fcd) o(hgj)pe(jvIHG)re,(hv) (,) quod(hkj/kwmKJ/kvIHG/hv) pri(hghGF/gv)mum(fvEDC/dv) or(fvEC/efwgFEDCB/cdcd)tum(fvEDC) est(ded) in(ixhg/hhwj) ve(jvIHG)stro(hv) so(kj/kkwmKJIH)ci(gfg)o,(hv) (,) per(ixhd/hv/ivGF)di(gf)to(ed/cd/ed) an(hghGF/gf~)ge(ed)lo,(fvEDC/dv) (z0:c3) qui(ghwiHG) vo(gfgFE/ffwg//lk/jjwlIH)la(if/efc)re(dvCBA/bv) (z0c4) vo(dvCA/cd)lu(fvEDC)it(dv) sup(hvGF/gf)ra(ed) in(fvED/ed~)tus(cd) la(dvC0A0//B1C1/dc)tens(ded) pin(hvGF/gvFD)na(hg/hi)cu(ikj/mvKJ)lum(ixkvIHGF) de(hd/fvEDC)i.(dv) (:) Un(adc/d@f/@fe~)de(c) ip(e/fwgFED/fvEDC)se(ded) tor(dh)tu(jm/LKJ)o(kjk)sus(ivHG/hv) di(dc)mer(fgf)sus(evDC) est(dv) in(dvC0A0//B1C1dv) ru(fv)i(evDC)nam;(ded) (;) sed(dh) ip(kj)si(ixivHG)us(hv) in(hv)stru(kmLKJ)men(kj~)ta(ixih) ca(df/gvFED)sus(fcd) con(dh)si(hvGF)li(hv)an(kvJI/jV/@ji~)do(hgh) fac(hkj/kwmKJ)tu(ixkvIHG)re(hv) di(ixdh/ivGF)gi(gf)ti(ed/cd/ed) de(cd)i(dv) in(fvED)sti(fgwhg)tu(hg)it.(fvED/ev) (::)

[henryso]

This one seems egregious enough to be in 5.0. The symptoms seem to indicate a problem in TeX or Lua.

[henryso]

I need a hint. I inspected the calls to \gre@calculate@additionalspaces, and they look the same whether the line break occurs slightly before or right at the (z0,c3). Therefore (I suppose) there is some other register that's causing the notes to shift at that point. Any clues as to what I should be looking for?

[rpspringuel]

@signumaltum How much of that gabc file is actually needed to reproduce the error? I'd like to inspect the gtex generated when the error occurs, but there's too much here to wade through. I'd also like to determine just how consistent the upward shift is and having a simpler file would make playing with the variations easier.

My preliminary thoughts are that the error has to be in something that is used to calculate the position of the notes, but not the staff lines (since they remain in the correct position). This says to me to look at registers which are involved in calculating note positions, but not staff positions.

Furthermore, I notice that everything goes back to normal on the very next line. Therefore, I would look at which temporary distance registers are being used in the clef change and which are being used in the line breaking code. If there's overlap in these two then it may be that we're seeing an interaction where said register is being modified by both algorithms at the same time, and both are expecting it to be theirs and theirs alone during its use. In that case I would try switching one of them to use a different register.

Along those later lines, it might be useful to consider implementing one of two options:

1. Get rid of the general temp registers altogether and use individualized registers for those occasions where we currently use them. This would increase the number of registers used significantly, but since eTeX gives us 32,768 of them, I don't think we're in any danger of running out (TeX's more limited 255 would be more problematic).

2. Devise some system for telling which temp registers are in use and which are not. This is not something that TeX can do automatically, so we would have to manually declare them 'in use' and then 'free' them when we're done.

Both of these would require some pretty extensive changes throughout the code, so maybe we put them off into their own issue. There are, for instance, 271 occurances of gre@skip@temp in the tex files which would need to be examined.

[henryso]

@rpspringuel I have a trimmed-down subset of that gabc which shows the problem. I'll push it to a branch of the test repository.

[henryso]

@rpspringuel See henryso/gregorio-test@5289206. If you uncomment the %(ggg), the line break will be shifted elsewhere and the problem will not occur.

[henryso]

I'm not having any luck debugging this problem. I'm going to have to raise the surrender flag, at least for now.

[rpspringuel]

I completely forgot about this. I'll see if I can't make time for it when I finish the fonts.

[rpspringuel]

Okay, I have to take a break from this for now, but after doing some playing I've figured out the following:

Because all the notes in the sequence are being affected, the problem must be in the calculation of constantglyphraise (or one of the values that goes into it). This supposition is further reinforced by the fact that this value appears to be recalculated at each line break.

Adding some debug messages to the log, I get the following information about this value:

1st pass:

GregorioTeX debug: (heights) constantglyphraise = 27.8826pt
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt
Inserting `gregoriotex.post_linebreak' at position 1 in `post_linebreak_filter'.
Inserting `gregoriotex.disable_hyphenation' at position 1 in `hyphenate'.(load l
uc: /Users/RPS/Library/texlive/2016/texmf-var/luatex-cache/generic/fonts/otl/lmr
oman9-regular.luc)(load luc: /Users/RPS/Library/texlive/2016/texmf-var/luatex-ca
che/generic/fonts/otl/lmroman9-italic.luc)(load luc: /Users/RPS/Library/texlive/
2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman17-regular.luc)
GregorioTeX debug: (heights) printing minima
GregorioTeX debug: (heights) printing minima

Overfull \hbox (8.45567pt too wide) detected at line 333

2nd pass:

GregorioTeX debug: (heights) constantglyphraise = 27.8826pt
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt
Inserting `gregoriotex.post_linebreak' at position 1 in `post_linebreak_filter'.
Inserting `gregoriotex.disable_hyphenation' at position 1 in `hyphenate'.
Module gregoriotex Info: \gre@calculate@additionalspaces{11}{5}{0}{0} on input l
ine 8
GregorioTeX debug: (heights) constantglyphraise = 27.8826pt
GregorioTeX debug: (heights) constantglyphraise = 27.8826pt
(load luc: /Users/RPS/Library/texlive/2016/texmf-var/luatex-cache/generic/fonts/
otl/lmroman9-regular.luc)(load luc: /Users/RPS/Library/texlive/2016/texmf-var/lu
atex-cache/generic/fonts/otl/lmroman9-italic.luc)(load luc: /Users/RPS/Library/t
exlive/2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman17-regular.luc)
GregorioTeX debug: (heights) printing minima
GregorioTeX debug: (heights) printing minima
Module gregoriotex Info: \gre@calculate@additionalspaces{14}{3}{0}{0} on input l
ine 255
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt
GregorioTeX debug: (heights) constantglyphraise = 36.08463pt

Overfull \hbox (8.45567pt too wide) detected at line 333

As you can see, the second pass throws in two extra calculations of constantglyphraise (I'm fairly certain the debug messages are duplicated because one occurs while boxing and the other while printing). The first of these is immediately preceeded by a call of gre@calculate@additionalspaces from the lua code and puts the value of constantglyphraise back down to the ~27pt value. I think that's the right thing to do, because if I manually override the calculation of constantglyphraise and force it too that value, the nots (though not the ledger lines) end up in the right place. Thus I think the second call of gre@caluclate@additionalspaces, which results in constantglyphraise taking on the ~36pt value, is spurious. I have not, however, been able to figure out why it's being called yet.

[rpspringuel]

Okay, turns out that the printing minima message repeat is due to the boxing, but the repeating of the constantglyphraise messages is because the calculation was being redundantly called (once by \gre@calculate@additionalspaces and once by \gre@removetranslationspace, which is also called by \gre@calculate@additionalspaces. I'm checking right now if I can remove that redundancy.

[rpspringuel]

No time to do additional work now, but I had a new thought which I want to make sure I don't forget:

Instead of it being constantglyphraise which is being miscalculated (too high a value pushing the notes up), it might be that the \gre@generatelines is using a faulty value for the spacelinestext. It's value seems to be the same on the bad line as on the previous line. It might be worth trying to get rid of the really low notes on the bad line and see if that eliminates the problem.

[rpspringuel]

I've looked at the constantglyphraise issue every way I can think of and can't find a problem in that area.

To do some further study, I manually compiled the gabc file and used the nevercompile option. This way I could manipulate the gtex file directly and see what result that had on the outcome. In particular I noted that by commenting out the \GreDivisioMinima command inside the clef change discretionary resulted in the score printing correctly. This is in keeping with the @signumaltum observation that the presence of the divisio was needed to trigger the bug. Intrigued, I examined the log for this run and compared it to the log for a run with that command uncommented (in both cases, looking at the second run log). When the diviso command is commented out, gregoriotex.lua inserts the line break stuff before the clef change discretionary, resulting it calling both \gre@caluclate@additionalspaces and \gre@updateleftbox. When the divisio command is not commented out (and thus the score is faulty) the gregoriotex.lua insertion occurs inside the discretionary and so while \gre@calculate@additionalspaces is called \gre@updateleftbox is not. Since the lines are in the leftbox I suspect that what's happening is that we're not really updating the lines properly after the new spaces are calculated.

Does anyone recall why we don't want to call \gre@updateleftbox inside the discretionary?

[henryso]

I was not part of the inception of that code. Maybe @eroux will know.

[rpspringuel]

Okay, I don't know why yet, but I can say that \gre@updateleftbox raises an "invalid discretionary list" error when it appears inside the discretionary. By not calling it, we avoid that error, but if my suspicion above is correct, we've traded an error for bad output in this corner case. I'm going to have to explore and see what it is that \gre@updateleftbox is doing that the discretionary doesn't like.

[rpspringuel]

Okay, so the culprit appears to be \localleftbox itself. We can't call that inside a discretionary, so naturally we can't call \gre@updateleftbox inside the discretionary. This means that the lines aren't updated and throws off the line spacing algorithm. Eliminate the super low notes in that line in the score and the problem "disappears" (actually becomes irrelevant because there is no need to correct the line heights).

Since the line break occurs inside the discretionary, we have to adjust the line heights before entering the discretionary. Now, \GreSetLinesClef is the function responsible for changing the clef on subsequent lines and is called right before the discretionary. Right now it just uses the spaces as they exist at the time of the call (i.e. for the current line). I think what we need to do is make this function look ahead at what line heights are indicated for the next line. Any ideas on how to make that work?

[henryso]

It it conceptually possible to get the low and high heights on the following line through Lua. How would you need the values? I suppose the Lua call could generate a macro call with the values you need.

[rpspringuel]

What I need is basically the output of\gre@calculate@additionalspaces to be effective for the purposes of \GreSetLinesClef. One foreseeable problem is that \GreSetLinesClef can be called mid-line too, so once the left box is updated, the distance changes need to be reverted until we reach the end of the line (otherwise the changes to stuff like \gre@dimen@constantglyphraise will throw off the subsequent glyph placement on the current line).

Based on that I might envision the following procedure:

1. \GreSetLinesClef stores the current line values for the distances affected by \gre@calculate@additionalspaces
2. \gre@calculate@additionalspaces is run with the line height information for the next line
3. we update the \localleftbox using the next line values
4. we restore the current line values for the various distances and proceed with typesetting the rest of the line
5. when the line is ended, the \gre@caclulate@additionalspaces is executed again, setting the various distances for the next line correctly (I'm fairly certain this step is already taken care of by the current code)

Step 2 & 3 is, I think, where the Lua function call would come into play. Indeed, the function would probably look like adjust_line_heights except that it would always call \gre@updateleftbox and would not be called at the line break and so has to look ahead.

[henryso]

OK, I'll create a Lua function that will call \gre@calculate@additionalspaces with the heights for the next line. If I can't complete the implementation of the procedure you outlined, I will push my changes to a shared branch on the gregorio-project/gregorio repository.

[henryso]

The issue I'm running into is handling the per-line spaces and counts. It'll take a bit more time.

[henryso]

I implemented the function. I tried to apply it in \GreSetLinesClef.

Before setting the local left box:

  \gre@save@additionalspaces %
  \directlua{gregoriotex.adjust_line_height(\gre@insidediscretionary, true)}%

After setting the local left box:

  \gre@restore@additionalspaces %

However, this has some strange effects because \GreSetLinesClef is used a number of times, including for the initial clef. I have created a fix-1285 branch with the function changes (but without the change shown above). I tried a few other random things without success, but for me, it's like feeling around in the dark.

[rpspringuel]

Did it at least work in the case which started this whole thing?

I'm working on something else right now, but when I finish that I'll come back to this.

[henryso]

It's hard to tell. It seems (visually, at least) to have applied the second line heights to the first line, so I can't really tell if it's helping in that case.

[rpspringuel]

When I attempt to use this function I'm getting an error: TeX capacity exceeded, sorry [text input levels=15]. This only occurs on the second run and increasing that capacity doesn't help (I tried upping it to 100 and the error persisted). This seems to be indicating that there is an infinite file opening loop some where in the lua code that gets activated on the second run. Did you encounter anything like this, @henryso?

[henryso]

I did not run into that problem. From where are you calling the function?

[rpspringuel]

I added the function call to \GreSetLinesClef as you described above.

[rpspringuel]

I put the additions closer to the \gre@localeftbox call, but moving them to be exactly like yours doesn't make a difference.

Interestingly, the error occurs only when I try to call gregoriotex.adjust_line_height inside GreSetLinesClef. If I put the function some where else, it works just fine. I'll play around with that and see if I can work with that, but I'm at a loss for why I'm getting the error and don't have time to whittle things down to create a MWE suitable for posting on StackExchange.

[henryso]

Can you put your test in the fix-1285 branch in the test repository?

[rpspringuel]

I'm working with the test that you put in the repository.

[henryso]

Ugh. I was hoping it was some other test. I definitely don't get that error with that test. It occurs to me now, though, that I am using the fix-1285 branch as in my repository, and not the one with your proposed changes (trace, etc.). I'll see if I can prep a repository with that stuff in it to see if there's a difference.

[henryso]

I cloned your repository, fetched fix-1285 into it and merged fix-1285 with trace. I still don't get that capacity error. I'll keep trying stuff, but I'm at a loss here.

[henryso]

I did a tlmgr update --all, and still no luck reproducing your problem. If you have (or anyone has) any ideas I can try, I will, but I'm out of my own ideas.

[rpspringuel]

I tried working with just your branch (and nothing from any of mine), but still get the error. The only thing I can think of right now is that the end of line call of \gre@calculate@additionalspaces is getting injected into the \GreSetLinesClef call of the same thing (via adjust_line_height) resulting in the infinite loop. Of course, that means that the end of line call has moved outside the discretionary (and to a different place from where you're system is putting it), so the explanation doesn't quite feel right. The only thing I can think of to try (and it will have to be tomorrow for me) is to insert a flag which indicates when we're inside \gre@calculate@additonalspaces and use it to prevent adjust_line_height from injecting a call of that function inside itself.

[henryso]

What really doesn't make sense is that you are getting a capacity error and I am not, with the same test, which then does not indicate infinite recursion. I am not skilled enough with TeX-fu that I can try to adjust how my setup works to try to reduce its capacity somehow.

[rpspringuel]

The input file capacity can be adjusted by adding the following line to texmf.cnf:

max_in_open = 100

The number indicates the file limit. You can check the value with kpsewhich --var-value max_in_open (which you should probably do first).

You can check for the location of texmf.cnf with kpsewhich, but if you've never modified it before, then chances are you'll only have copies in the distribution specific directories. In that case you should add one to the equivalent folder in your texmf-local or personal user tree. You only need to have the line given above in the new file as the settings in texmf.cnf override each other on a variable by variable basis.

[henryso]

Ok, I am now able to reproduce this problem. I'll try a few things out over here as well. Thanks for the tips.

[rpspringuel]

I tried upping the limit on my system again and found that I have an inbuilt limit of 600 and that this still isn't big enough to get rid of the error.

[henryso]

Ok, I changed the Lua function to not call \gre@updateleftbox (which calls \GreSetLinesClef) when it's called for the next line. This produces some really wacky incorrect results in other tests, but at least it doesn't cause the problem you found (and does seem to work for that test case).

[rpspringuel]

A quick test and I see what you mean about it breaking other tests. However, it also doesn't seem to work completely for the test case. The lines and notes are aligned right for the second and subsequent lines, but the divisio minima and the custos at the end of the first line are now pushed high. It also looks like the ledger lines on the third line are high and the lyrics are overlapping with the bottom notes.

All the broken tests make me think that we're not calling \gre@updateleftbox enough. We may have to break that infinite loop in some other fashion.

[henryso]

\gre@updateleftbox calls \GreSetLinesClef so either we call the Lua function somewhere other than \GreSetLinesClef or we call \gre@updateleftbox in such a way that doesn't call \GreSetLinesClef. In the latter case, I guess we need to understand how much of \GreSetLinesClef still needs to be called in this situation.

[henryso]

I took a look at those macros. \gre@updateleftbox calls \gre@updatelinewidth and \gre@updatelinesclef. \gre@updatelinesclef calls \GreSetLinesClef. I tried modifying the Lua function to call \gre@updatelinewidth when it is called for the next line measurements, but this doesn't help the problem (same weird results). Perhaps the approach of doing this from \GreSetLinesClef is wrong.

[rpspringuel]

I think you may be right, but can't think of an alternative at the moment. I'm going to have to brainstorm that one for a bit.

[rpspringuel]

Okay, in order to help figure this out, I'm going to try and lay out the issues:

1. When we change clef, we need to update the macros which hold the clef information (\gre@clef et al.). Currently we do this by inserting \GreSetLinesClef into the gtex file. This calls \gre@save@clef which does the actual saving.
2. Changing the clef also requires that the contents of the localleftbox need to be updated (by calling \gre@localleftbox). \GreSetLinesClef does this directly, which is useful for when the line heights are not being adjusted. When they are being adjusted, then we insert a call of \gre@updateleftbox (which calls \gre@updatelinesclef which calls \GreSetLinesClef) at the end of the line after we've calculated the heights for the new line.
3. Finally, when changing the clef at the end of the line we don't want the new clef to be the last element on the line so we make use of \GreDiscretionary so that a line break at this element will be have as desired behavior.
4. \gre@localleftbox cannot be called inside a discretionary (specifically the \discretionary primitive), and thus it (and anything that calls it) can't be inserted at the end of a line which ends on a clef change (i.e. a discretionary). This means that updating the left box has to happen before the discretionary, which of course requires knowledge of the next line's heights. However, we can't actually switch to those distances yet because they are used to position any glyphs inside the discretionary.

Have I missed anything?

Assuming I haven't, and our attempt to update change the distances inside \GreSetLinesClef isn't working, we could try changing the distances inside \GreDiscretionary (before invoking \discretionary). The issue is that we'd then have to update the left box (either explicitly, or by calling \GreSetLinesClef).

[rpspringuel]

I just tried it, and it appears that working inside \GreDiscretionary might work (at least for the test case). I'm running the full battery of tests now to check that it doesn't break anything else. If it's all good, then I'll post a PR in the morning.

[henryso]

I tried it as well and concur that is works. However, in running tests, I discovered that I am not saving enough dimensions in \gre@save@additionalspaces. I have this corrected and will merge them into fix-1285 in the gregorio-project/gregorio repository.

[henryso]

The fix-1285 branch is updated.

[rpspringuel]

I've confirmed the changes and created the PR.