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

BOL Shifts interact with invisible clefs #683

Closed
rpspringuel opened this issue Dec 3, 2015 · 5 comments
Closed

BOL Shifts interact with invisible clefs #683

rpspringuel opened this issue Dec 3, 2015 · 5 comments
Milestone

Comments

@rpspringuel
Copy link
Contributor

I noticed this as I was preparing the revised summary, but when the automatic clefs are set to be invisible, the bolshift causes the text to stick out into the margin. This should not happen. There are two ways to implement this:

  1. The easy way: when \gresetclef{invisible} is called, it automatically calls \gresetbolshifts{disabled}. The problem is that what to do when \gresetclef{visible} is called later.
  2. The less easy way: Add a flag check to the bolshift calculation that checks to make sure clefs are visible before calculating the bolshift. If clefs are invisible, then bolshift is automatically 0.
@rpspringuel rpspringuel added this to the 4.0 milestone Dec 3, 2015
@henryso
Copy link
Contributor

henryso commented Dec 3, 2015

It sounds like the less easy way is the way to go.

@rpspringuel
Copy link
Contributor Author

I've run into a problem with fixing this. It appears that when there is no clef the first line of the score starts immediately while there is a small fixed space before the first element of the subsequent lines. You can see this in the new test I added on rpspringuel/gregoiro-test@e170fd9. I don't have time at the moment to track this bug down. Hopefully I should get to it tomorrow, but I may not have the time.

Should the tracking this down be complicated, or I simply don't have enough time to get to it soon, do we want to postpone the pushing 4.0 out the door until it gets fixed, or should we simply push fixing the bug off. As far as I can tell, this is the last outstanding issue which remains on 4.0. If we push this off, we could release 4.0 tomorrow.

@henryso
Copy link
Contributor

henryso commented Dec 5, 2015

I could go either way with this. I don't think this is used enough that it will bother a lot of people as long as it's fixed soon after, in 4.0.1.

@eroux
Copy link
Contributor

eroux commented Dec 6, 2015

I Agree with @henryso, 4.0.1 can be released soon after 4.0.0, this bug is small enough to be in the KNOWN BUGS category of 4.0.0 in the changelog... What do you think about adding this section?

@rpspringuel
Copy link
Contributor Author

I can add a section like that when prepping the 4.0 release.

Which I'll do on Tuesday (Immaculate Conception is the Patronal Feast of CUA, so no classes), unless there are objections.

This was referenced Dec 12, 2015
@henryso henryso closed this as completed Dec 14, 2015
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

3 participants