Beyond what you wrote, I would like to add:

• ampersand
• quotes
• at
• numbersign
• asterix
• percent and perthousand

It breaks down into how small caps are used. For books anyway, there are two uses, (1) run into text and (2) used as display, as for subheads.

For (1), you want to maintain most of the punctuation of the regular font — it would look odd to have the quotes change (includes apostrophe), the period change, etc. For most of us book people, it would look odd to have the numbers change, unless someone was so crass as to use lining figures in the text.

For (2), ideally you have a separate set of glyphs that should mirror the full caps in all ways they can occur in display, just smaller, but with a weight that lets the smaller size carry itself when compared to the weight of the text. No telling what words or punctuation might appear in a heading, so you would need everything where the position or size of the basic font was appeared odd — just as with full caps.

As to size, the run-into-text small caps should be just a bit bigger than x height, with the sc “X” roughly 10 to 20 units taller that the topmost part of a lc “n”. They need to blend into the lower-case letters, without appearing optically smaller.

For display, it is a harder call, but I’d say a height should be around 10 percent greater than a l.c. “x” would be most useful.

FWIW

Which special characters schould be activated with smcp-feature, and which with c2sc?

This distinction addresses the “double duty” described by Charles.

What I’m doing now is to put the “text” features (1) in smcp, and the “optical size” features (2) in c2sc.

That is to say, “smcp” only substitutes the lower case alphabet.
So smcp, which is really “caps with small caps”, has default figures (whether cap-height lining or oldstyle), whereas “c2sc/all-small-caps” has small-cap height lining figures.

However, I don’t make c2sc versions of every character, omitting those which I consider to be “text” characters that don’t usually occur in all-capital settings, such as parentheses and brackets. I think the bar character is instrumental in determining the look of “all small caps”, representing the way that setting is most likely to be used, in a folio for instance.

Here are the two styles.

thanks for your answers.

you are right, it depends on text face or display face. Sigh ... all those differentiations.

Concerning smcp and c2sc – I have these sets at the moment:
- upper case
- lower case
- smallcaps

- lining figures
- oldstyle figures
- smallcaps figures

- uppercase currency symbols
- small caps currency symbols (addional characters like bracked.sc would go here I guess)

I just don’t know yet whether to use smallcaps figures when activating smcp or “reserve” them for c2sc. My default figures are lining ones, but I am not sure about that as well.

I think the bar character is instrumental in determining the look of “all small caps”, representing the way that setting is most likely to be used, in a folio for instance.

I don’t get this sentence... might be because english is not my mother tongue.

If lining figs are your default (nothing wrong with this), then I would sub oldstyle figs with {smcp}. I would sub your sc figs only with {c2sc}. You might also consider parens, braces, and brackets to sub with {c2sc} but not {smcp}.

As Nick pointed out above, {smcp} is usually invoked when the designer wants U&sc. Thus the punctuation and figures should accommodate both heights. Standard puncts and oldstyle figs do the best job in this case, in my opinion.

Nick’s comment about the vertical bar has to do with the fact that one of the most common uses of small caps, at least in book work, is as a running element in conjunction with a folio (page number). It is currently a favorite stylistic device to separate these two things with a vertical bar. The standard vertical bar stands too tall when set in a line of small caps and doesn’t look vertically centered against the nice horizontal line of small caps. Book designers usually baseline shift the bar down a bit to look right. Since this is usually done once on a master page, it’s not such a terribly tedious task. But his idea of an alternate form for [c2sc} is a nice detail.

— Kent.

I guess my biggest purpose on Typophile is just to represent those who use type.

So here is a for-instance:

Right now, I’m setting a book with 4,000,000 characters (1,100 manuscript pages). Sequence of events: The files are supplied by the author, then edited. After editing, which includes any coding or change to the text, the book is designed. And in designing the book, the designer will decide that certain elements, some of which (e.g., acronyms) are run into the text stream, are to be set in small caps. The book does NOT go back to the editors after design.

Except for the size, this is a pretty typical workflow.

OK, think it through: in the copyedited files, the elements to be set in small caps may be (1) full caps, (2) a mixture of cap & lower case, or (3) lower case. In the week that I spend typesetting this, when I encounter one of these elements in the text, all I want to have to do is hit “all small caps” (which takes case of 1-3), and be done with it.

