Lowercase letter slots used to house Uppercase forms.
This is a question I have asked myself many times, I've never gone into it.
When you are designing a typeface conceived as all-uppercase, which would be the best way to handle the lowercase slots? I recall that in the early stages of digital typography it was not uncommon to find either fonts with duplicated uppercase letters in place of the lowercase ones, or with the lowercase glyph slots left blank.
Clearly the first solution is better from a technical viewpoint, but I was still wondering whether it would be good in technical terms, as it basically states that a form supposed to be lowercase is uppercase instead.
As an alternative, I have seen digital typefaces which use the lowercase slots to provide the most important alternatives for uppercase forms. This could be handy in a typeface like the one that I am designing, where I have more than a single alternative for some letters, and the more important could be mapped in the lowercase, but I am still unconvinced by this practice.
What do you think about the topic, both on a theoretic technical side and from your past personal experience?
Many thanks in advance for all the possible advice, it will be much appreciated.
Comments
-
Purists will balk, but real users are rarely purists :-) so what I would recommend is some variant of the UC. Most conventionally, smallcaps. But feel free to go hog-wild with it! That's what I tell my students in fact (since many end up doing a caps-only font due to limited time).2
-
I’ve implemented a “caps with small caps” format on several typefaces.
It’s an added value to users, in that, apart from mixed case usage, it gives them the equivalent of two matched optical sizes, which is useful for decorative and display work, which is what “monocule” typefaces are usually designed for. The old “titling” designation.
Phiz Shadow and Parity (a unicase design).
The scaled down upper case glyph is shown for comparison on the far right of each example.5 -
Some of my early all caps typefaces had some unicase variants in the lowercase slots such as e or a. But I've since regretted that and usually removed them in updates. If I want to provide unicase variants, I don't want them to appear to the user accidentally. Let's say there's a font that has a unicase a in the lowercase a slot and the rest of the alphabet is the same as the caps. The user might not know that the unicase a is there. They might have most of their text in all caps or with and all caps feature turned on. But in one line, they used lowercase and now they have one stray a that they may not notice until it's too late. And with sentence or title case, the user might get an ugly capitalized word but two forms in the same word like ANaCONDa. Even if you think the user should be more careful, consider web fonts. If the user wants the unicase form, should they title all their blog entries in lowercase, including proper nouns? If you include unicase variants as OpenType alternates, none of these problems will occur.5
-
The only all cap fonts I have made have been personal (so far) revivals. I used the lowercase slots for letter variations or when my source reference was missing characters and I supplied them editorially.
I appreciate the questions and replies to consider for the future.1 -
The best way to approach this question is to ask yourself how you want a string of mixed case text to appear when it is set in your font. Too often, people making fonts seem to assume that the process of setting type consists of choosing a typeface and then setting the text, as if we were still working with pre-digital text technologies. It is now the case that text most often precedes type, and setting type involves applying a font to existing character strings. So if you put variant forms in lowercase slots, be aware that those forms will be displayed for any mixed case text and you are requiring users to re-type or case convert the text in order to display it with the default letterforms.4
-
Nick Shinn said:I’ve implemented a “caps with small caps” format on several typefaces.
It’s an added value to users, in that, apart from mixed case usage, it gives them the equivalent of two matched optical sizes, which is useful for decorative and display work, which is what “monocule” typefaces are usually designed for. The old “titling” designation.
Phiz Shadow and Parity (a unicase design).
The scaled down upper case glyph is shown for comparison on the far right of each example.0 -
Ray Larabie said:Some of my early all caps typefaces had some unicase variants in the lowercase slots such as e or a. But I've since regretted that and usually removed them in updates. If I want to provide unicase variants, I don't want them to appear to the user accidentally. Let's say there's a font that has a unicase a in the lowercase a slot and the rest of the alphabet is the same as the caps. The user might not know that the unicase a is there. They might have most of their text in all caps or with and all caps feature turned on. But in one line, they used lowercase and now they have one stray a that they may not notice until it's too late. And with sentence or title case, the user might get an ugly capitalized word but two forms in the same word like ANaCONDa. Even if you think the user should be more careful, consider web fonts. If the user wants the unicase form, should they title all their blog entries in lowercase, including proper nouns? If you include unicase variants as OpenType alternates, none of these problems will occur.
But how about the lowercase slots? Would you leave them empty or have a (possibly automated?) duplication of the uppercase in the lc slots?0 -
John Hudson said:The best way to approach this question is to ask yourself how you want a string of mixed case text to appear when it is set in your font. Too often, people making fonts seem to assume that the process of setting type consists of choosing a typeface and then setting the text, as if we were still working with pre-digital text technologies. It is now the case that text most often precedes type, and setting type involves applying a font to existing character strings. So if you put variant forms in lowercase slots, be aware that those forms will be displayed for any mixed case text and you are requiring users to re-type or case convert the text in order to display it with the default letterforms.
So, assumed you agree in using just sets to provide letter variants, for an all-uppercase font do you think I should leave the lowercase slots empty?0 -
Hrant H. Papazian said:Purists will balk, but real users are rarely purists :-) so what I would recommend is some variant of the UC. Most conventionally, smallcaps. But feel free to go hog-wild with it! That's what I tell my students in fact (since many end up doing a caps-only font due to limited time).1
-
Your observation is very intelligent John, thank you. Ideally, people should not type mixed case, as it will be an all-caps typeface (actually, more than one).You're still assuming that people are typing in the text in the case that suits your font. Presume, instead, that the text already exists, and your font is just part of the formatting applied to that text. The text may be all uppercase, all lowercase, or mixed case.So, assumed you agree in using just sets to provide letter variants, for an all-uppercase font do you think I should leave the lowercase slots empty?I would duplicate the encoding for each glyph, so it maps to the uppercase and to the lowercase character. So, e.g. the /A/ glyph would be mapped to U+0041 and U+0061.
If you simply leave the lowercase characters unmapped, then if the font is applied to lowercase or mixed case text the users will see a lot of /.notdef/ glyphs.
6 -
do you think I should leave the lowercase slots empty?For a few years I've been double mapping all of my all-caps fonts. I leave the lowercase blank and add the lowercase Unicode value to the uppercase. The only downside I've found is that the MyFonts upload tool can't detect a lowercase and flags it as having an insufficient character set—unless they've recently fixed that issue. But otherwise it works. Some of my multiple-mapped fonts have been getting at least 100 downloads a day for a couple of years and I haven't heard of any problems so I'm pretty sure it's safe.
2 -
+1 to double mapping3
-
John Hudson said:It is now the case that text most often precedes type, and setting type involves applying a font to existing character strings.0
-
Here is a script written by Adam Twardoch to automate the process of double encoding, and a few more details about the topic:
https://forum.fontlab.com/fontlab-vi/all-caps-font-(automatically-generate-lowercase-from-uppercase)/msg43427/#msg43427
2 -
Of course this is far more true for a text face than for an all-caps one...Again, you are assuming that the font choice precedes the text creation. That only applies to one particular way of working with text. Fonts need to be able to handle e.g. use in style sheets, independent of the text to which they apply. Any font that requires a user to re-type a text or apply a case conversion to it before it display correctly isn't built for today's text environments and workflows.
5 -
@John Hudson The point is a font that's not expected to carry a lot of text is much more likely to be typed in than applied to an existing text. And it's generally not worth sacrificing the richness of your font for somebody who is blindly trying out different fonts for a text your font is not meant to carry.
You are (again) thinking as a text face designer, which is better than the the other way around, but best is to admit the existence of both worlds. Many designers working in display acquire and select a font they like for a specific reason, for example that it has two versions of caps; they then either apply it to a very short text they know will accommodate that reasoning (or can easily be modified to) or they simply type in it.
Standardization can stifle culture too.1 -
Thanks much everyone, this is very useful. :-)0
-
Another question: so far I have labeled the various letter variants as .021, .021 etc. because there are variants by category and then more than a variant for each category.
This is because I will have a limited number of Stylistic Sets, not coinciding univocally with the variants (i.e. a single letter variant could fit more than a Stylistic Set).
Would it be better to have them named as Character Variants, i.e. 'cv01' – 'cv99', or is the Character Variant feature geared towards the solutions of lexical contexts?0 -
Hrant H. Papazian said:Standardization can stifle culture too.
So surely not the average user (or even designer) applying the font to a pre-existing text to see how it fits. In my case, the choice would pre-date the design work.1 -
What you seem to be describing is a model in which you can provide easy access to some variant uppercase letterforms by mapping them to the lowercase characters. I would say that is a very 1980s approach, similar to 'Expert Set' Type 1 fonts, and based on a fundamental misunderstanding of the relationship of keyboard input, character storage, and glyph display. Should you not do it? That’s for you to decide, but be clear in your mind that any variant letterform access that requires a user to encode WaR aND PEaCE or PRide ANd PReJUdiCe in order to obtain the desired glyph display is an outdated hack.
The other thing to bear in mind is that this hack only works for one variant form per letter, so if you have more than one variant glyph you’re still going to need some other character-to-glyph access mechanism such as OpenType was designed to provide.2 -
Those of you talking about "double mapping," is there a functional benefit to doing it that way instead of just duplicating the UC glyphs into the lc spots?
In Glyphs, I can place the UCs as components into the lc spots, and then add them to the same kerning classes to ensure results are identical. (This avoids the "insufficient character set" problem Ray mentioned.) Is there a reason NOT to do it that way?0 -
Duplicating glyphs is not a good idea as it just increases file size and makes kerning more work (keeping classes in sync).
In Glyphs, you just delete the lowercase and run Glyph > Update Glyph Info that will automatically assign the (missing) lowercase codes to the uppercase.7 -
John Hudson said:What you seem to be describing is a model in which you can provide easy access to some variant uppercase letterforms by mapping them to the lowercase characters. I would say that is a very 1980s approach, similar to 'Expert Set' Type 1 fonts, and based on a fundamental misunderstanding of the relationship of keyboard input, character storage, and glyph display. Should you not do it? That’s for you to decide, but be clear in your mind that any variant letterform access that requires a user to encode WaR aND PEaCE or PRide ANd PReJUdiCe in order to obtain the desired glyph display is an outdated hack.
My more important question now is whether it would be OK to have the alternatives as as Character Variants (instead of generic numeric names, as they will not coincide with Styilistic Sets), i.e. 'cv01' – 'cv99', and I seem to get it can be.0 -
Georg Seifert said:Duplicating glyphs is not a good idea as it just increases file size and makes kerning more work (keeping classes in sync).
In Glyphs, you just delete the lowercase and run Glyph > Update Glyph Info that will automatically assign the (missing) lowercase codes to the uppercase.1 -
@Austin StahlIs there a reason NOT to do it that way?No, I think it's just personal preference. But with heavily detailed fonts the reduction in file size is worth it and sometimes necessary.
1 -
John Hudson said:based on a fundamental misunderstanding of the relationship of keyboard input, character storage, and glyph display.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 800 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports