better defaults for ledger lines

[eroux]

The gabc (c4) Aa(klk) bb(kml) space() cc(lmk) dd(da) ee(ca) gives the following result:

which is obviously imperfect (unbalanced ledger lines). The ledger line could be automatically (optionally?) extended if it crosses a line

[henryso]

Any suggestions for the heuristic to use here? Extend the ledger lines to the ends of the glyph?

[eroux]

I think it could be that when the ledger line crosses a line, the note (after/before) the line should be taken into account too... what do you think?

[henryso]

Then I guess it's unclear to me what I should fix. Should all five figures be changed? If I read your rule strictly, then bb, cc, dd, and ee should be changed. Is that your intent?

[eroux]

hmm here only the first shouldn't change, all the others should, because the ledger line crosses a inter-note line from the glyph. I'm not quite sure about your aa, bb, etc. examples... what do you mean?

[henryso]

In the above gabc, you have figures for syllable text aa, bb, cc, dd, and ee. I was referring to that, but your answer made it clear that all except aa should be modified.

[henryso]

Trying to wrap my head around this, I think it will be complicated by the queue size adjustments.

[eroux]

indeed... well, for the high figures I think it's feasible, for the lower ones... that's difficult indeed... maybe an option on the TeX side such as LongClivisQueues that would be true by default and would be used when ambitus is > 1 ? (or maybe > 2)

[henryso]

This is a non-trivial change. The current manually-specified ledger line feature is texverb-based, making it difficult to inject post-processing. I am currently considering how best to implement everything (i.e., adding an additional way of specifying a ledger line versus refactoring the current method into something that can be used more commonly).

[henryso]

I haven't had much time to formulate my solution, and I may not have time for a while, so I've unassigned myself.

[henryso]

I gave this some thought, and I need some guidance / opinions.

Currently we have:

• [oll:] and [ull:] which draw ledger lines
• [hl:] and [ll:] which suggest that ledger lines exist on a given note

[oll:] / [ull:], when used in bracket form (i.e., { .. }), influence the value which [hl:] and [ll:] override.

Implementing the feature from this issue would mark a given note as having a forced ledger line on it, which is actually neither of the above constructs. It is some new construct that means "draw a ledger line over/under this note" and of course should the value which [hl:] and [ll:] override. And of course, there would need to be a way manually override it.

Whether we come up with some new syntax or overload some of the above, this introduces a fourth way of specifying something about ledger lines:

• [oll:] and [ull:] without brackets means to draw some arbitrary length ledger lines and does not affect the value which [hl:] and [ll:] override.
• [oll:] and [ull:] with brackets means to draw a ledger line from one note to another and does affect the value which [hl:] and [ll:] override.
• [hl:] and [ull:] indicate whether Gregorio should process a given note as having a ledger line, and overrides any automatic setting. However, this construct does not draw any ledger lines.
• the new syntax allows you to override a ledger line drawn (or omitted) automatically over/under a given note and would affect the value which [hl:] and [ll:] override.

So the first question is, am I understanding the problem correctly?

The second question, if the answer to the first is "yes", is what the new syntax should be. There are probably an infinite number of ways to do it, but here are three I came up with:

• If we overload one of the previous constructs, it should probably be [oll:] / [ull:] since those draw ledger lines, like [oll:0] / [oll:1] / [ull:0] / [ull:1] (which at first glance is unambiguous)
• Or, a new bracketed construct, like [onll:0] / [onll:1] / [unll:0] / [unll:1]
• Or, a letter based modifier, like t0 / t1 / T0 / T1 (though this eats the one of the two both-case letters we have left -- the other is u/U, though S, X, and Y are still available as capitals)

Overloading [oll:] and [ull:] has the disadvantage of adding a possible confusion to the construct. Adding a new syntax (bracketed or letter based) adds more confusion as to which construct to use.

What do you think?

[eroux]

The first option looks the best to me though I'm not strong-minded about it... I think the solution you're proposing is very generic and clean, thanks!

[henryso]

I think the only thing remaining here is the question of queue size on low notes. Do we still need to do that? If so, can someone describe what the C code should emit to allow the "LongClivisQueues" option to work?

[henryso]

Thoughts?

[eroux]

Hmm I admit I hesitate between closing and making the C code emit a ledger line on the first note of a clivis when the second note is below c... what do you think?

[henryso]

As I mentioned above, I am in favor of doing exactly that—which is what I think the algorithm currently does. It keeps the algorithm simpler and easier to predict/explain.

[eroux]

ok let's close it then