Well, almost done. I’ll then run a global S&R for “all small caps” with “0 tracking” and replace the “0” tracking value with a value appropriate to the text font. Small caps in display won’t be affected; they’ll be set either through a paragraph style which will include a bit of tracking, or occasionally “directly formatted,” again with tracking done as set.

If the type designers start messing around with just which small cap function does what, I’ll have a lot more work & confusion.

I believe it was Adam who suggested that “display” small caps really call for a separate font, and I agree. If you’re gonna screw around with just what feature does what, put it all in a readme. And make sure the EULA lets the end user go in and modify the font(s) so they are useful.

So, Charles, are you advocating completely against contextual punctuation for small caps? (I don’t see how that would affect your example, since presumably you’re just selecting the letters of the acronyms.) Or are you advocating against including any figure substitution in either small cap feature? Or all of the above?

So far, I haven’t seen anyone suggesting that “All Small Caps” not change all cases to small caps — {c2sc} for the caps and {smcp} for the lc. Software must implement both for the All Small Caps command.

I can respect the opinion that these two features should perform only the minimum written in the spec (which BTW, suggests that OsF may be included in {smcp} subs).

But it doesn’t seem to necessarily follow from the example that you outlined. Or, at least, I’m not seeing it.

— K.

As to size, the run-into-text small caps should be just a bit bigger than x height, with the sc “X” roughly 10 to 20 units taller that the topmost part of a lc “n”. They need to blend into the lower-case letters, without appearing optically smaller.

I think with the growth of multi-script OT fonts, the default Small Caps size is going to be closer to between 10-20 percent larger than the lowercase to accommodate Cyrillic SC.

Kent,

Maybe I’m lost. It wouldn’t be the first time. But in the Adobe fonts I’ve worked over, c2sc maps existing full caps to small caps, and smcp maps lower case letters to small caps. I’m just assuming that InDesign “all small caps” applies both c2sc and smcp, since otherwise, you’d get caps & small caps whenever there were full caps in the text stream. On the rare occasion we need caps & small caps in the text, there is another ID feature that can be applied.

OK, if I use “all small caps” and either c2sc or smcp applies a different set of numbers, I’d guess they would be substituted in the ID file. I’ll confess I haven’t checked it out, because I always move such numbers to a stylistic set.

As to the contextual punctuation, I haven’t thought it through completely, but I’d imagine that, say, lowering an apostrophe in a small capped acronym when the subsequent (lower case) word also had an apostrophe (like “it’s”) would look odd. Again, if ID applies both c2sc and smcp, if a substitution occurs in either, it would be applied to the text stream, right?

I can’t remember the thread where Adam proposed a separate small cap font, but it was a good one. Initially I was against it — I thought we’d be back to the old days using when small caps in running text meant a font change. But I believe what came out of that thread was the separate font would be for display, and that makes sense — including all the bells & whistles.

Anybody have the link to that thread?

edit

I think with the growth of multi-script OT fonts, the default Small Caps size is going to be closer to between 10-20 percent larger than the lowercase to accommodate Cyrillic SC.

How about making just the Cyrillic small caps bigger — they are different characters, they can use different glyphs!

Q. Anybody have the link to that thread?
A. http://www.typophile.com/node/32455

There’s more than one “style” of small caps.

For instance, there is a traditional style where the small caps are x-height, and generously letterspaced (and the tabular old-style figures would be similarly spaced out).

There is also another look, where the small caps are bigger and tighter, and old-style figures too are closely fitted, and kerned.

A lot of it has to do with the typographer’s preference, and, from my perspective as a type designer, what kind of overall style I’m trying to create in the typeface.

So typographers really have to pore over their specimens and find the face with the size of small caps which can create the right “presence” for the job at hand.

I’m not going to make small cap versions of characters I don’t think will be used in an all-small-caps setting.
Really, if typographers want to have the whole character set (including all forms of punctuation and currency) for all-small-caps, they should just use full capitals, because in that situation, the text is likely to be quite separate from any upper-and-lower case setting.

***

Is there a real-world usage for currency symbols at small cap height?

***

Charles, if I’m putting small-cap-height lining figures in my “c2sc” feature, is this going to work out poorly for any of the acronyms/whatever in your 1,100 page book?

Charles —

I don’t think you’re lost. We have the same understanding of the basic implementation of {c2sc} and {smcp}.

Both Quark and InDesign apply both features when “All Small Caps” command is selected. For U&sc, (i.e., just {smcp}), Quark and InDesign differ: Quark has an OpenType menu item called, logically enough, Small Caps.

InDesign, however, does not. Ironicially, Adobe relies upon the Small Caps button on the Control palette or the Small Caps command in the Character palette. If the font contains a {smcp} OT layout feature, then that will be applied. If, on the other hand, the font is not OT or does not contain {smcp}, then faux small caps will be applied. Now, isn’t this sort of button/command just the kind of thing that many of us were trained never ever to use? It boggles my mind that Adobe chose to implement in this way, when Quark’s approach is more straightforward and logical.

I’m not going to argue with you about figures in {c2sc} and {smcp}. Upon further consideration, you’re right. Figures should probably be left to the figure features and determined separately.

Depending upon the feature order, though, it’s possible that any figure substitution in {c2sc} or {smcp} might conceivably be overridden by the figure features. But in principle, you’re probably right, the better approach is to leave figures out.

However, that still leaves the problem of small cap figures (i.e, lining figures at small cap height). If a type designer designs this third set of figures, how should they be implemented? I suppose that {c2sc} makes the most sense. But I can see how a typesetter might dislike not having some measure of control over this. Perhaps the features could be carefully ordered so that sc figs are applied by {c2sc} only when {lnum} is also active — that is to say the substitution would be something like sub one.lf by one.sc and ordered after the figure features. Something like that.

Or are you suggesting just sticking them in their own stylistic set?

Regarding punctuation, again, you make a good case for careful consideration of which punctuation marks, if any, deserve sc variants. I see now that perhaps you were responding more to some of Nick’s suggestions. I agree that quotes and apostrophe don’t need repositioning, nor period, comma, colon, semicolon and the like.

I think the likely candidates are really just parens, brackets, and braces. Perhaps question and exclam. These all lie outside words and can be easily excluded when selecting acronyms where they might not be desired, but included in longer text strings like lead-ins or subheads where they would make more sense.

But perhaps you disagree.

— K.

I think so, Nick. As I said, I never checked it out to make sure that “all small caps” applies *all* the replacements found in c2sc and smcp, but it seems to, since both cap & lc letters are changed to small caps. If there were any numbers, they too would be changed, & that would affect global S&R in the file.

A couple of notes:

First of all, my grumble would only apply to fonts that would be used for text, esp. text as found in books (a lot of text). Here’s the reason. If the graphic designer decides that all acronyms are to be set small caps, you globally search & replace them. You can be expected to visit anything in display, but not in text.

Why? Economics. In 1960, in the States, the charge for setting a page of type in a book was about $5.00. That’s roughly what it costs today — maybe a little less. In 1960, a Ford or Chevy car was about $2,000, and a typical house about $25,000. You know what they cost today. So, the price maintenance of composition has come about from (1) using author/publisher supplied files that are “editorially correct on disk”, (2) processing speed with computers & the size & speed of file storage media, and (3) some efficiencies in composition software. BTW, when I started setting type for books in 1980, the Z-80 chip was the hot number, and disk storage was a 256-K, hard-sectored 8-inch floppy disk. Cost for a page had risen to about $8.50. Of course, we keyed from the typescript.

In passing, since I & other compositors don’t look at all the text, what gives us the right to also claim to be “typographers”? OK. I spend a fair bit of time setting the min-ideal-max justification spacing. I keep notes in a *readme* file with each type family, but there will be some variance in what’s ideal, depending of measure, leading, and type size. Checking includes running out some test laser prints, since my eye can get fooled by the screen.

Then there is the kerning. When academic publishers & typesetters changed to InDesign, I got A LOT of calls about the terrible kerning. These calls were from both publishers and other typesetters; most used Quark, where kerning was external. For them, ID was a nightmare; you had to fix all the kerning. We’d always used TeX, where kerning was in the font, so I was use to remaking AFM files.

Some of us would also re-work the type itself, esp. with fonts where the thick-thin contrast in the letters was suited for letterpress, not offset printing.

Finally, we still take time with display type, just like the the guys who’s work is trying to get the consumer to part with hard-earned currency for a product they probably don’t need.

So I say that a “compositor” is more than a “typesetter,” and involves elements of “typographer.”

