Misplaced horizontal episema

[ebydj1]

When I try to write this:

præ(j_h)

I see this:

In a previous (>1 year old but I'm not sure exactly which) version of Gregorio the horizontal episema was on the first note. As I understand gregorio's syntax, it should be on the first note, shouldn't it? I can't figure out how to place it on the first note now. (The example is from the gradual of the Immaculate Conception, for the record.)

I am using gregorio 5.0.1 (from the Arch AUR).

[henryso]

I tried this with the GregorioTeX in TeX Live and am unable to reproduce it. Please run the system-setup.command in the contrib directory and provide the output. It would also help if you can provide a minimum working example (e.g., a small tex and gabc file) that demonstrates the problem.

[ebydj1]

Attached is system-setup.log

mwe.zip contains my best stab at an MWE, including the PDF output. I generated it with the command lualatex --shell-escape *.tex && lualatex --shell-escape *.tex and viewed it with evince if that matters. I want the horizontal episema to be above the Do, not the La. Changing the (ixi) to either (ix) or (i) moves the episema where it should be (but it also doesn't represent the neume properly, of course).

[henryso]

Thank you, that MWE proved very helpful.

My preliminary analysis is that the problem comes when setting #7 of \GreSyllable to 20 in order to adjust spacing for a flat. Fixing this will be slow for me since it's apparently in the TeX spacing code, so if some other developer with more familiarity in this area has time to look into it then great. Otherwise, I'll push slowly along.

[henryso]

I'm going to have to put up my hands. I've tried to figure this one out for a few days, and I can't tell what is causing that one change to mess up the position of the episema.

[rpspringuel]

I just took a look and I'm not sure that the problem is in the setting of #7 to 20. If I manually edit the gtex file to have 0 instead of 20 for that argument, the spacing between the syllables is adjusted appropriately (i.e. the flat is treated as if it was a normal neume), but the episema doesn't move out of it's wrong position.

What does fix the placement of the episema is getting rid of \GreNextCustos{11}{Flat} from #9 (where it appears at #3 to \GreGlyph). Something in that function must be altering one of the spaces which the later call of \GreHEpisema relies on in order to place the episema correctly. There's too many dependencies for me to trace the potential conflict immediately, but this kind of thing always has me looking for places where both functions might be using the same temp variable. Thus my first suspicion falls on the line \gre@dimen@temp@three=\wd\gre@box@temp@width in \GreNextCustos. That temporary dimension is not used explicitly in the rest of \GreNextCustos so this line is either legacy code that should be removed, or \gre@dimen@temp@three is being used to transfer the width of the custos box to some other macro later on which needs to know that distance. The trick, of course, is figuring out who's expecting that distance in that register.

The other thing to look for is to see where \GreHEpisema is making use of \gre@dimen@temp@three and figuring out what it is expecting there. If I'm on the right track, that is.

On a general note, given the way that TeX treats registers, it may be a good idea to do away with the use of our temp ones altogether, or at least restrict them to uses where they are not transferring values from one macro to another. That would increase the number of registers we use, but eTeX does give us 32767 of those (of each type) and I don't think we're anywhere near that limit at the moment (I think we're at less than 100 dimen and skip registers used). Reusing temp registers made more sense when considering TeX 255 limit.

[henryso]

Thanks. That led me down the right path. The problem is that \gre@alteration changes \gre@dimen@lastglyphwith which is not appropriate for a custos alteration.

I agree with your general note, but there are so many side effects that we depend on that this is difficult to do, at least for me. I will only patch the code to fix this issue at this time.