An aside: X-Cap is a great term for that.

Within the font, there are a couple of ways you could access these smaller smallcaps, and could even employ more than one of these methods. The most obvious OTL feature to use would be the Petite Caps 'pcap' and Capitals to Petite Caps 'c2pc' features. These were specifically designed to support this kind of smaller smallcap, as implemented in Emigre's Mrs Eaves and Filosofia types. See these links:

http://www.microsoft.com/typography/otspec/features_pt.htm#pcap

http://www.microsoft.com/typography/otspec/features_ae.htm#c2pc

In addition, you could treat the smaller smallcaps as stylistic variants of the regular smallcaps, using 'salt' and/or 'ssXX' features.

In terms of present application support, your best bet would be to map the regular smallcap glyphs to the smaller smallcaps glyphs in e.g. the 'ss01' feature. This would make them accessible in Adobe CS2 apps. The Petite Caps features are not supported in any shipping apps, but are supported in the Windows Presentation Format environment and XAML, so will be more accessible in future. It is worth implementing these features now.

would it be unkosher to map smaller, x-height capitals to the lowercase using the smcp feature and larger smallcaps to the upercase using the c2sc feature? thoughts?

I wouldn't do it. John's right that the petite caps feature should be used for this. Mapping different small caps using smcp and c2sc would be confusing to the user who rightly would expect to see the same small caps regardless of whether they typed UC or lc. Mapping the x-caps to smcp would force the user to do something to fix the text if the result wasn't what they wanted whereas using the petite caps feature would give them full control over what was happening without unexpected results.

George
I felt bad because I had no shoes, until I met a man who had no Bodoni

i don't agree that the petite caps feature is the right one. i mean it's fine to use it for this, but i doubt it'll ever get implemented into any major software apps (just my own hunch). stylistic sets is a good option. but i still don't see why users should "expect to see the same small caps regardless..." just because that's what Adobe fonts do. what is the all small caps feature for anyway? does anyone set text in all small caps? i'm assuming that the c2sc feature is for things like acronyms anyway where x-height caps just look silly and so it would make sense to use larger smallcaps for situations where smallcaps are replacing capitals. can i get a designer's take on this? miss tiff, what do you think?

If it isn't easy to access it ain't gonna get used. That said, if it were as easy as selecting a stylistic set then it wouldn't be a problem. Would it? I mean, stylistic set one, Caps and small caps, stylistic set two Caps and petite caps, stylistic set 3 small caps and petite caps. Would that work?

I'll assume that your uppercase A is the "A" glyph, the lowercase a is the "a" glyph, the mid-sized smallcap A is the "A.smcp" glyph, and the tiny smallcap A is the "A.pcap" glyph.

Then your feature code should look like:

==

feature smcp {
sub a by A.smcp;
} smcp;

feature c2sc {
sub A by A.smcp;
} c2sc;

feature pcap {
sub a by A.pcap;
} pcap;

feature c2pc {
sub A by A.pcap;
} c2pc;

feature ss01 {
sub A.smcp by A.pcap;
} ss01;

feature salt {
sub A.smcp by A.pcap;
} salt;

==

(For salt, it might also be:

feature salt {
sub A.smcp from [A.pcap ...];
} salt;

if your salt code contains some one-to-one-of-many mappings.)

The "ss01" feature can be used in InDesign CS2 and in Apple applications on Mac OS X 10.4 (TextEdit, Pages, Keynote). The "salt" feature can be used in Illustrator CS/CS2.

The "pcap"/"c2pc" features can be used e.g. in Apple applications on Mac OS X 10.4 (TextEdit, Pages, Keynote), in Microsoft WPF applications such as the Expression Interactive Designer (http://www.microsoft.com/products/expression/en/interactive_designer/ ), in XeTeX (http://scripts.sil.org/xetex/ ).

Regards,
Adam

> but i doubt it’ll ever get implemented into any major software apps

It is already implemented in WPF (just like Adam mentioned)
http://windowssdk.msdn.microsoft.com/en-us/library/system.windows.fontca...

> feature smcp {
sub a by A.smcp;
} smcp;

feature pcap {
sub a by A.pcap;
} pcap;

Shouldn't these be

feature smcp {
sub a by a.smcp; #a.smcp instead of A.smcp
} smcp;

feature pcap {
sub a by a.pcap; #a.pcap instead of A.pcap
} pcap;

It's a subtle difference, but you don't want your 'a' to default to 'A', right?

Note: a.smcp is just a copy of A.smcp, and both glyph would exist in the font.
The same would apply to a.pcap/A.pcap.

> It’s a subtle difference, but you don’t want
> your ‘a’ to default to ‘A’, right?

Indeed, *if* you choose to include duplicate "a.smcp" and "A.smcp", as well as "a.pcap" and "A.pcap", then the code should be as you suggest. If, however, you decide to only supply one set of small cap glyphs and one set of petite cap glyphs, then I believe it’s better for these glyphs to have uppercase names (before the prefix) so that they fall back to uppercase letters when Unicode codepoints are computed by Acrobat. The reason for this is that all-uppercase text is always correct while all-lowercase is not (i.e. "ADAM TWARDOCH" is correct text but "adam twardoch" is not). For this reason, for example, Unicode character names are set in all uppercase.

A.

Unless you happen to be erik spiekermann

;^)

I believe it’s better for these glyphs to have uppercase names (before the prefix) so that they fall back to uppercase letters when Unicode codepoints are computed by Acrobat.

This is one of the reasons i proposed mapping the larger small caps to the caps and the smaller to the petite caps, to avoid all this confusion.

I have followed Adam's advice for this first attempt...

It seems to work. I can change the type to small caps and THEN to petite caps with the stylistic set in InDesin and the stylistic alternate in Illustrator...

It works... but I am wondering at this point if it might be easier for everybody if I just left everything as three different OpenType fonts-- regular, small caps and petite caps (I would prefer the term x-cap -- more descriptive and a little less gay sounding)

With the three separate sets you could just access the set you wanted through the character pallet in one stroke and be done with it. Albeit-- that way would lose the kerning between the caps and small caps and lower case that I have meticulously set up... but I really wonder if that stuff is so very important to most design situations anyway.

And you could always hand kern, like I have learned to do, if it was a concern...

R\V

Robby,

I agree that for small caps, it’s worth considering putting the designs into separate fonts. Small caps is a typographic variation that is on the verge. Small caps deviate from the basic grapheme of the letters much more than ligatures or swashes, but probably less than italic or bold. Of course you’d put italic or bold into separate fonts, and of course you’d put swashes or ligatures into the same font (in OpenType).

But small caps? The makers of the OpenType specification have envisioned the appropriate features, such as "smcp", "c2sc" etc. But this does not mean that you *must* integrate your small caps into the basic font. Indeed, *if* you provide a separate small caps font, even people who use Word, Freehand, Corel Draw etc. will be able to use them. Underware puts their small caps into separate fonts, for example.

Note that even if you make a separate OpenType font that has small caps in place of lowercase letters and uppercase letters on the uppercase slots, it’s still useful to include the "c2sc" feature in that font that substitutes the uppercase by the lowercase:

feature c2sc {
sub [A B C ...] by [a b c ...];
} c2sc;

I think it would be also useful to include a dummy "smcp" feature a la:

feature smcp {
sub .notdef by .notdef;
} smcp;

This will ensure that various applications will "register" the font as having small caps.

Adam

> that way would lose the kerning between the caps
> and small caps and lower case that I have
> meticulously set up

As I say, you’d probably want to put the small caps along with uppercase letters into the separate fonts. You’d still have the kerning between the small caps and the uppercase.

And, for what exact purpose would you want to kern small caps with lowercase? :>

Robby,

If Petite is too gay a word for you, you could call them X-treem concentrated super-potent caps. ; )

If the 3 styles of caps are already available in PS fonts, why make a new format of font that has to be used the same way? Isn't the benefit of OT that one font can contain all the variants of one weight/style? I don't agree with Adam that small caps are so irrelevant to a basic Roman font. I expect book designers would like very much to be able to have small caps and x-caps in the regular font. Especially since implementing them is as simple as selecting a feature from a menu. I think small caps will continue to be ignored as long as they reside in separate fonts.

You've heard some ideas for the substitutions, and I'm sure once the logic is decided and implemented, users will find it very nice to use. See the link on the Mrs. Eaves Open Type page showing the features of that typeface. I don't agree with all the combinations that are available with that design, but you can choose your own and offer different levels of automation to satisfy different kinds of designers. The glyph palette is always there as well, and you get to keep your Cap/small cap kerning.

> feature in that font that substitutes the uppercase by the lowercase:
feature c2sc {
sub [A B C …] by [a b c …];
} c2sc;

Using a feature to do case conversion (which means replacing an Unicode point by another)?!... now that's extreme stuff!! :^)

> Using a feature to do case conversion (which
> means replacing an Unicode point by another)

No, it does not mean that. OpenType substitutions work on the glyph level. The character codes should be principally retained. Only in a situation when the Unicode codepoints are not available, an application can fallback to glyph names. :)

I agree with John and Carl (Crossgrove).

I would sincerely hope you put all this in one font, and for the X-small caps use both ss01 and pcap/c2pc.

If you decide to make multiple fonts to make access easier for the less-OpenType-savvy part of the universe, please also keep them all in the main font for those of us whose apps do support this stuff.

Regards,

T

I have the Clarice OT book weight caps, small caps and petite caps all working properly.

I can now use the same code for the medium and bold weights. And I am going to just leave the old individual type one fonts as they are for people that don't care about open type features.

I really appreciate all the help, everybody...

R\V

> If you decide to make multiple
> fonts to make access easier for
> the less-OpenType-savvy part
> of the universe, please also
> keep them all in the main font
> for those of us whose apps do
> support this stuff.

I agree. Indeed, the choice of whether to use the OpenType Layout features or separate fonts for small caps is not necessarily an either-or choice. It can be an "and" option.

But I think my point is valid in that the small caps represent a case that is on the "verge" of what is reasonable to be supported through OpenType Layout features.

For example, when making the OpenType conversion, Adobe chose to merge the character sets of Robert Slimbach's Poetica and Matthew Carter's Shelley Script into single OpenType fonts. In case of Poetica, I think that it was a completely founded decision. However, in case of Shelley Script, I'd argue that keeping these fonts as separate "Shelley Andante", "Shelley Allegro" and "Shelley Volante" fonts *might* have been a good choice *as well*, or perhaps even a better choice.

In any case, *this* was an artistic choice, not technical. In some cases, decisions in what to put where in a font, are of technical nature (for example, whether to put ligatures into the "liga" feature rather than the "onum" feature). In other cases, like making decisions about stylistic sets or whether a certain ligature should be standard or discretionary, it really is an artistic choice.

I'll argue that in case of small caps, the issue *is* somewhat on the junction of artistic and technical considerations.

Carl writes:
> I expect book designers would like very
> much to be able to have small caps and
> x-caps in the regular font.
> Especially since implementing them is
> as simple as selecting a feature from
> a menu.

That's a valid point.

On the other hand, today's applications' font menus don't tell me which fonts support which features. If I put a small caps font as a separate font, I'll see it in the WYSIWYG font list of InDesign, Illustrator, Suitcase or Font Explorer along with the other styles. This means that as a font user, I'll be instantly aware of the fact that the particular family includes small caps.

If you show me at least *one* application that allows me to easily look up which OpenType fonts in the font collection on my computer have small caps (or support any other OpenType feature, for that matter), I'll be very grateful. Seriously.

In other words: these days, in order to do the "as simple as selecting a feature from a menu" thing, the font user needs to know upfront that a font supports a certain feature. It's not much of a problem for a book designer who uses 2-3 font families but for graphic designers who do avertising etc., and need to deal with large font collections, it is a problem.

