Easy? I can't think of one. Less cumbersome? Yes, but the process involves a few extra steps outside of FL...

Being lazy, what I would do is select all the small caps in the font window, open the metrics window, and use copy and paste to move them around. Not great, I know...

Another option:

1. Make a COPY of your original file.
2. EITHER copy and paste your SMCP letters into their corresponding normal cap positions; OR scale the normal caps to the same size as SMCPs and adjust metrics accordingly.
3. KERN as usual, then EXPORT METRICS.

Then, open the .afm file in a simple Text Editor, and...

Finally, OPEN your ORIGINAL file and IMPORT METRICS. choosing "Add imported kerning data to the current font" and SAVE.

Yeah, a lot of steps, but should take less than fifteen minutes from start to finish.

Assuming you've set up smallcaps as an OpenType feature, you could use the OpenType tab of the Preview panel to generate the "slash string" that you could copy and paste to the Metrics window.

Yes, the last method is currently the only workable:

1. Compile the features in the OpenType panel.
2. Open the Preview panel.
3. Switch to the OpenType Features tab of the panel.
4. Type in any string you want in the top text box.
5. Apply the features you want (e.g. "smcp").
6. From the bottom read-only text box, copy the output string.
7. Paste the string into the Metrics Window text box.

We intend to improve that particular aspect in the upcoming release of FontLab Studio.

Yes, that's the method I use.
The OpenType Preview panel and the Metrics window work well together.
I like the way that one can change the type size in the OpenType Preview panel by changing the window size.

1.

To remap kerning from caps to small caps, you can also use a terminal command. First, export the afm file with your kerning. Open the terminal window and do this:

cat file.afm | grep KPX | grep ' [A-Z] ' | perl -pe 's/KPX //' | perl -pe 's/([A-Z]) /$1\.smcp /g'

Now you can copy the new kern pairs out of the terminal window and into the "Add Kerning Pairs" box in Fontlab.

Here's how this works:

cat file.afm

This prints your whole file to the terminal window. (On the Mac, you can drag the file from the Finder to the terminal window and it will fill in the whole path & file name for you.)

cat file.afm | grep KPX

This filters the afm for the kern pairs.

cat file.afm | grep KPX | grep ' [A-Z] '

This filters the afm for kern pairs that involve the letters A-Z.

cat file.afm | grep KPX | grep ' [A-Z] ' | perl -pe 's/KPX //'

This deletes the KPX at the beginning of each line.

cat file.afm | grep KPX | grep ' [A-Z] ' | perl -pe 's/KPX //' | perl -pe 's/([A-Z]) /$1\.smcp /g'

This changes the single letters A-Z to A.smcp-Z.smcp. (You can change the 'smcp' to whatever your suffix is.)

2.

To generate test strings, you can use a similar approach. Make a text file with the test strings IN ALL CAPS.

cat strings.txt | perl -pe 's/([A-Z])/\/$1\.smcp /g'

Copy the result into the Fontlab metrics window. (Again, you can change 'smcp' to whatever your suffix is.)

You can also do this without a separate file:

echo "MY TEXT" | perl -pe 's/([A-Z])/\/$1\.smcp /g'

This produces:

/M.smcp /Y.smcp  /T.smcp /E.smcp /X.smcp /T.smcp

3.

On the Mac, you can append | pbcopy to move the result to the clipboard automatically, which saves some mousing around the terminal window, e.g.:

cat strings.txt | perl -pe 's/([A-Z])/\/$1\.smcp /g' | pbcopy

echo "MY TEXT" | perl -pe 's/([A-Z])/\/$1\.smcp /g' | pbcopy

4.

Be warned that you can only paste a limited amount of text into the Fontlab metrics window. So if not all your sample strings are showing up after you paste, break them into smaller pieces.

One more stupid terminal trick: if you also want to make a mathematical adjustment to the small-cap kern values before you import, add the following:

| perl -pe 's/^(.*?)([-\d]+)(.*)$//;$val=$2;$val=$val*0.6;print $1.$val.$3'

The part that says $val=$val*0.6 is what converts the kern value. You can change this to whatever transformation you like — add 100 would be $val=$val+100, 50% would be $val=$val*0.5, etc.

The code above will adjust the kern values by 60%. As above, you can append | pbcopy to the command to put it on the clipboard automatically. So putting it all together:

cat file.afm | grep KPX | grep ' [A-Z] ' | perl -pe 's/KPX //'
| perl -pe 's/([A-Z]) /$1\.smcp /g'
| perl -pe 's/^(.*?)([-\d]+)(.*)$//;$val=$2;$val=$val*0.6;print $1.$val.$3' | pbcopy

Using this command, you can remap all your cap kerning to small caps, and rescale the values, in one step.

Whoops, one small fix — forgot to convert the new kern value to an integer.

So instead of this:

print $1.$val.$3'

Use this:

print $1.int($val).$3'

And the revised code is this:

cat file.afm | grep KPX | grep ' [A-Z] ' | perl -pe 's/KPX //'
| perl -pe 's/([A-Z]) /$1\.smcp /g'
| perl -pe 's/^(.*?)([-\d]+)(.*)$//;$val=$2;$val=$val*0.6;print $1.int($val).$3' | pbcopy

