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

Fine space tuning #736

Closed
eroux opened this issue Dec 29, 2015 · 35 comments
Closed

Fine space tuning #736

eroux opened this issue Dec 29, 2015 · 35 comments

Comments

@eroux
Copy link
Contributor

eroux commented Dec 29, 2015

For the new Antiphonale Monasticum project, some differences in the manuscripts are noted with differences in spacing, for instance f/hoi will be the transcription for a certain neume, while another will be noted by replacing the space with half a space.

The original request was to have the possibility of negative spaces, but I see several:

  1. find a new symbol to denote half a space in gabc, maybe /0
  2. ask people to tune the different spacings in a custom spacing file, using for instance / as half a space, // as a normal space, etc.
  3. use -/, -// and - for negative spaces, in this case f/-/hoi would be ok with -/ tuned to be half a space
  4. completely generic solution: /{1/2} is half a space, /{-3/2} is a negative space of width 3/2 of a normal space, /{2} is a space of twice the normal space, etc.

What do you think?

Edit: I've made a few edits since the initial post...

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

If the user will need both the current spacing and the negative spacing in the same score, then 1 will not work. The concept of 2 is fine, but using - (alone) here would conflict with initio debilis, so we'd need another notation. The concept of 3 is neat as well, but the notation conflicts with { and } used for polyphony (who still uses polyphony?). Perhaps use /[...] here? Also, shouldn't we be consistent with 1/2 and -3/2 or 1:2 and -3:2?

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

Sorry, I've made a few edits so your comment is off by one index, but I'll answer:

  • for 2, I don't have any use case where both half space and negative space are used, but it may come in the future
  • for 3, I think it would be easy enough not to confuse -/ with an initio debilis in the lexer...?
  • for 4, sorry, I mixed / and : but I fixed it. You're right, /[...] is better

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

Using your new numbers, for 3, -/ is not a problem, but you suggest using -/, -//, and -. The - alone would conflict with initio debilis.

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

Oh, sorry, markdown ate my space, what I meant was -[space]

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

As the half space is significant here in terms of gregorian chant, I think it would be good to add /0, but maybe adding point 4 would be good too, for edge cases... So a combination of 1 and 4 is what I think would be best...

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

I agree with doing both 1 and 4.

@rpspringuel
Copy link
Contributor

I agree with that proposal.

@eschwab
Copy link
Contributor

eschwab commented Dec 29, 2015

This would be very useful. The proposal seems good from a user's perspective.

@rpspringuel
Copy link
Contributor

It occurred to me that at least for the purposes of documentation, it would be useful to establish equivalencies between the "shortcut" notation, and the explicit notation. Something like:

  • /0 = /[1/2]
  • / = /[1]
  • // = /[2]
  • ' ' =/[3/2]

or whatever the actual numbers are.

@henryso henryso self-assigned this Dec 29, 2015
@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

Well, they are not really equivalent:

  • /0 will point to halfspace
  • / to interelementspace
  • // to largerspace

while

  • /[1/2] will be 0.5*interelementspace
  • /[2] will be 2*interelementspace

which can be different (and are different in gsp-default), and I think we can keep things this way, the spaces have different meanings, and can vary according to taste. I don't think the fraction spaces should be used frequently (if at all) except for edge cases...

By the way, what about the possibility to have floats? like /[1.6] (instead of /[16/10])

@rpspringuel
Copy link
Contributor

I understand that, but what if (arbitrary example with arbitrary numbers) someone decides they want 3/2 of largerspace? Will //[3/2] be valid syntax? If not, then it would be useful in the documentation to explicate that // produces the same amount of space as /[2] so that the user in this situation could then realize that the correct syntax for the amount of space they want is /[3].

Obviously these equivalencies would only apply to gsp-default. If the user custom tunes halfspace, interelementspace, largerspace, or glyphspace then the equivalencies would no longer apply (and the documentation could say as much).

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

I didn't think about //[3/2], but I think it should be parsed as / then /[3/2]... What do you think?

In gsp-default, the ratio between interelementspace and largerspace is around 1.579, it's a bit odd, but yes, we can document the equivalences of the default values in the documentation.

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

Actually / is interglyphspace, but that doesn't change anything else you are saying.

See question below.

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

I'd rather take floats than fractions in the /[...] notation.

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

Ok, TeX's primitive multiply also takes float, so it should be fairly simple

@rpspringuel
Copy link
Contributor

I didn't think about //[3/2], but I think it should be parsed as / then /[3/2]... What do you think?

I agree with this interpretation.

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

What is interglyphspace? It seems to be the same as interelementspace with a smaller "plus".

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

