best way to represent optional notes?

[eroux]

The Antiphonale Monasticum Project would like to represent some optional notes, they're thinking about two solutions:

• extending the cavum system to many other glyphs (virga, pes, clivis, torculus and porrectus)
• using brackets before and after groups of optional notes, where the brackets have different heights and vertical placements according to the notes (algorithm currently unknown!)

Both solutions seem quite complex, especially the first one... What do you think would be best? Do you have other ideas?

[henryso]

If we use the cavum system and generate all the glyphs, it will overrun the BMP PUA. Alternately, we can do it with fusion. A large part of the difficulty in either case, is drawing the base glyphs.

Depending on the algorithm, the bracket solution could also be fairly complex, but the difficulty here is really the placement algorithm and drawing the brackets (metapost?).

As far as which is better, this is clearly a style decision, and given there's no precedent, I don't think we can really make an appropriate decision. Perhaps both should be implemented in the long term, and of course the project-selected solution in the short term.

[eroux]

For cavum glyphs, drawing all possible glyphs would indeed be a rather bad decicion... I was thinking about only drawing the cavum part and place it as signs, I think it could be plugged (not without work of course) into current architecture?

I agree that both solutions would be best in the long term. The Antiphonale Monasticum project is not really decided yet, but they seem to prefer the cavum option...

[henryso]

Placing the cavum on the note head doesn't sound too difficult. Placing it on the downward stroke of the porrectus will be somewhat more complex.

[eroux]

I admit I don't really see why: the sign placement already has so many options, I think it would be relatively easy, for instance, to draw a vertical episemus in the middle of the porrectus stroke? Wouldn't this be basically the same?

[henryso]

For the porrectus stroke, the complication is vertical positioning since it's not just below the pitch or something like that; it's probably best handled by creating one glyph per porrectus stroke (I think we have ten of them), and then some glue logic in the cases to select the right glyph depending on stroke/case.

[henryso]

One more thing to think about: there is an option to see the lines behind the "hole". Drawing a white glyph on top of a black one will not allow this to happen.

[eroux]

I was thinking of drawing cavums for all possible porrectus strokes indeed (but also for virga, etc.). Also, there wouldn't be an option not to hide the lines for these new cavums, indeed. Let's see how the brackets look like (I've asked for an example). I think they are square brackets, so they should be relatively easy to draw...

[henryso]

Would we abolish the old cavum technique in deference to this new technique? Or would we try to meld them together somehow?

[eroux]

That's a difficult question... I tend to see the two systems as quite different: the current simple one will be used most of the time and will have more options (like the possibility to see the line underneath or the different shapes for punctum cavum), while the new one would be quite rarely used, and have less options... Maybe there could be a global switch? (with new by default?) Does it sound much more difficult?

[henryso]

The simplest thing would be to introduce a new notification notation for it (perhaps r6 or X if r6 is too long). To make it swappable would be more complex, but maybe it's better for users (i.e., no need to edit gabc to switch)?

[eroux]

r6 is a good idea indeed. Here is how square brackets should look like:

So I think the algorithm to find the heights can be quite straightforward... About the way to input them in gabc, I don't really know... maybe with backslashes like \[f/gh\]?

Also, my contact tells me that the most needed cavum figures are pes, porrectus can wait, and torculus can be achieved with fusion, so maybe a first version could include an r6 working only for pes?

[rpspringuel]

I made a post yesterday that seems to have gotten lost. While it my be that the discussion has moved past this point now, I reproduce it below:

If we abandon the old technique, the option to have the lines show through would be lost. Before doing that it would be wise to determine if anyone is using that option.

Just spitballing here, but what about a system of paired fonts. Font 1, would contain all the glyphs in hollow form. Font 2 would contain the corresponding cavum fills. When solid notes are desired, the appropriate glyphs from both fonts are printed in black (or whatever the note color is). When cavum notes are desired with the lines showing through then only font 1 is printed. When cavum notes are desired with the lines blocked out, the font 1 is printed in black and font 2 in white (technically the background color). This, I think, would minimize the number of glyphs required to have a cavum option for each note shape available.

[eroux]

I like the idea of the paired fonts, it's certainly much simpler than using the signs system! About the option to see the line through, I'm quite sure noone uses it, especially with the new cavum shapes, with which it would look odd

[henryso]

With regard to the brackets, how about double square brackets, as in [[f/gh]]?

[eroux]

Looks good!

[henryso]

We should decide if we are going to continue to release all three varieties (currently six fonts, but with paired fonts, it'll be eighteen, as we'll need normal, hollow, and hole versions of each of the six).

[henryso]

Also, if we use paired fonts, which I think is a really, really good idea, then we can support this with just r (it'll be just one system). Also, it might be a good idea to have some fusion-like delimiter so a number of notes can be marked as hollow for things like the porrectus, like maybe &r[..], which would essentially be the same thing as putting r after every contained note (akin to fusion).

[eroux]

Well, I think gregorio and parmesan could actually be distributed in only one mode (not even dominican), we can keep the code to make the dominican version but just comment it...

And we could start the hollow font without distributing the dominican version, we'll see if users ask for it... Wdyt?

[henryso]

I'm in favor of distributing greciliae in all forms with gregorio (the package) and have (TDS-layout) font packs for gregorio, gregorio-op, parmesan, and parmesan-op (each with their hollow/hole sister fonts). Similarly, the build would build greciliae in all forms by default, but something like make gregorio-op would build the desired variety with its hollow/hole sister fonts.

However, if you don't like this, then I don't really have an objection to doing it your way.

[rpspringuel]

I like @henryso's idea.

[eroux]

Good idea yes

[henryso]

Do we need to support partially-optional multi-note glyphs? For example, a porrectus where the first note is optional and the second two are not.

[rpspringuel]

That's probably a question best answered by the project wanting the notes (my inclination is no, though).

Re-reading through the thread, I noticed that @henryso seems to think that three versions of each font are needed: normal, hollow, and holes. My original idea was that the normal "font" could be created on the fly by printing both the hollow and hole fonts in the same color. Is there some reason why that wouldn't work?

[eroux]

I don't think we need that

[henryso]

@rpspringuel I don't think "fusing" the hollow and the hole for the glyphs in the normal case is a good idea. It will make the PDFs bigger and will cause the same alignment issues that we get with fusion.

[rpspringuel]

Understood.

[henryso]

#1143 implements the cavum glyph portion of this issue; the bracket portion still needs to be implemented.

[henryso]

Before I forget, when using brackets, how do they change with respect to notes on a line as opposed to notes on a space? Do we just extend the bracket to the next open space below/above the low/high notes contained within? Or do we adjust the position within the space (akin to the vertical episema positioning)?

[eroux]

I think the first proposal is best, that will make something more uniform...

[henryso]

With #1175, this should be complete. I tried extending the bracket as I mentioned before, but I didn't like the result, so what I've put here is a little different. It's not perfect, but I'm not good at judging the result aesthetically. See gregorio-project/gregorio-test#251 for sample output.