-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
Let's see. It looks like these glyphNameFormatter/Lib/glyphNameFormatter/rangeProcessors/spacing_modifier_letters.py Line 23 in abb3cdb
I don't remember what the motivation was to use sup for small. Maybe small would be better?
|
Suppose we want to make
|
Thanks for looking into this. It is indeed a bit discouraging :) You are right, it is probably better to leave this as it is. Thanks for the input! |
Might still change |
Maybe smallmod is better? (I have no qualification to answer this though 😁) |
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 thesupmod
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.
The text was updated successfully, but these errors were encountered: