-
Notifications
You must be signed in to change notification settings - Fork 43
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
Name font calibration distances #1526
Name font calibration distances #1526
Conversation
There were several "magic distances" still in the code. All of these distances are related to calibrating things to the fonts and so should not be user editable. However, having those numbers scattered through the codebase is harder to maintain (if you change one, you have to figure out which of the others also needs to change, by how much, and where they all are), so based on relationships between the numbers, I've reduced them to 6 named dimensions which are then used as needed in the various calculations.
One question on this remains: Right now we have |
It should be noted that currently in the code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to trust that your math is right. If the tests pass, then it probably is, or at least is close enough.
What about the issue with |
If it works, then go for it. I know there's some weirdness in spaces above and below the staff. |
The additional distance added between the score and the lyrics for lower than "normal" notes (as defined by `noteadditionalspacelinestextthreshold`) is now calculated automatically based on the exact distance below the "normal" position that the low notes have been placed. This mirrors what was already being done for notes higher than the "normal" position above the staff. The distance is marked as obsolete (skipping deprecated status) because it is no longer functional and we normally require deprecated code to be functional.
I've pushed the changes to eliminate |
Is there a way to set things up so that the spacing of those low notes are not changed? I suspect that some people (like me, for instance) will have scores already typeset and want to retain the old spacing, even if it's wonky. |
I could probably toggle the behavior with a conditional. Let me look at that after Mass. Sent with GitHawk |
By making use of the `\ifgre@allowdeprecated` conditional, we can allow the user to preserve the old spacing behavior regarding low notes.
Okay, I think I've got that worked out. Please look it over and let me know if you see any problems. |
Note that the associated test PR has changed due to some of the monkey business I did to extract the old test results for the backwards compatibility tests. That process was much harder than it really should have been. |
I don't think this is deprecation. I see this as an alternative that doesn't really go away, like the old vs new style oriscus orientation algorithms. |
Hmmm... That’s going to require a slightly different approach. Now, currently the additional space added for high notes is calculated while the additional space for low notes is manually set. If we’re going to preserve the ability to manually set the space for low notes, should we add the ability to do so for high notes? If so, should the user be able to independently decide whether to use the manual or automatic setting for low and high notes (requiring two switches with two positions each), or does it suffice to have there be a single manual vs automatic setting? Sent with GitHawk |
I think that there should be a "legacy" switch only for the lower notes as the upper notes have been working as they've been working thus far and no one has been asking for a way to make the high note spacing work like the low note spacing. We'd only need this for the people who have things typeset and laid out and for whom such a change would cause a big mess and a need to re-layout the work. |
Okay. I can work on that tomorrow. Sent with GitHawk |
Converted. I'll be offline on Ash Wednesday so if you spot anything I'll deal with it on Thursday. |
Looks OK to me. |
There were several "magic distances" still in the code. All of these distances are related to calibrating things to the fonts and so should not be user editable. However, having those numbers scattered through the codebase is harder to maintain (if you change one, you have to figure out which of the others also needs to change, by how much, and where they all are), so based on relationships between the numbers, I've reduced them to 6 named dimensions which are then used as needed in the various calculations.
Fixes #1521.