The “complete typographer” I suppose, would be accomplished in designing type, designing printed material, and setting it.

But since most of us aren’t that complete — I’m sure not — things work best when we understand the other guy’s problem and don’t make their job harder.

FWIW

Charles —

(We’re ping-ponging.)

Question for you: When formatting a text with various small caps, do you just use manual styling (albeit perhaps via S&R) or do you use semantically named character stylesheets? — for instance, a stylesheet named “text_acronym” and maybe another named “text_leadin” to retain some underlying semantic distinctions?

— K.

Charles, how many acronyms containing figures in your 1,100 page book?

Kent,

I must admit I was thinking more about comps in general . . . I doubt anyone works quite the way we do. We do all this sort of formatting in an InDesign-tagged-text file (Edit Pad Pro, in UTF-16), which lets us deal with a number of issues. All this is done before the files are first placed in InDesign.

I had to change the angle brackets to square brackets just to get it to display here, but our code for all small caps is

[ccase:Caps To Small Caps]Megan Benton[ccase:]

After all the hand coding, we run a pre-processing program, which adds some kerning. For example:

is professor[ck:-28] [ck:]of communication and adjunct professor[ck:-28] [ck:]of

shows a (negative) kern added in the string “r space o”

two goals.[ck:-55] [ck:]They[ck:-28] [ck:]could

shows a (negative) kern added in the string “period space T” and a kern between “y space c”

([ct:i]The Adventures of Don Chipote, or[ck:-36] [ck:]When Parrots Breast Fee[ck:100]d[ck:][ct:]).

shows, in addition, a positive kern added between an italic d followed by a roman close paren.

Etc.

Charles

Edit:

Nick,

Why would I want to visit them all to find out?

Well, it was a somewhat rhetorical question.

You indicated that a set of small-cap-height lining figures, included in the c2sc feature, would not be appropriate, as your implementation of “all small caps” for acronyms would be in a predominantly U&lc setting where oldstyle figures are the norm.

However, I’m saying that the instances where figures occur in acronymic text are extremely rare.

Therefore it is OK for me to include small-cap-height lining figures in the c2sc feature, because the “folio” usage is a style of setting where such figures are commonly required, for page numbers.

Therefore it is OK for me to include small-cap-height lining figures in the c2sc feature, because the “folio” usage is a style of setting where such figures are commonly required, for page numbers.

Hmmm. Well, us comps are use to having to work around font designers, so it is “OK” for you to do whatever you want.

BTW, the 1100 page book I’m setting specifies small caps for the running feet, and OS figs for the folios, and the RF & folios are on the same line. Of course, the RF are 9-pt small caps, letterspaced 100 units, the folios are 9.5 & not letterspaced, so there is handwork anyway. And once you’ve set up one set of master pages for RF-folios . . .

BTW2, I’d count running heads/feet as “display”

Charles —

I see.

I’m familiar with InDesign tags. Although I admit that I always found the syntax of Indd tagging more convoluted than the Quark tag syntax that I first learned. We even had our editors & copyeditors trained to include paragraph-level Quark tagging for basic semantic structuring in manuscript — @AH, @BH, etc. But the Indd syntax was too foreign and “geeky” for them to transition to, so originally I wrote some simple BBEdit S&R routines to translate MSS.

My thought behind semantic-named character stylesheets (in addition to paragraph stylesheets of course) is that it provides essentially a structural, rather than presentational, markup for character-level styling and gets closer to allowing more flexible repurposing of the content — closer to an XML approach. Which is taking us way off topic, I know. ;-)

Do any of your customers ever ask you to post-process to XML yet? Just curious.

So, for instance, you could have

<cstyle:bio-name>Megan Benton<cstyle:>

and a header definition

<dcs:bio-name=<ccase:Caps To Small Caps><ctk:40>>

for instance.

Thanks for the glimpse into your processing of special kerning situations. Good food for thought.

— K.

BTW, you can enter angle brackets by using the HTML entity names, so that they don’t get processed as code:

&lt; = “lessthan” (left angle bracket);

&gt; = “greaterthan” (right angle bracket).

With apologies to Sebastian for hijacking his thread . . .

Kent,

Just a few have asked for post-processing to XML. Having said that, we don’t try to make a set of files conform to their specific DTD’s, that’s their business. Many publisher *say* they want XML, but few know what to do with such files in any case.