Gregorio used to have a clear distinction between glyphs and elements, and interglyphspace was certainly used between glyphs of the same element, but now this distinction is quite blur, so I don't think it's used anymore, except in very rare cases... but I admit I cannot remember well...

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

It seems we have a zerowidthspace but it doesn't seem like \GreEndOfGlyph{3}{...} is using it. Should it be?

@eroux
Copy link
Contributor Author

eroux commented Dec 29, 2015

if gabc ! converts to \GreEndOfGlyph{3}{...} then I think so yes

@henryso
Copy link
Contributor

henryso commented Dec 29, 2015

For custom spaces, should stretch ("plus") and shrink ("minus") be scaled by the provided factor, or just the width?

henryso added a commit to henryso/gregorio that referenced this issue Dec 30, 2015
henryso added a commit to henryso/gregorio-test that referenced this issue Dec 30, 2015
henryso added a commit to henryso/gregorio-test that referenced this issue Dec 30, 2015
@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

In the pull request, I only scaled the width part of the glue and not the stretch or shrink. Let me know if I should do something different.

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

Thanks a lot! The space looks perfect! I can't decide about scaling the stretch or shrink... so if there is no objection, we can merge like this.

I believe the half space is really useful, but it's kind of difficult to explain, let me try (as it might lead in changes in the code):

initially there was a strong differenciation between glyphs and elements, one element being several glyphs separated by some small space. The problem is that it never has been possible to differentiate them in gabc. Let's take the example of the tests in your PR:

  • fghi is a salicus and a punctum, two glyphs in the same element, separated by interglyphspace
  • fg!hi are two podatus, in the same element but stuck together
  • fg\0hi are two podatus in the same element, separated by halfspace

but it's not possible to have two podatus in the same element separated by interglyphspace, and having the third case (two podatus in the same element, separated by a space) was previously impossible. I never noticed that...

So maybe \0 should in fact be the separator for glyphs in the same element, and output an interglyphspace (which would have the width halfspace currently have)... I'm not really sure as it would change the spacing in many scores, but the old spacing could be done again with fgh/ifor instance... I'm not really sure about that, What do you think?

@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

If I'm understanding this, I see two ways of going about it:

  1. We change interglyphspace to be the same as halfspace and put instructions in UPGRADE.md that the user can use / for an ad-hoc change or redefine interglyphspace back to the old value for the old behavior.
  2. We don't change anything and advise the user to redefine interglyphspace to the size of halfspace should they desire the alternate behavior.

Which way depends on whether the halfspace-sized interglyphspace is more "correct" in a chant score (if so we would choose number 1). I don't know which is more correct, so I will defer to you. If you feel the halfspace-sized interglyphspace is more "correct", I will make the change in #738.

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

I think option 1 is the good one, but I'm not 100% sure (I've asked a contact about this). I was thinking about renaming halfspace into interglyphspace but it's probably too hard, so here is another proposal:

  • change interglyphspace to be the same as halfspace (and the rest of your first solution)
  • deprecate halfspace and use interglyphspace for /0 in next release

What do you think?

@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

It seems funny to release an immediately deprecated feature, so if you want to do this, then I would simply change interglyphspace to the size of halfspace, remove halfspace, and have /0 use interglyphspace. This would require a note in UPGRADE.md should the user prefer the old behavior of interglyphspace. What do you think?

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

If there's no disagreement, I think it's a good solution yes

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

Also, maybe /0 could be at glyph level (with glyphs before and after being inside the same element) in the code, but that's not really top priority...

@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

The code makes some assumptions about spaces that are at the glyph level, so it might be a little tricky, but I'll try.

@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

If /0 is at the glyph level, this implies that it's not breakable (i.e., there would be no need for !/0 as the ! is implied). I don't see a problem with this, given your definition, but I just wanted to be sure before I make such a change.

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

I think it's fine...

henryso added a commit to henryso/gregorio that referenced this issue Dec 30, 2015
@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

I've made the requested change. Please review. Obviously, a number of test expectations change because of this.

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

Hmm sorry, I didn't realize so many spaces would be impacted... I think we can keep /0 at glyph level but differenciate halfspace and interglyphspace, otherwise the changes in previous scores will be too big... Sorry!

henryso added a commit to henryso/gregorio that referenced this issue Dec 30, 2015
@henryso
Copy link
Contributor

henryso commented Dec 30, 2015

I've made the requested change. Please review. The only test expectations that change now are due to making "/0" a glyph-level space.

@eroux
Copy link
Contributor Author

eroux commented Dec 30, 2015

Thanks a lot! ok for me

@henryso henryso removed the question label Dec 30, 2015
@eroux eroux closed this as completed Dec 30, 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

4 participants