Lowercase letter slots used to house Uppercase forms.

Claudio Piccinini

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.

Hrant Հրանդ Փափազեան Papazian

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).

Nick Shinn

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.

Ray Larabie

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.

Rocky Mjos

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.

John Hudson

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.

Claudio Piccinini

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.

That is clever Nick – thanks!, but it’s not my case: my typeface will have a single caps-height.

Claudio Piccinini

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.

Yes, many of these things were what I was thinking about when approaching this *as a problem*. I don’t definitely want people to mix letters "by mere chance", so I guess using sets will be the best way.
But how about the lowercase slots? Would you leave them empty or have a (possibly automated?) duplication of the uppercase in the lc slots?

Claudio Piccinini

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.

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).
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?

Claudio Piccinini

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).

Thanks. That would be doable in general, for an unconventional alphabet maybe mixing forms. But as I said, my current work is a historically based collection of uppercase forms.

John Hudson

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.

Ray Larabie

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.

Dave Crossland

+1 to double mapping

Hrant Հրանդ Փափազեան Papazian

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.

Of course this is far more true for a text face than for an all-caps one...

Igor Petrovic

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

John Hudson

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.

Hrant Հրանդ Փափազեան Papazian

@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.

Claudio Piccinini

Thanks much everyone, this is very useful. :-)

Claudio Piccinini

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?

Claudio Piccinini

Hrant H. Papazian said:

Standardization can stifle culture too.

And not only culture… I agree. I see John’s point is about current usage, but in general this specific work (which strictly speaking is not even a typeface) would be for *very* conscious user looking to evoke a specific atmosphere thrugh the letters.
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.

John Hudson

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.

Austin Stahl

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?

Georg Seifert

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.

Claudio Piccinini

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.

I don’t understand. That was an option that I mentioned in my opening post simply because I did not want to leave the lowercase slots blank, but now – after all the discussion and all of your input – I see the double unicode mapping is surely the best option as I did not want to treat uppercase forms as lowercase.

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.

Claudio Piccinini

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.

For FontLab users to avoid assigning the double Unicode values manually the script provided by Adam works perfectly.

Ray Larabie

@Austin Stahl

Is 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.

Hrant Հրանդ Փափազեան Papazian

John Hudson said:

based on a fundamental misunderstanding of the relationship of keyboard input, character storage, and glyph display.

Sounds like a fundamental misunderstanding of the relationship of typography and humans. ;-)  Hacks enable culture as much as standards do.