Time for some heresy.

Put the small caps in the lc positions of a seperate font.

– far easier treatment when kerning.
– for the user its just the same amount of trouble to pick small caps from the OT or the type menu.
– saves you a lot of labour.

I admire Buttericks approach but I feel it’ll never become my way of doing this …
One single char. messed in the code – and you’re going to sink.

good luck!

Andreas: Put the small caps in the lc positions of a seperate font.

What if the text that the user needs to represent in smallcaps is uppercase characters?

What if the text that the user needs to represent in smallcaps is uppercase characters?

Well, then you’ll have to re-type it. This is a disadvantage, alright.

But I assume this is a rather seldom case to happen. The question is, is it worth the trouble, after all.

Put the small caps in the lc positions of a seperate font.

It's not heretical. I just don't think it pays off in efficiency. Yes, it's easier to space and kern the small caps when they're in the LC positions. But then you have a second font with a lot of duplicate characters in it. For instance, if you change the shapes or spacing of the caps in the original font, you have to migrate those changes to the small cap font. But you can't copy the kerning from the original font directly, because the UC->LC kerning means something different in the SC font … the complications escalate from there.

As for the risks & rewards of using terminal commands, I imagine most type designers could learn the basics of grep filtering and perl substitutions in a few hours. Since it will save weeks of your time in the long run, why wouldn't you?

We intend to improve that particular aspect in the upcoming release of FontLab Studio

The ideal solution would be to add the Opentype layout toggles to the Metrics window itself, thus merging the Preview and Metrics functions. Then you could check off your 'smcp' box and type away using small caps.

"Bash? Isn't that the polite form of addressing on typophile?"

Andreas: Well, then you’ll have to re-type it.

It isn't simply that you have to retype the text: you have to change the text.

The most common use of smallcaps in the texts I work with is for organisational and other abbreviations. If the text has UN and USA, I really don't want to be changing it to un and usa just to access smallcaps. Remember, digital text gets repurposed for lots of different media, and changing text to affect display is a really bad idea.

John,

1. Put small cap glyphs into lowercase positions of a separate font.
2. Add a "c2sc" OpenType Layout feature that replaces uppercase glyphs with the lowercase glyphs.

Look at Adobe's Trajan Pro or Sava Pro. That's exactly how it is done there :)

More on small caps in a separate font at http://typophile.com/node/32455 :)

Best,
Adam

But Trajan Pro and Sava Pro have no regular lowercase. I don't see any benefit to avoiding having to implement 'smcp' in one font only to still have to implement 'c2sc' in another font.

John,

if you put the small caps in a separate font, there would be no regular lowercase in that font either.

If you put small caps into a separate font that only implements "c2sc", I see the benefits as follows:
1. The small caps will be accessible in all applications, no matter whether they implement OpenType Layout or not, and whether or not they have a UI for enabling OpenType Layout features. They will even work in Microsoft Office 2010 which does implement OpenType Layout and has UI for enabling OpenType Layout features but that UI excludes OpenType small caps (i.e. small caps in Word 2010 are still made by reducing uppercase letters).
2. The small caps will be visible to users when they are doing normal font selection from the font menu, so they'll be able to see what they'll get before they pick the font.
3. The users will actually be able to see at all that the font family has small caps. If you put small caps into the same font as lowercase, there is no way to see which font on a user's system actually has them, because no single UI exists to my knowledge for selecting a font that has certain layout features.
4. When used as a webfont, a font with small caps in a separate font will be much smaller than a combined font, and the small caps will be more accessible: every browser allows font selection, but very few support applying user-controlled OpenType Layout features.
5. In all existing font development tools, including refurbished classics such as Fontographer, it's much easier to space and kern small caps if they're encoded as lowercase.
6. Every automatic hinting process will perform better if the small caps are in a separate font, because there are fewer stem thicknesses and less chances to mix up alignment zones when small caps and actual lowercase are in separate fonts.
7. Font vendors can sell the small cap font separately, and the users can buy it separately. Instead of having one cheaper font without small caps and one more expensive with them, there are just two fonts. So a user who bought the font with lowercase and later gets the small caps font does not have to change existing documents (switch from "Std" to "Pro" everywhere).

Even if 1, 2, 3, 5 and 6 were not true (i.e. better UIs existed etc.), there would still be no clear disadvantage of having small caps in a separate font over integrating them. Or can you think of a serious benefit for having integrated small caps vs. separating them?

I obviously see the benefit of using OpenType Layout features in general, especially if one feature affects a reasonably small number of glyphs which heavily interact with the rest of the glyphs in the font (through kerning, mark positioning, ligaturing etc.). So most kinds of OpenType Layout features do make sense.

But small caps in OpenType Layout don't make sense:

