Hello,
I just noticed that lowercase letters are not included in smcp feature when smallcaps glyphs stick to uppercase letter naming convention (A.sc, B.sc).
Is it on purpose? Should I now change names of all smallcaps glyphs in all of my fonts?
Glyphs Version 1.3.24 (526)
In my GitHub repository, you can find a script Glyph Names > Make glyph names lowercase.
Personally, I would recommend lowercase glyph names for SC anyway, since there are some cases where you may want to differentiate, e.g. germandbls/Germandbls.
Yes, I did use this script. Thanks 
Maybe Iām slow, but I could never understand why people name smallcap glyphs A.sc, B.sc, etc.
The way the feature works is, if you want a full cap, you type A, B, C, etc. If you want a smallcap, you type a, b, c, etc.
Why then, would anybody write A.sc, B.sc, C.sc, etc.
Just doesnāt make any sense to me.
Americans us the small caps feature to set abbreviations (like NASA) in small caps. Unfortunately they should use āc2scā for thatā¦
Another way of thinking is that both caps and smallcaps are two possible varieties of uppercase letters. Personally, I never combine caps with smallcaps.
Not only Americans do that. It is also pretty common in most European typographic traditions. And they actually are using c2sc if they type caps and then apply the all-in-smallcaps option of InDesign.
I recommend using lowercase names because some letters exist only as lowercase (germandbls, napostrophe). Then again, for uppercase Germandbls, one may want a different .sc glyph.
I often use caps mixed with smallcaps. Also, I used to use the āa.scā naming convention but was convinced by Adobe to switch because of the PDF text reading issue where smallcaps would then have no differentiation from lower case, missing the point of the distinction. Perhaps what is needed is a smarter PDF software that reads the feature code and designates smallcaps as something else like underscore. This would help the textreader issue and allow search and replace of text to select the transformed text.
The proper sollution is to have both A.sc and a.sc. Use the first in the c2sc and the second in smcp.
Appleās Preview seems to do some guessing, the output seemed erratic:
ErstEr BuchstaBE Gross
ErstEr BuchstaBE klEin
lEtzEr BuchstaBE Gross
Adobe Reader, however, got it completely right:
Erster Buchstabe Gross
erster buchstabe klein
letzeR buchstabE groSS
Except for the germandbls at the end of the first line, which seems to have been lost through a built-in text conversion, this is exactly what I had entered in InDesign before I activated all-smallcaps.
Ah, not quite erratic: In Appleās Preview, the SC letter is reverse-engineered to the capitalization of its first appearance in the text stream.
Thanks!
Sorry to re-open this. But this is really annoying me way too much every single time I need to make smallcaps.
I do understand the whole thought process on why it is implemented the way it is. But honestly, I think it is just totally flawed and inconsequent. Moreover it is super easy to implement it the way many requested it before (as e.g. Tim Ahrens) without any drawback ā¦ and even while keeping the current way alive too.
I will first just show what currently works and what not. After that I will elaborate more on why I think it is flawed overall to favour lowercase (a.sc) instead of uppercase (A.sc) / Though technically, Iām actually just asking to include the later, not to exclude the former if some might want to stick to it nevertheless.
So currently the auto feature code function does this
1 -------------------------
smcp -> sub a by a.sc; // also a.smcp works
c2sc -> sub A by a.sc; // also a.smcp works
--------------------------
c2sc will also favour A.c2sc, if it exists within the file (which is great)
But it BREAKS here
2 ------------------------
smcp -> sub a by A.sc; // gets not generated // also A.smcp does not work
c2sc -> sub A by A.sc; // even A.smcp works!
--------------------------
This also breaks
3 ------------------------
smcp -> sub a by A.c2sc; // gets not generated
c2sc -> sub A by A.c2sc;
--------------------------
So I just ask if there is only one design for all small caps (smcp+c2sc) then please let the type designer/developer choose to either go with a.sc or A.sc (possibly also a.smcp or A.smcp) and if ā for whatever reason ā you want to differentiate them in design -> A.sc/A.smcp + A.c2sc will also just work fine. (instead of the current a.sc/a.smcp + a.c2sc/A.c2sc) You can then still type in any tyepsetting application an uppercase A + lowercase a and the smcp fature will replace the lowercase a with A.smcp. Itās the exact same experience.
Then there was one more comment on napostrophe only existing in lowercase. This is true, you should not miss that one, but naming it Napostrophe.sc will also do no harm. Plus in your own tutorial https://glyphsapp.com/tutorials/making-small-caps you create the smallcaps from the uppercase which will also lead to missing out the napostrophe. Such exceptions is after all something you need to check individually in the quality control. Moreover the other alternative to use the lowercase as a starting point to generate the smallcaps has the drawback that you might need to delete all the stilistic sets (or other variation) you only had for the lowercase, but not for the uppercase; and then you need to check if there where any stylistic sets for the uppercase you now missed.
So even if there is no agreement on why A.smcp might make more sense than a.smcp, please just in this case implement both. Or at least make option 3 work, as it does the exact same thing as in the working option 1, just in the other direction.
I really hope I will get this stupid little feature at least in Glyphs 3.
Reasoning in favour for A.sc [edited, thanks Tim]
Finally, some reasoning why it makes a little more sense to use A.sc / A.smcp instead of a.sc / a.smcp.
Mainly it makes more sense, because the underlying structure of a small capitals is the uppercase construction and not the lowercase construction! So if, as a typographer, you decide to use small caps, youād definitely expect any font to give you a smaller uppercase construction made to work with lowercase; but surely not a lowercase construction. And if there would be small caps supported by unicode and the typesetting software (so when you select the feature that it would actually swap the lowercase letters with real small caps unicodes) then maybe it would be slightly more complex to discuss. But I would still be much more inclined to use the inherent letter construction (uppercase) that is connected to the intended small cap typography. So possibly naming it A.smcp or A.small in opposed to just A (as c2sc should definitely not be added to unicode ever I think)
I guess, some will continue to argue again, that the raw text is still a lowercase letter when you apply the smcp feature and therefore that it would make more sense to name it a.sc ā this is just none-sense from my perspective. Because the raw unicode text will not change and stay as a lowercase character, no matter how you name your small caps inside Glyphs. You could name your small caps in Glyphs in any way you want with your own feature code and it would make no difference to the experience in Indesign and Co.
At last just a little personal rant. Please ignore.
It just really annoys me extremely to not only make those stupid unnecessary upper to lowercase conversions to use the automatic featureā¦ but then actually having to live with this ugly a.smcp thing that just hasnāt anything to do in construction with what is sitting inside this glyph. It just feels like making a broken implementation, like a bug Iām forced to include if I want to use the automatic feature. And if anyone wondersā¦ Yes I wrote to Georg probably 8 years ago already that Iām annoyed by it and just canāt get behind their thinking. Letās see if I still have to live with it for another 8 years before I write something like this again. haha.
Small caps look like small capitals but syntactically, they are lowercase.
Really, again? I thought, I made clear that I do understand that. Alright, I try to say it in other words to be more clear. Yes, it is syntactically a lowercase [edit: maybe not actually] ā which I argue isnāt important in this context. Moreover this is still signified by ā.smcpā and also the underlying text input, that isnāt affected by opentype. Moreover, if a typographer changes uppercase and lowercase all together to small caps (which is also frequently used) then it looses that syntactically aspect that seems so important to you. It then is all unicase with an uppercase construction. Same is when a text is set in ALL CAPS. According to your reasoning this shouldnāt even be possible in typesetting software. Which would be really far fetched.
Anyways, though I would advice against the āa.scā practice, Iām not even asking to remove the current implementation. I just ask to extend it it with the reasonable āA.scā approach.
So wrong!
Also: What relevance does semantics have for font production internals?
smcp feature is applied to lower case characters, if you copy the text you always get back lower case characters. Glyph names reflect this for consistency in PDF situations where the original text is lost and applications guess it based on glyph names.
c2sc feature does the opposite. If you think smcp feature is wrong you might want to avoid it (and I agree, it was a mistake to add such feature to OpenType, but for a different reason; case mapping rules can be complex and language-sensitive it shouldāt be left to individual fonts to implement them correctly, as they often donāt).
Which ones are they? Are they still relevant today?
I wouldnāt say smcp is āwrongā, Iād say only smcp (without c2sc), i.e. mixing capitals and small caps, is an āunusualā case. If you are a scientist writing papers then thatās probably the ānormalā case but I would say from a typographic point of view is is no more important than all-small-caps.