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

Possible superior letter name inconstancy? #105

Open
mathieureguer opened this issue Jun 16, 2022 · 5 comments
Open

Possible superior letter name inconstancy? #105

mathieureguer opened this issue Jun 16, 2022 · 5 comments

Comments

@mathieureguer
Copy link

Most superior letters are named with the mod suffix (amod, bmod, cmod, dmod, emod, fmod, gmod, kmod, mmod, omod, pmod, tmod, umod, vmod, zmod) while some are named with the supmod suffix (hsupmod, jsupmod, lsupmod, rsupmod, ssupmod, wsupmod, xsupmod, ysupmod).

I guess this is because the set is split across multiple code pages.
Maybe they should all use the same suffix? Something supmod to avoid ambiguity with other potential modifiers?
Maybe they should even use a dot syntax (a.supmod)?

I am happy to make a PR for this (or at least try to 😅) if you think it makes sense.

@LettError
Copy link
Owner

Let's see. It looks like these mod names have been like this from the beginning. This line is the conversion of SMALL to sup which may not always be correct? Does "small" have to mean "superior".


I don't remember what the motivation was to use sup for small. Maybe small would be better?

@LettError
Copy link
Owner

Suppose we want to make .mod suffixes, we would need a bunch.

  • .supmod or .smallmod
  • .hooksupmod
  • .hookturnedsupmod
  • .turnedsupmod
  • .supinvertedmod
    etc
    I find that a bit discouraging.

@mathieureguer
Copy link
Author

Thanks for looking into this. It is indeed a bit discouraging :)
On top of the amount of potential mod related suffixes, they seem have very different semantic values: a.supmod could maybe be an alternate from of a triggered by an OT feature but a.hooksupmod is likely not to be an alternate, I suppose. Like we have A.smcp but no A.acute.

You are right, it is probably better to leave this as it is. Thanks for the input!

@LettError
Copy link
Owner

Might still change sup to small which seems closer to the unicode. Any thoughts about that?

@mathieureguer
Copy link
Author

Maybe smallmod is better? (I have no qualification to answer this though 😁)
It's the sup keyword that lead me to use these unicode values for a.sups b.sups etc. But maybe that was a mistake and these unicode values should remain for phonetic related glyphs only and superiors should remain unicodeless? 🤷‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants