Neography issue: quilisma porrectus ancus

[jakubjelinek]

In Nocturnale Romanum 2002, p. 278*, I run into problem typesetting:
mun(h!iwjijih~)di(ih)
which is typeset IMHO wrongly as:

In NR02 it looks like:

I'd expect something close to a combination of h!iwjiji overlapped with jih~ over the ji, without the stem, so:

Unfortunately in this case I can't find any workaround, putting ! anywhere in between creates something wrong.

[henryso]

The salient neume in this case is a 6-note neume. At the minimum this is going to be a fused neume. Maybe we should come up with a way to create fused neumes generically. This requires some thought and perhaps some engineering.

[jakubjelinek]

Yeah. Do we have a neume for the iwjiji or is that already composed too? If yes, is it composed from the quilisma and jiji without stems? If we have ancus without stem (jih~) it could be fused with the portion of porrectus.

[henryso]

All 5-note shapes are fused. We don't have a stemless ancus, and even if we did, it'll take some headwork to come up with a sensible way to fuse these extended shapes.

Edit: while I did say that all 5-note shapes are fused, the only 5-note shape we support is the torculus resupinus flexus (with various shapes at the head and tail).

[henryso]

I'm still thinking about this, but here are my thoughts so far, in case someone wants to stop me from going in the wrong direction:

I'm thinking of the addition of something to gabc that would indicate a desired fusing of notes. For the sake of discussion, I'll use the backslash (\). So to get the figure above, you would specify something like mun(h!iw\jij\ih~)di(ih).

This would tell Gregorio (and inevitably GregorioTeX) that there should be a line (if appropriate) to connect the iw to the jij and the jij to the ih~. This would also cause the system to place the j after the "porrectus" stroke to the right rather than to the left of the shape since it would be fused to the next shape.

I'm not sure how complicated this kind of thing would be to implement.

[jakubjelinek]

Perhaps it can be useful in some cases, but for this particular case I don't see other way to render it, so just writing it as I wrote IMHO should be enough and the fused neume pattern matched for it.
With backslashes (it is similar to ! in nabc) the question is where to put them exactly, if e.g. in between iwjij and ih~ above, or in between iwji and jih~ (the desired case glyph is that it looks like iwjij (with the last note to the right instead of left) and jih~ (without stem), so the fused property is that the j acts as both part of previous and next neume together.

[henryso]

I think it's a question of implementation order. I think it makes sense to implement the manual system first, and once that works, we can detect extended sequences like yours and put the breaks in for sensible defaults.

As for where to put the \, it would be trial-and-error, similar to putting ! until you get the neume you want. Then once you get used to it, you'll put it in the same place.

[henryso]

As I work through the various cases, it seems to me that an automatic evaluation of arbitrary notes into a set of fusable portions will almost certainly break scores where people depended on the old (arbitrary but somewhat logical) algorithm for breaking notes into neumes. Would anyone object to me adding another gabc-header to control gregorio's behavior on a given file? Something like neume-fusion: manual;, the default which retains the current behavior and neume-fusion: auto;, which uses the new behavior. Or perhaps we feel strongly that it's "auto" and only "auto"?

[eroux]

I agree with your first option (both possible, with current being the default), I think it's the safest

[henryso]

As I work on this, I have come up with another proposal that I like better than a behavioral header. The behavioral header would cause gregorio to attempt to fuse anything that's seems fusable. However, fusion is really the exceptional case since normal glyphs have a much better appearance. So my suggestion I , rather than adding this header, we add something like @{cdefghij} to gabc to cause fusion of the note sequence within the braces. This way, it's explicit what's happening, and the state machine in gabc-glyph-determination.c remains as "simple" as it is today. This would not replace the manual fusion of the @ character between notes. Anyone have thoughts on this?

[henryso]

Syntax-wise, it seems @[cdefghij] works better for the lexer. It's actually also possible to start fusion with something like @! and end it once you hit something that cannot be fused, like a liquescent or a space, but that is less explicit than delimiting it on both sides (which of course has the disadvantage that you can have something that cannot be fused inside the brackets).

[eroux]

I think @[cdefghij] is good, quite easy to understand. Would you use the same concept (fusion) and same notation (@) for #692 ?

[henryso]

As far as I'm concerned, #687, #692, and this issue are all aspects of the same feature. For this issue, the focus beyond basic fusion is the auto-fusion. For #687, the focus is on adding the reverse oriscus and making it fusable. For #692, the focus is on tuning the spacing of ascending puncta inclinata.

As of now, barring technical reasons to change, the syntax will be:

• @ before a note indicates the note should be stemless: @fe would produce the stemless flexus.
• @ between notes indicates a point of manual fusion. The shape at the top of this issue would be h!iw@ji@j@ih~.
• @[ and ] will delimit a sequence of notes intended to be fused. Since this case is "new", I am still working out how to lex it properly.

The rules for fusion are as follows:

• Fusion is allowed as long as the note that precedes is neither auctus nor deminutus and the note that follows is not initio debilis.
• The final shape of a string of fused shapes may be a two-note pair or a porrectus-like set of three notes.
• All shapes prior to the final shape must either be a single-note shape or a "porrectus-like flexus" (a descending pair of notes which lead upwards to the next fused note).
• If an invalid string of notes is used, gregorio will interpret it as a non-fused note or—in the case of a @-f—as a syntax error.
• using the @[cdefghij] syntax would split the notes into fusable parts based on these rules.

Regarding the lexing of @[cdefghij]:

• Due to similarity of the tokens, allowing "texverb" and "alt" within the sequence (which I would like to do) may prove tricky
• I have to decide how to handle non-fusable components within brackets. My earlier thought that the state machine in gabc-glyph-determination.c may be kept simple may not be true if I need to use it to "parse-out" non-fusable glyphs.

[eroux]

I agree with everything. If you allow texverb and alt (which I'm quite sure will be chalenging, especially in TeX), I think you'll solve #707 too... But don't hesitate to give up if it's too difficult, the feature is already quite a big improvement without it!

[eroux]

Just a thought: #707 will be solved (worked around actually) by using g[ob:1;6mm]@hgh. Writing this makes me believe that alt and texverb are not very useful in the @[] syntax, as they'll be possible in the 1@2@3 syntax...

About the state machine, maybe you can just throw a fatal error if an anomaly is detected?

[henryso]

The complication in the state machine is not so much one of detecting anomalies as it is one of deciding to continue if "auto-fusion" is on. For example, if you detect a scandicus, and it's not liquescent, then you might not want to end the glyph there if "auto-fusion" is enabled. I'll figure it out.

[henryso]

Question: using @[ and ] as delimiters is lexically the same as using <fuse> and </fuse>. Any preferences of one over the other?

[eroux]

I tend to prefer @[], but opinions from actual users would be more relevant...

[henryso]

Above-lines text will not work with the current implementation because it ends the element, and fusion is only supported (at present) within an element. I am not going to change the implementation unless there is a serious need because this would make things a lot more complicated.

[henryso]

Please try out the feature in the develop branch.