And most of them just want a graphic representation. What will eventually make sense is XML coupled with something like TEI-Lite. For example, one person’s “extract” (displayed quoted matter) is another persons run-in quote. Quote marks themselves can be used to signal different things, as can a *single quote right* — an apostrophe, or a glottal stop — etc. etc. But these are things for editorial to put in before composition, not properly the domain of the typesetter.

I need to add that my business partner Larry Tseng is responsible for the programming that implements a lot of the techniques we use. I work with him on what is wanted, and he finds a way to make it happen. He also knows more about color management (includes grayscale) than anyone else I know. Preparing & handling images has become a large portion of bookwork, even in academic publishing.

Any more & we’ll have to start a different thread.

us comps are use to having to work around font designers, so it is “OK” for you to do whatever you want.

It’s a little unfair to characterize font designers as wilfully intractable.
One tries to make the fonts as useful as possible, but they must satisfy various constituencies, not just a homogenous “us comps”.

The problem here is, what is the best style of figures for all-small-caps: lining or old-style?

IMO, old style figures with all-small-caps is quaint, like using roman figures with italic letters, because that’s all you’ve got.

But if it’s what the majority of users want, it would certainly be easier for me to never provide small-cap-height lining figures as an option.

But if it’s what the majority of users want, it would certainly be easier for me to never provide small-cap-height lining figures as an option.

That’s unfair. I wouldn’t presume to speak for the entire community of comps. I’ll run the risk of speaking for book comps, but that’s just one subsection.

Having said that, I’ll stick to my guns. For fonts intended for setting text, until the layout programs offer transparent choices, I would prefer to see small caps intended to be used with text included in the font. The OT features c2sc and smcp should not be encumbered with numbers, punctuation, or even brackets & parens. If you want to put these as “extras” in stylistic sets, fine. Also, I would prefer to have a set of display small caps in a separate font — like all display type — and will defer to the type designer as to what to include.

And having said that, If there are any comps left who set advertisements, posters, playbills, etc. etc. from designer’s layouts, I don’t know what they would say.

Charles — Thanks for your insights regarding the questions I raised. I’ll let it lie for now and the thread can stay focused on small caps.

The more I think about it, the more the question of what to include in c2sc/smcp really depends upon where the type designer thinks the type will end up getting used. This always going to involve a degree of guess work.

But for the broadest possible usability, at least as far as book text composition goes, the more separable and controllable the various alternates, the better I suppose.

> The problem here is, what is the best style of figures for all-small-caps: lining or old-style?

Behind this question is another of Who’s in the best position to decide what style is best — Is it the type designer or the typographer? Perhaps the domain of the type designer is What are the best forms for any of these options — lining, oldstyle, hybrid, small cap lining, et al. — and Which to include/provide, but not When should they be used. Secondarily, how best to make them accessible. But also, how to keep the font itself flexible enough for the typographer/compositor to make choices.

Perhaps coupling figures with small caps is well-intentioned but misguided. Do we type designers want to take a “Microsoft Word” approach of imposing our stylistic assumptions on our users? Especially if software provides no easy way to circumvent them.

— K.

Perhaps coupling figures with small caps is well-intentioned but misguided.

There has to be a default.

The small cap “which figures” problem is no different than for lower case—i.e. should the default be oldstyle or lining figures?
The layout application makes it easy to switch, and keep it “programable” in style sheets.

I would say, make things appropriate to the typeface genre, and consistent within the typeface: i.e. if the lower case default is lining figures, then the all-small-caps (c2sc) default should also be lining figures. Does that make sense?

All the foundry now has to do, as was mentioned earlier in the thread, IIRC, is to code the font features so that when “all small caps” and “old style” figures are both selected, the numbers change from a c2sc default of lining figures, to oldstyle (Or vice versa.)

The OT features c2sc and smcp should not be encumbered with numbers, punctuation, or even brackets & parens.

Yes, smcp should be unencumbered, but not c2sc, which, as part of all-small-caps, is a fundamentally useful, legitimate and rich style, and not something that should be consigned to the graveyard of stylistic sets.

Charles, isn’t your problem rare and hypothetical? i.e. it only occurs when text that is to be set in small caps has letters that surround a number or punctuation. Surely in those circumstances the typographer can make the appropriate selection before applying the feature?