You might be right. I'll test it out tomorrow.
I think wider smallcaps are a metal legacy (where you simply used a smaller size, and everything was wider).
I think you're mistaken about the method of printing small caps in the letterpress era.
I also think you should refine your test string, since /T/M/F/ just happen to have relatively small counters or semi-enclosed spaces. But anyway, here's your test in my font-in-progress, Millennial, FWIW.
I think the lower line (true small caps) fit better with the lowercase, don't you?
@Hrant: Of course small capitals are larger because they have to work smaller.
Most of what has been developed and learned in centuries of lead type setting is not strictly related to the printing technology. You can see how small capitals work better with a wider proportions by decreasing the size of your own typeface. In fact, you can see they work better even if you are writing by hand.
Not that'd I'd expect anyone to go to all the work, but theoretically...
The small caps needed for phonetics should be drawn up special. They also have a Unicode code point, unlike small caps generally. They need to blend into the general lower-case letters, and be kerned with other phonetic & lower case sorts, but probably not against each other.
The small caps to be switched in by an OT feature probably should be the ones used in running text, for acronyms & abbreviations. Depending on your school of thought, that has implications for height & width. Kerning is only needed against each other and punctuation, & maybe full caps, though that's another issue (used in some legal styles like "Harvard Blue," etc.).
The "Display" small caps are those intended for use in a subhead, chapter number, that sort of thing. Maybe even a TABLE or FIGURE head... It can be argued that these do not have to mix with lower case letters, and can have different height/width properties. They probably have to work with full capitals. One way to deal with them would be to use a separate font, as Adam Twardoch has mooted from time to time. Or perhaps a stylistic set.
The compositor can do some work by using different character styles. Any needed differences between the "display" & "running text" will likely be small, and the layout program's scaling for a few percentages points change is one way to go. It isn't ideal for several reasons -- the contrast of the characters will change a little (stem, fine lines), as will the weight generally if you use more than about 5 percent. Kerning will be maintained within the set of small caps the character style is applied to, but not with characters not included the character style, with punctuation being the most common problem.
Then, I suppose if you're being really pure, except for the phonetics which have a Unicode index, you need them both mapped from capitals and mapped from lower case (c2sc and smcp). [Edit: FWIW, I don't think this is worthwhile generally. In fact, with fonts where it's legal to modify them, I've been known to go in & take out the lower-case mapping. There is always some handwork in using text extracted from a pdf, and 99.9 percent of the time, any odd full caps are going to occur where you expect them to.]
Just some of the issues that can come up with small caps in the use of type.
Personally, I wouldn't bother to do all that in a font. Too much work for too little gain -- esp. since the designers who select what typeface will be used in a document will get bored with one font family fairly quickly, and move on.
Craig, a lot depends on how small caps are set in combo with U&lc.
For old-style types in which the small caps are “petite”, very close to x-height, it was customary to letter space them, they are capitals, after all. (They appeared a lot like old style figures—which are tabular—with a lot of inherent sidebearing space.) By the same token, small caps that are a lot larger than x-height may be set tight, like the lower case.
1. Petite small caps, normal spacing
2. Petite small caps, letter spaced
3. Small caps, normal spacing
In the top face, which is something of an old style, setting #2 is preferable.
In the bottom face, a didone, #3 is preferable, because letterspacing doesn’t suit this kind of didone (unless it is an all cap setting, with lots of spacing).
And remember: Real typographers never set caps with small caps!
I agree, but am reluctant to anger all the practitioners of the legal profession. What if I'm falsely accused of a crime?
(&BTW, I know some who'd argue that real typographers never use bold...)
How would you set an acronym at the beginning of a sentence (or are small-capped acronyms also something that real typographers don't do)?
Nick, why didn't you build more generous spacing into the petite caps in the oldstyle font?
Depends on what world you live in. In my world (books) anything the editor feels trumps whatever the designer or typesetter feels. And if the editor defers, both the book designer and compositor trump the type designer... Now, just who is the "typographer" in that long sequence?
But in general, I say if you use them, let the chips fall where they may. Anything else gets you into a terrible tangle. & I'd tend to say use them in text, but not in U&lc display, esp. if initial caps are used in the displayed material.
With acronyms, a lot depends on the typeface and the genre of job it’s being used in.
One also has to consider what the ﬁgures are like.
It makes sense to match the default look of small caps to that of All Caps (with “cpsp” if it’s in the font).
That way, it’s a benchmark that typographers can relate to, adding tracking as necessary.
For instance, in a “title page” usage mixing All Caps with All Small Caps, you want to have a consistent letterspacing when the typographer adds, say, 100 units of tracking throughout.
@Nick: You remember how I love Richler (especially the regular), right? :-)
So you’re doing it on purpose! LOL
It will be published soon.
That is very good! :-)
I had hoped to have it out by now, but after I decided to add Greek and Cyrillic, I added small caps for them, and then WGL4, and it’s taking for ever to do the specimens. I did chicken out on Hebrew, though.
Golly, even Cyrillic?
Thanks for mentioning WGL4, Nick. Is there some specific reason to add it?
I always loved the regular version, the italic is very good but more conventional.
WGL4 is a recognized standard for Pan-European fonts, with Latin, Greek and Cyrillic.
I’ve never supported it in a typeface before, as I thought the pattern pieces were a waste of time, but WTF, they were easy to draw and they’re the same for every font.
The pattern pieces (line and box draw characters) were not intended to be included in all WGL4 fonts: they are only included in the spec for console fonts. This used to be clearer in early documentation of WGL4, which distinguished between the core set and the optional inclusions. Unfortunately, more recent documentation has omitted this distinction; I'm not sure why.
There really is no reason to include line and box draw characters in anything but a monospaced font, since they are entirely dependent on such spacing in order to work correctly. So, for example, of the ClearType fonts, which were based around the WGL4 set -- with some additions -- only Consolas supports these characters.
But can I say my font is WGL4 compliant if it doesn’t have the line and box characters?
It probably depends on to whom you are making the claim. Some years ago, at a Unicode conference, I was sitting next to Michel Suignard from Microsoft, who was primarily resposible for defining the WGL4 set, and I recall that he agreed with my interpretation of the then published spec that the line and box draw characters were optional, outside of the core set. But one possible reason for the removal of the core/optional distinction in the documentation might be that software developers want to be certain about what characters a font contains if it claims WGL4 support. An equivocal option would be to claim that a font provides 'WGL4 language set support'.
I suppose I could make an equivocal claim, but having drawn the line and box characters, I can put them in every “Pan-European” font now, so I might as well.
I think certain potential customers will be reassured to know that the full WGL4 character set is supported.
This reminds me of another thread ongoing at the moment, about parentheses not belonging to any particular typeface.
Forgive my ignorance, but which is the use of those pattern pieces?
Thanks, sorry for the spamming. :-)
Strange that the combining diacritical marks are not a part of WGL4. Doesn't that put Microsoft & Unicode a bit at odds? My sense of consortium's preference is that characters with accents as precomposed glyphs are an unfortunate relic.
We get in a number of manuscripts these days where even simple ones like an a with an acute are typed as two characters, U+0061 followed by U+0301.
Strange that the combining diacritical marks are not a part of WGL4. Doesn't that put Microsoft & Unicode a bit at odds?
No. WGL4 is a superset of 8-bit encodings for European languages using the Latin, Greek and Cyrillic scripts, plus a few additions. Since it deliberately only supports those languages that do not require combining marks, it omits them. It is also worth noting that WGL4 is pretty old now, and it's been almost a decade since it was defined as the procurement requirement for any work I've done for Microsoft. We extended even those ClearType fonts that are not Office core fonts to support Vietnamese and some symbol and extra numeric glyphs not in WGL4.
Which Microsoft would automatically map to the precomposed character in the font cmap during display.
I generally use the IBM extended Universal (or Unified) Glyph List (which is undoubtedly descended from a common source as WGL4) as the basis of character support if I want to expand coverage outside Latin-1. That's mostly because the first fonts I designed were targeted at OS/2 users, of course. Since then I've just kept the habit because I figure it's as good a system as any.
I don't mean that I support the whole thing, just that I use it as a rough guideline for "I should really plan to support these characters" up to a certain cut-off (usually about the 383 mark, although I often include the 505-529 region as well).
It used to be divided into a few language-specific versions. TypeTool (and presumably FontLab) includes obsolete mapping tables for them; I created an updated one for the full UGL which I use.
We extended even those ClearType fonts that are not Office core fonts to support Vietnamese and some symbol and extra numeric glyphs not in WGL4.
Sorry to belabor this, but it seems to me that the community beneﬁts from having a specially named encoding for Pan-European coverage; it’s a shorthand which lets users know that what they’re getting will do the job, validated by Microsoft.
John, is there such a thing as a current Microsoft standard? Perhaps as Nick suggests, a WGL5? Perhaps a type community generated standard would be more appropriate, if such a thing could ever be agreed upon...
WGL4 stands as a pretty good basis for pan-European language support.
Microsoft's expanding procurement requirements reflect their own market priorities, which might not be everyone else's market priorities, especially not every font foundry's priorities. How many font makers are selling end user licenses in Vietnam or Kyrgyzstan? There are a few things that can be picked up from examining the Win7/8 release versions of e.g. Constantia. For example, if you are making Greek fonts -- even Monotonic ones -- you might want to consider including the numeric koppa character: apparently there was enough of a call for this (it is used as a symbol in legal documents) for Microsoft to add it to all their fonts with Greek support.