A.

If you're going to have more than one set of small caps, I'm with Adam -- put the "alternate" small caps in a separate font.

One advantage is that the menu name would be quite informative, eg "Shinnface with Middle Caps" rather than "ss03".

I'm working on a typeface with a small x-height, and two sizes of small caps appears to be in order. So I am putting the small caps in the standard font, and the "Middle Caps", as I term them, in the font "Shinnface with Middle Caps".

Also, It's not apparent whether Petite is larger than Small, or vice versa. Or whether a Petite "caps with small caps" setting combines Caps with Petite Caps, or Petite Caps with Small Caps. So to avoid confusion, having separate fonts avoids the possibility of a Petite with Small Caps setting, which is an unlikely usage.

"If you show me at least *one* application that allows me to easily look up which OpenType fonts in the font collection on my computer have small caps (or support any other OpenType feature, for that matter), I’ll be very grateful. Seriously."

InDesign's glyph palette shows only glyphs that are present. No fakes there. The OpenType menu shows features that are built into the specific font you're viewing, with non-functional fetures in brackets.

On the mac, InDesign also shows in the font menu OpenType icons, which is a small clue.

Though these are not what you are asking for, they do solve the problem of finding out which fonts have small caps, to some degree. Of course, it is one application, or suite of apps, and not available system-level, and not available at all without the apps.

The basic complaint here is that one can't tell what capabilities lie within any given font without deeper exploration. This to me is a reason to develop the means to reveal this information, not a reason to make OpenType fonts in several parts.

The thing you are asking for is a worthy project, but probably complex. Is anyone up to the challenge? It would be an interesting utility, or function of the system(s), to show something like Adobe's list of icons; they indicate at a glance (once you understand them) what features are included.

I don't agree that Small caps/Petite caps use would be so odd or inadvisable. One benefit of a variety of caps in a font (think Poetica or Operina) is that they can be combined a lot of different ways, some of which allow you to mimic different weights, and which may be more appropriate for certain sizes. Versatile, not confusing.

Carl, yes in principle, but the names are confusing.
IMO, a basic small cap is the one that's x-height, or just slightly taller.
However, with small x-height typefaces, room is opened up between x-height and cap height, for another "small" cap, which I would term "Middle Cap" -- ergo Full Size, Middle, and Small Caps being the nomenclature. After all, everyone's familiar with S, M, L and XL as designators of size range.

But that's just my logic, obviously Emigre has different ideas.
The thing is, different foundries will interpret OT features in different ways (just as they used to interpret "expert" set content in different ways in the previous generation of technology).
So what's needed is for software applications, Adobe and Quark of course, to provide the opportunity for foundry-designated descriptors. "sso1", for instance, is really hopeless.
Not just a name, but a visual showing would help.

Ideally, an application user could "mouseover" an item on the menu item, and a panel in the palette showing the U&lc alphabet and figures would change accordingly.

Right. Robby's caps are Regular, middle and small. A set smaller than the x-height would be (besides strange) extra-small.... Since small caps are more generally associated/used with Caps, though, whatever names we give to additional sets of caps shouldn't really refer to the x-height, since even very conventional small caps can be larger than x-height.

I would like for System software to reveal this information; in any app, both clear symbols like Adobe's, plus foundry style names should be shown, since as time goes forward, I suspect those names will become even less standardized. Given the possibilities of OT, and the different things different designers use OT for, we can't possibly predict now what all the eventual style names will be. I'm including something I call "Cartographic Caps" in my next release along with Swash Caps. If a user can't see them or the style name is meaningless, or worse, buried and meaningless, I agree, they're almost the same as not there.

In the absence of retail software that adequately shows a font's full scope, the onus is on foundries to produce pdf specimens -- manuals, really -- which demonstrate its features.
Or perhaps special website pages with interactive explanations.
There is a marketing opportunity here for well-designed documentation. Kent Lew's specimen for Whitman springs to mind, as something that shows glyphs attractively, lists features, and also puts them in explanatory context.