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

force vertical episemus placement top or below #385

Closed
eroux opened this issue May 8, 2015 · 12 comments
Closed

force vertical episemus placement top or below #385

eroux opened this issue May 8, 2015 · 12 comments

Comments

@eroux
Copy link
Contributor

eroux commented May 8, 2015

It would be useful to have '0 and '1 forcing placement of vertical episemus on top or below the corresponding note (reported on the ancient bugtracker).

@henryso
Copy link
Contributor

henryso commented May 11, 2015

Now that we have the variant system in place, and with the circumflexus as an alternate glyph for the vertical episemus, should we have/use an inverted vertical episemus when it appears above? An inverted vertical episemus using the default glyph would look the same, but possibly the alternate may need two forms? A silly idea?

@henryso
Copy link
Contributor

henryso commented May 14, 2015

Any thoughts on this?

@eroux
Copy link
Contributor Author

eroux commented May 14, 2015

Oh sorry... I'm not sure the circumflexus would look nice reverted, what do you think? But maybe the normal vertical episemus could have two forms yes, not sure it would be noticeable without magnifying glass, but it would look nicer...

@rpspringuel
Copy link
Contributor

If the circumflexus is supposed to flip when it appears above vs. below, then I'd say go for it. It placement doesn't cause the circumflexus to flip, then I'd wait until someone requests that feature.

@henryso
Copy link
Contributor

henryso commented May 14, 2015

Ok, I will just implement this using the same glyph upper and lower until there is need to do otherwise.

@eroux
Copy link
Contributor Author

eroux commented May 14, 2015

For this kind of hesitations, I admit I never know what to do: for instance if we decide to change this in the future version, this means that the gtex output will slightly change, and that we thus have to go for a new major version... So sometimes I doubt modifcation of the gtex output is a right criteria... what do you think?

@henryso
Copy link
Contributor

henryso commented May 14, 2015

I originally thought major version is one for which there are backwards incompatible changes to the gabc syntax or to user commands in TeX. However, we interpreted this to mean that if the gabc files need to be recompiled, then it would be a major version. I can see the sense in both, and frankly, it doesn't matter too much to me either way, so I don't see a problem bumping up the major version if gabc files need to be recompiled or, on the on the opposite side, with requiring a recompile at the minor version number level.

@rpspringuel
Copy link
Contributor

While I understood major version number as @eroux did, I think @henryso has a point. With autocompiling, changes to the gtex don't necessarily need to be a major version change because they don't affect the user. Perhaps, though, we should wait a while to let autocompiling take hold in the user base before doing that.

@eschwab
Copy link
Contributor

eschwab commented May 14, 2015

A thought: If the new feature requires recompiling the gabc to use it, but no change if the user does not want the new feature, then no major version change.

If the new feature requires recompiling regardless if the user wants to use it or not, then major version change.

@henryso
Copy link
Contributor

henryso commented May 14, 2015

@eroux If we follow @eschwab's guideline, then adding the inverted vertical episema (if ever) would not be a major release.

@henryso
Copy link
Contributor

henryso commented May 17, 2015

Does this mean that you can have a vertical episema both above and below the same note at the same time? It'll be somewhat more complicated if that's allowed, so I'll hold off on this until a decision is made.

@eroux
Copy link
Contributor Author

eroux commented May 17, 2015

@henryso I don't think having both is necessary, no...

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