any practical reasons requiring that all members of a particular family should have the same glyph complement.

How about, no surprises? Assume that someone has set a project in a regular width of a font, but the amount of copy requires that the font be set in a smaller size than desired. If the author were to substitute a condensed weight of the font, he or she would expect the font to contain the same characters...

Yes, I certainly understand why the character set needs to be the same. Here I'm talking about the glyph set. Not all variant glyphs are necessarily appropriate for all widths/weights.

André

The inclusion of .case accent glyphs is merely a simplification in the font development process. The designer can place the glyph outlines in the .case variants higher than in the glyphs intended for lowercase letters. I.e. the difference between the caps height and the x-height can be "hardcoded" in the accent glyphs. Then, when generating composite glyphs, the designer does not need to shift each component accent in all the composite glyphs up by the same value, but instead, all accent components can rest at the y=0 position. Then it's easier to make changes. When I move the outlines of the acute.case or dotaccent.case up or down, the changes will be immediately reflected in all the uppercase accented letters, but the lowercase letters won't change. And in general, when using the .case approach, the designer only needs to adjust the x-position (left-right) of the components in the composite letters, and does not need to worry about remembering to set the correct y-position.

If we use the same accent glyph for lowercase and uppercase letters, then any change will require going through all the uppercase glyphs and making the change for each (and we need to pay attention that those changes are consistent).

In addition, those .case variants can be used "ad hoc" as a "poor man's" method to create additional composites while typesetting (through the use of kerning). Finally, this simplifies hinting a bit because we can define additional alignment zones just for the .case accents.

So it's merely a way to simplify the creation of composite glyphs. But of course, some designers may choose to do it differently. They can write a "mark" feature or use Python scripting to produce the correct placements, but the practice has shown that using the .case method is the simplest, and works even in font-creation tools such as Fontographer or TypeTool that do not have the more advanced features.

Best,
Adam

Actually, I just realized that most of what I've written applies to accents placed on top of the letters. For commaaccent, cedilla and ogonek, it is, indeed, less common to include .case variants (and the standard Fontographer 5 encodings do not have slots for these).

In general, I'd say, including a few superfluous glyphs does not do any harm. In OpenType PS, those will be compressed with their identical counterparts using subroutines, and in OpenType TT they will only occupy a few more bytes. I wouldn't worry about it.

I'd even say: any methods used in the font for the creator's benefit (i.e. methods that improve the speed and consistency of the font creation) that do not IMPEDE or LIMIT the usability of the font for the user, are fine.

Of course this depends on the font creator's priorities. If one's goal is to create a "technically ultra-perfect font", which is optimized to the point of perfection, the designer may choose to employ any optimization he or she wishes.

In the end, it's a matter of decision, really.

(...) we can define additional alignment zones just for the .case accents.

It seems I lost this lesson. How to create alignment zones just for a partial set of glyphs? I just know that way, where zones are always global:

FL alignment zones dialog.

I suppose alignment zones for a given set is especially important because overshoots usually are not the same between different cases (for example, I use 24 for lowercase, small caps and petite caps, and 32 for uppercase, within a 2048 UPM).

You can only define global alignment zones. What I mean is that you can have a alignment zone specifically for the .case glyphs, which are typically drawn way above the caps height and even ascender height, and by default don't have an alignment zone on their own.

(By the way, I do think that the ability to define per-class alignment zones would be useful).

Best,
Adam

Thanks, Adam. As usual, clear and precise.

I imagine class alignment zones could be useful when doing automatic hinting in the situation I cited, with different overshoot for UC and lc. A global 0,–24 is not adequate to UC overshoot 0,–32, I guess. I add a secondary zone at –24,–32 to compliment this difference, but have no idea if this has any real sense.