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.
Perhaps this has already happened. I just tried a font with lowercase-only SC names (a.sc). I copied text out of a PDF opened in Apple Preview, and in Adobe Reader. Then, I pasted the text in TextEdit. The PDF was generated in InDesign.
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.
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
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
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
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.
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.
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).
I wouldn’t say smcp is “wrong”, I’d say onlysmcp (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.