rpspringuel
commented
5 years ago It sounds like expected behavior. Your new spacing file should have its own \greconffactor. This variable indicates what size staff the gsp file assumes so that the distances loaded by the file can be scaled appropriately if a different staff size is currently in effect. This prevents odd order effects in changing staff size and loading custom spaces.
Example: I have a project for which I expect to print staves at 20. In designing a custom gsp file for the project I set \greconffactor to 20 so that I can enter custom spaces directly based on page measurements without any math for scaling. Later on, I create another project in which I want to include a scaled down version of one of the scores in the first project, say at size 10 (half scale). Because of \greconffactor, I can load my custom gsp file either before or after switching to size 10, and I never have to switch to size 20 (if that isn’t used elsewhere in the new project).
Sent with GitHawk
asbloomf
This was happening on 5.2.1
If \greconffactor is different than what the staff size is set to, it seems to cause a problem when loading the new space file. It multiplies by the staff size but divides by \greconffactor. Anyway I think that is what was going on. So if you have the staff size set to something big like 23 and the regular \greconffactor of 17, when you load the new spacing, \gre@stafflinefactor gets set to 31 (23 * 23 / 17). It's easy to workaround so it's not a big deal. I'm not sure if anything else is affected, but the line thickness was certainly quite noticeable.