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

new way of specifying inter-syllable stretching #923

Open
eroux opened this issue Feb 15, 2016 · 8 comments
Open

new way of specifying inter-syllable stretching #923

eroux opened this issue Feb 15, 2016 · 8 comments
Milestone

Comments

@eroux
Copy link
Contributor

eroux commented Feb 15, 2016

Currently we have tons of different values with different stretchings, combined in many different ways, compared in many different ways, etc. and the final output has a stretching which can more or less not be predicted, at least by the end user. The idea here would be to just use dimen for all these values, but introduce their stretching counterparts, specified as skips with a main value of 0. The different algorithm would just work with the non-stretching values, and, just after the final skip they compute, add the corresponding stretching value asked by the user. This would make things a bit more complex to set up, but way more predictable and coherent. What do you think?

@eroux eroux added this to the 5.0 milestone Feb 15, 2016
@henryso
Copy link
Contributor

henryso commented Feb 15, 2016

I don't quite understand the proposal. To me, it sounds no better than defining them as they are now (as skips) and casting to dimension when doing computations, but I'm sure I'm missing something.

@eroux
Copy link
Contributor Author

eroux commented Feb 15, 2016

That would be something like that yes, but it would improve coherence, for instance now we define a different stretching for spacearoundmaior and interwordspacetext... who knows which one will be used when? One of them certainly, maybe a combination of both, maybe sometimes one sometimes the other depending on the configuration... I don't even know myself...

@eroux
Copy link
Contributor Author

eroux commented Feb 15, 2016

(I'm talking about a case like *(;) here)

@henryso
Copy link
Contributor

henryso commented Feb 15, 2016

How would it be different if you define a dimension and a skip (with 0 base value) for those things? I think I'm beginning to get a feel for what you're trying to fix, but maybe a concrete example for something like *(;) showing how the old versus new systems interact would help show what you are proposing?

@eroux
Copy link
Contributor Author

eroux commented Feb 15, 2016

It would be the same kind of things I did for intersyllablespacestretchhyphen in https://github.com/gregorio-project/gregorio/pull/924/files yes.

In the example *(;), there are two kind of space, the one between the bars and the one between the text, we can specify them separately. But only one same rubber should be added before all the spacings, and after all the spacings. There are many advantages:

  • now you can really specify the rubber you want around bars, and you know it's really this one that will be used
  • applying it once before and once after makes the output really perfect, if you have different rubbers for text and notes, the alignment will be messed and all the calculations will be wrong if the line needs to be stretched

Right now I don't know how it works, I think it takes the rubber of spacearoundmaior before and the one from interwordspacetext after, but it depends on the configuration...

@henryso
Copy link
Contributor

henryso commented Feb 15, 2016

Ok, so to sum it up, you suggest we use multiple dimensions to build up a "base" and apply a single skip to it. Makes sense to me. Thanks.

@eroux
Copy link
Contributor Author

eroux commented Feb 15, 2016

Exactly yes

@rpspringuel
Copy link
Contributor

How many cases are there which warrant different stretches? My think-out-loud list has one for between syllables and one for between words, but doesn't differentiate between bars and notes. Should there be a differentiation between bars and notes? If so, is notes->bar the same as bar->notes? Also, bars usually come in singletons, so would bar->bar really be needed?

@henryso henryso modified the milestones: 5.0, 5.1.0 Apr 16, 2017
@rpspringuel rpspringuel modified the milestones: 5.1.0, 5.2.0 Mar 15, 2018
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