1. When "smcp" is activated, small caps usually replace a huge number of encoded glyphs (letters, often also punctuation, marks etc.) -- so the font vendor ends up nearly doubling the size of the font even for the users who won't use the small caps ever. Which is especially important with webfonts.
2. Of course it does make sense to include uppercase glyphs in the small caps font, so yes, there will be some doubling in size either way. But while uppercase is often kerned with lowercase, and uppercase is often kerned with small caps, there are hardly any cases where lowercase would be kerned with small caps (and I don't just mean kerning, also other kinds of glyph interaction) -- which is an evidence that lowercase and small caps do not necessarily belong into one and the same font.
3. Small caps often end up being in a separate glyph run from lowercase or other characters anyway, because often users apply different formatting to them within the same line (e.g. different tracking, or slightly different size).

So, what do you think?

A.

Adam, good arguments, but...

2. Of course it does make sense to include uppercase glyphs in the small caps font, so yes, there will be some doubling in size either way.

Incorporating smallcaps into the same font = approx 1.5 times the number of glyphs (if using subroutines, this is true even if following Adobe's approach of duplicating smallcaps). Placing the smallcaps into a separate font = 2 times the number of everything, not just glyphs but also all the other font tables.

I think the issue then becomes where you want your efficiencies and where you want to take your hits. As you say, for webfonts there may often be efficiencies in not including smallcaps in a font, but this is in general the argument for subsetting and is not smallcap specific. A lot of my clients are concerned with different kinds of delivery footprint and, believe it or not, hard drive footprint. [Did I tell you that significant parts of VOLT had to be rewritten to get the Gabriola font down to a size that would be accepted for Win7?]

As you know, I'm also opposed in principle to font makers doing things that let software developers off the hook for supporting layout features.

John,

I think the entire notion of font format development is quite interesting because it keeps following a sinusoid where things are being disassembled, then assembled, then disassembled, then assembled etc.

We started off with Type 1, where one font existed in several files (.pfb, .afm, .inf, .pfm -- and analogical on Mac), then we moved to TrueType where everything was in one file. But because of the codepages, things had to be split into several fonts, and then OpenType united them into one file. But now with webfonts, we're splitting them (not only because of webfonts -- also because of mixing various writing systems), but at the same time, we're working on "virtual unification" through composite fonts and the CSS font stack.

IMO, according to Occam's razor, the "BASE" table and the "smcp" feature are "worse" solutions. I tend to think that these days, splitting font files physically at the boundary of what would become glyph runs when typesetting would make sense most. But for that, we do need a composite font mechanism. Actually, to a large extent, I feel that we already have one such mechanism: CSS. A CSS file can register a font family in the browser that points to various font resources for various styles and character ranges.

I believe more and more, and at some point, when we'll be talking about installing fonts in applications, a CSS file will be what we'll be "installing". It should replace Composite Font Representation, SING and all the other stuff. Perhaps CSS should be extended to incorporate some aspects of what is in CFS -- but don't you think that CSS is possibly a better solution than CFS, SING etc.?

Best,
Adam

Adam: I tend to think that these days, splitting font files physically at the boundary of what would become glyph runs when typesetting would make sense most.

In my experience, most presumptions about what will constitutes glyph runs run into real world problems, of greater or lesser severity. Microsoft presumed that a change in text direction would break a glyph run, and as a result we can't apply necessary contextual substitutions relative to Arabic date signs across intervening numerals. Failure to roll common European punctuation characters into glyph runs with non-Latin scripts that now use these characters means that we can't kern to them. And so on. So I'm wary about dividing fonts along glyph boundary lines, because those lines are not well defined.

...don't you think that CSS is possibly a better solution than CFS, SING etc.?

Possibly, yes. More generally, and a subject for another discussion, I think there are good arguments to be made for pursuing font technology developments under W3C.

butterick: The ideal solution would be to add the Opentype layout toggles to the Metrics window itself, thus merging the Preview and Metrics functions. Then you could check off your 'smcp' box and type away using small caps.

I dream about things like this...

But small caps in OpenType Layout don't make sense

On reflection, I am persuaded by Adam's argument.

I do very little typing to kern my small caps (or any set of glyphs) by just using find/replace. (I use BBEdit 'cuz it's fast and easy to use for just this sort of thing.)

For instance, I take the whole of the small caps text from the kerning window:

/a.smcp/b.smcp/c.smcp/d.smcp/e.smcp/ ...and so forth

and do a find a replace of the / with, for instance, /Y/ so I get:

/Y/a.smcp/Y/b.smcp/Y/c.smcp/Y/d.smcp/Y/e.smcp/Y/

And just copy/paste that new line of text back in. I have all 26 small cap glyphs ready to be kerned with Y. It works perfectly for any instance—punctuation, anything against anything. With kerning classes everything just falls into place right away; and because it pairs one with whatever set you like, you can kern both sides, one right after the other:

/f/a/f/b/f/c/f/d/f/e

f with the whole lowercase. Or period with all lower:

/period/a/period/b/period/c/period/d/period/e/period/

...and then all upper, then all small caps. Works great for parenthesis and other random parts that need to be next to one side or both of any set of glyphs, with very little typing so the focus is on the kerning, not the typing of the pairs to be kerned. I can kern large sets quickly because of how fast the permutations can be built. Bonus: because it is a long line of glyphs I get a better sense of the color of the overall text as I go so parts that are wrong stick out, and parts that are fixed fade back.

eolson: I dream about things like this...
Like this?