Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completing glyph handling #898

Closed
eroux opened this issue Feb 10, 2016 · 13 comments
Closed

Completing glyph handling #898

eroux opened this issue Feb 10, 2016 · 13 comments
Assignees
Milestone

Comments

@eroux
Copy link
Contributor

eroux commented Feb 10, 2016

Looking at Nocturnale Romanum:

nr

there are a few glyphs that Gregorio doesn't handle and that seem to be used in Antiphonale Monasticum project. The main one is "virga strata", but it would be good to handle (in the form where the two pitches are not the same, but keeping both notes in the same element when they have the same pitch), and "pes stratus" too. This also raises the question of how to apply the changes made in #744 for combined glyphs. For instance, the pes stratus would have different forms according to the following note, how should the glyphs be named?

This could also be the occasion to apply #744 completely and revert the direction of the oriscus for the FlexusOriscusScapus glyph, as these are just plainly wrong in the Nocturnale Romanum, and we copied them. So should we add some .nr variants for the current ones, and fix the normal form?

Note also that NR has a "salicus quassus" figure which looks just plainly wrong, I don't think it should be added to Gregorio...

@henryso
Copy link
Contributor

henryso commented Feb 10, 2016

The following are currently possible:

image

@eroux
Copy link
Contributor Author

eroux commented Feb 10, 2016

Thanks! this leaves the following remarks:

  • the only problem for virga strata seems to be when the ambitus is one... very strange... maybe we should open a bug issue against 4.1 for this?
  • the pes stratus is perfect this way, I didn't find any mean to make the second oriscus in the opposite direction, is there any?
  • there should be a way to turn the oriscus of gO in the other direction (the glyphs are already drawn IIRC)
  • inverting the oriscus of gOe (with variants)

@henryso
Copy link
Contributor

henryso commented Feb 10, 2016

  • What is the problem with virga strata at ambitus one?
  • There is currently no way to change the direction of the second oriscus; the current rules are that oriscus can only fuse upwards (f@ho@j) or downwards (i@ho@f). The "exception" here is that a "leading" stemmed oriscus (one that starts a figure) can fuse in either direction. This, of course, can be changed.
  • Inversion of the oriscus in those two figures sounds doable.

@eroux
Copy link
Contributor Author

eroux commented Feb 10, 2016

Forget about the bug, I was trying gho instead of ghO! Let's not hurry about the fusion change, I don't think it's really a priority, but allowing an inversion of gO and gOe would be a good feature for 5.0!

@eroux eroux removed the question label Feb 10, 2016
@henryso
Copy link
Contributor

henryso commented Feb 12, 2016

Do you have an example of where the inverted gO and gOe might be used?

@eroux
Copy link
Contributor Author

eroux commented Feb 12, 2016

not at all, all I know is that Solesmes asked me to revert gOe in their font because they follow the rule that the oriscus should be in the direction of the following note. I think it's just the same for gO

@henryso
Copy link
Contributor

henryso commented Feb 12, 2016

Should we follow that sort of thing by default? It certainly is more consistent.

@henryso
Copy link
Contributor

henryso commented Feb 12, 2016

Thinking about this a little bit, if we are going to change the gabc syntax to handle this, it would be better to do it in 4.1 since the oriscus logic has already changed in this version.

@eroux
Copy link
Contributor Author

eroux commented Feb 12, 2016

Applying the rule by default would be best indeed, in 4.1 would be perfect!

@henryso
Copy link
Contributor

henryso commented Feb 12, 2016

Ok, the hard question. When using the new oriscus orientation rules, < and > change the shape of the oriscus to a specific shape. However, it currently only affects the oriscus that is not connected to anything (in other words there is no way to have goe (lowercase o) with an up-down-up oriscus as that figure always leads downward. In this case < and > do not really indicate liquescence. Maybe it would be better to use 0 and 1 like we do for _ and ' for this. This means that if you want goe with an up-down-up oriscus, you would issue go1e.

@henryso
Copy link
Contributor

henryso commented Feb 12, 2016

By the way, I will try to get this done in 4.1, but I cannot promise it will be ready for rc1.

@henryso
Copy link
Contributor

henryso commented Feb 13, 2016

There are a number of missing glyphs to make this work and it has a strong potential to destabilize the code, so I'm inclined to leave it for 5.0. Part of the problem is that in some shapes, the oriscus direction is implied (so flexus oriscus is an oriscus descendens and pes quassus is an oriscus ascendens). This becomes very confusing when working out the cases. I recommend changing the names of the glyphs in order to make the oriscus direction explicit (i.e., flexus ascendens oriscus and flexus descendens oriscus). This, too, is a very risky step to take before we stabilize for TeX Live.

However, if you are OK with using 0 and 1 (as opposed to < and > using the new rule set) to force oriscus direction, I recommend we make that change in 4.1 so we don't introduce a new rule set only to introduce a new one a release later. Part of the reason to use something other than the liquescent modifiers for this is that liquescentia cut the glyphs, and we don't want that for gOe with a reversed gO.

What do you think?

@eroux
Copy link
Contributor Author

eroux commented Feb 13, 2016

I agree with everything, let's make the pure 0 and 1 change for 4.1 and let's wait for 5.0 to do the big changes. I think the gO case would be quite easy to handle with current code though? If so, maybe we could handle it in 4.1 (the glyphs are already in the font)?

@henryso henryso self-assigned this Mar 11, 2016
henryso added a commit to henryso/gregorio that referenced this issue Mar 13, 2016
henryso added a commit to henryso/gregorio that referenced this issue Mar 13, 2016
@henryso henryso modified the milestones: 4.2, 5.0 Mar 13, 2016
henryso added a commit to henryso/gregorio that referenced this issue Mar 14, 2016
henryso added a commit to henryso/gregorio that referenced this issue Mar 14, 2016
Added change log and upgrade entries to describe the orientation change.
Part of the implementation for gregorio-project#898 and gregorio-project#972.
@henryso henryso closed this as completed Mar 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants