How would the features be named? If the SC feature has OSFs as default, how to get the lining SC figs to be included? One of them has to be default with small caps....

I think it’s ridiculous that SC has OsF as default. We only think it makes sense, I think, because they’ve been packaged that way for so long - many decades. But I think that was a marketing decision; certainly, even the metal typesetters I know pick those numerals and the SC apart when they distribute the type into a case, and don’t use them side by side very often - especially not at text sizes.

I’m assuming that the current custom to attach OsF to SC is simply a carryover from this, and from here it seems somewhat ridiculous - OTF sets should be organized around use, not arbitrary convention.

—-

jlt : http://www.hewnandhammered.com : rnrmf!

From a design point of view I agree with you Josh. I don’t know the technical side well enough to understand the limitations.

I’ll second the desire to have smallcap height figures. Dolly, for instance, has gorgeous smallcap lining figures. (Although it isn’t opentype so it is off-topic.)

Old style figures are near the small cap height normally. So they would suit the small caps better than lining figures.

Aren’t small cap height lining numerals a new thing?

Also are they actually useful? How often do you need to set numerals with small caps outside of lower case text, where the OSF should work well?

William: I am constantly called upon to use numerals with small caps in technical manuals, textbooks and government documents. I would say that I need them perhaps 50% as often as I need OsF, and just as often as I need full-height lining numerals.

I do not think they are necessarily a new invention, as some of the first Italian faces to have small caps as part of the metal family included them (as far as I remember; I think several cuts of Bodoni included them). They are fantastically useful, imho, but even more than that, not having them when you need them is tremendously disruptive.

—-

jlt : http://www.hewnandhammered.com : rnrmf!

Ok, let me ask another question then. Are OSF that are monospaced actually useful?

Maybe sticking monospaced lining figures at smallcap height in that slot—which exists in InDesign—would work and serve all practical needs. Then you could just formulate a character style with both small caps and lining cap-height figures. How does that sound?

So replace monospaced OSFs with the preferred lining SC figs? Is there anyone on here who uses tabular OSFs?

I have never heard of using tabular small caps figures. If I were to do tabular work, I would just use the standard figures in a smaller point size if needed—but I have never needed.

ChrisL

Linotype’s done a few type families with these. Avenir Next has them. A small display family I’m finishing up also has them. Most of the time, whether these are designed comes from whether the designer sees them as important or not. I also think that this is sort of a “new” (but good) thing. I seem to remember old, “classic” typography mixing SC with OsFs all the time. In fact, I never had even heard about SC figures before I came to Linotype. But maybe I was just living under a tree or something…

Yes, Carl put my question it more succinctly.

As Chris has never heard of it, Joshua, can you show us come examples of where the lining small cap height numerals are much better?

Paul Rand used tabular OSF in some old Westinghouse annual reports.

ChrisL

Lining smallcap height proportional is different than lining smallcap height tabular. It’s the tabular that I have not seen. I have actually designed 2 faces with smallcap height proportional figures.

ChrisL

>It’s the tabular that I have not seen.

Oh, I see. The question is really: What is useful? and Can you fit it into the existing programs so it is accessible?

Here’s the Adobe insight on this one:
— (You’re right that) oldstyle figures are the traditional form to be used with small caps, and that’s what Adobe does in our fonts’ small-cap layout features.
— Any font developer who wishes to can easily add lining figures of small-cap height to their fonts’ small-cap layout features
— Font developers can also add such figures as a stand-alone feature (a stylistic set)*. Both approaches are well-supported in InDesign & Illustrator.

* or “hook” the glyphs directly to the features ’smcp’ and ’c2sc’

Clearly a lot of us are unfamiliar with small-cap tabular (monospaced) figs. But Tiff’s question, and one I would like to pursue is: Does anyone use tabular Oldstyle figures? Because it would be convenient to put the “new” tabular small cap figures in those slots, if nobody’s using them.

Sorry, need to be more specific. I do not need tabular sc-height figures! In the books and government reports I usually set, proportional but lining small cap height numerals would be fine.

Yes, if you like, I can find some examples of work I’ve done that would have benefited from such figures. And Carl, please do not delay anything you are working on because of me! I’m thinking out loud about little things that might take advantage of the OTF technology and make my work a bit easier.

Miguel, is there a way for a USER to override the stylistic sets? Custom sets, maybe? That way, one face I work with regularly, which does indeed have small cap height proportional lining numerals (from here on referred to at SCHPLN, pronounced “askdjadlkjhsdkjfh”) but which does not have them as the default character set for small caps, would be able to be used in the way I’m wishing for.

Wow, that was a good run-on sentence.

Anyway. Basically, here’s all I wanted to say:

I would like to see more lining small cap proportional numerals in text faces, and I would like to see them as the default figure style in the small cap stylistic set, and barring that I’d like a way to customize stylistic sets so that I can use them with small caps without changing sets/fonts/whatever.

—-

jlt : http://www.hewnandhammered.com : rnrmf!

A couple of things:

- people do use tabular OsF. I’ve used them in real work. They’re not as common as the other permutations. More importantly, hijacking a feature for some other usage is generally a dubious choice, IMO.

- although InDesign supports stylistic sets, AFAIK neither Illustrator nor QuarkXPress does, as yet.

- jlt: No stylistic sets are on by default. The way you override a stylistic set is to turn it (back) off. Stylistic sets are a group of 20 features, numbered 1-20. Small caps are not a stylistic set (unless you wish to make them so, but I can’t see why).

Oops, gotta run and go get some stitches out. Maybe somebody else can explain stylistic sets better to Joshua. Or maybe just reading the right section of the OpenType spec will help: http://www.microsoft.com/typography/OTSPEC/features_pt.htm#ssxx

Cheers,

T

> Are OSF that are monospaced actually useful?

All kinds of things are useful.
And fixed-width OS numerals can certainly look awesome:

hhp

> Miguel, is there a way for a USER to override the stylistic sets? Custom sets, maybe?

You mean, as a user you want to change the behavior of a particular stylistic set of a given released font?* The answer is no.

* let’s suppose that a font’s stylistic set 1 changes the double-story ’a’ to a single-story ’a’, and open ’g’ to a binocular ’g’; and you only want ’a’ to change.

“And fixed-width OS numerals can certainly look awesome:”

But what about the USER’s needs, Hrant? This is design, not art! ; )

I just want lining numerals that match my small caps, that’s all. nothing fancy... not OsF, not tabular. Just lining numerals that don’t look out of place with small caps.

—-

jlt : http://www.hewnandhammered.com : rnrmf!

My wishlist would be for OTF sets to have names defined by the type designer instead of numbers. This would make what the set does be more apparent to the user. There could be a stylistic set called “Small Cap Lining figures” or what vere descrptive name.

ChrisL

My wishlist would be for OTF sets to have names defined by the type designer instead of numbers. This would make what the set does be more apparent to the user. There could be a stylistic set called “Small Cap Lining figures” or what vere descrptive name.

I believe the thinking on this is that it is impractical to expect this to make any more sense to non-English users, unless the type designer interprets these descriptions into every language which the font might be used in.

Carl: Very. Funny. Ha. Ha.

BTW, what’s ironic about the rarity of fixed-width OS nums is that they’re actually easier to make look nice* than proportional OS nums! I have to think that people naively migrated Regularity from the horizontal dimension (where it can very often make sense) to the vertical dimension (where it typically backfires, except for all-caps setting).

* FYI, all your base are belong to us.

hhp

“designer interprets these descriptions into every language which the font might be used in.”

Bundle Babelfish with FontLab? :-)

ChrisL

To respond to something Dezcom posted above: font families’ tabular figures should all have the same tabular width in all weights. This is very important when setting financials in annual reports, where font weights, underlines, and alignments are actually dictated by SEC standards. So, to simply use a smaller point size would result in a narrower setting, breaking the tabularity. (Also useful in timetables, listings, etc, etc.)

In my experience, it’s a challenge to get an OsF “2” looking good. The other glyphs are all pretty self-evident.

FWIW, the Apex New family has small cap lining numerals which are turned on with the small caps, in both proportional and tabular versions.

> it’s a challenge to get an OsF “2” looking good.

I’ve long said that the OS “2” should ascend. And there’s one font that
has actually has that, and it’s not obscure either. Yes, this is a test.

hhp

I believe the thinking on this is that it is impractical to expect this to make any more sense to non-English users, unless the type designer interprets these descriptions into every language which the font might be used in.

Really? I assumed it was an mistake. Since “Stylistic Set 1” doesn’t mean anything in any language other than English, nor does “Default Ligatures”, I’m not buying it. The inability to custom-name custom-use fields is probably my very least favorite aspect of OpenType. It makes no sense. English is the most international language, and there is other components of a font that support that.There are not specific fields for for every language for every other aspect of a font file’s data (although there are some, which are customizable and optional). Additionally, not only is English used for the default names of existing explicit OT features, it is used for the standard glyph names, as well other aspects of fontery.

I think it would be a lot better idea to make the sets named (perhaps with a “Stylistic Set #:” prefix) and let the designers do the designing and naming in the file. A stylistic set being named in non-English would still assist me, speaking English, as I would learn to recognize foreign words if I really came across them a lot, and to speed up recognition of already known features of a font. Its a far more workable solution than expecting designers to put out a lengthy guide to each feature-rich font’s intracacies. Then, what, translate that into several dozen tongues? And make the consumer track that added separate file? Yucky.

I think more likely, this was an oversight, low priority at creation, out-of-budget or a mistake. Since the current folk explanation are dubious, I hope when OT grows up, this will be one of several small refinements. So, here’s my suggestion to the logical successor in today’s technology trends, back-compatible ExtensibleOpenType. Or .XOT for short. :)

Choz Cunningham
!Exclamachine Type Foundry
The Snark

”...impractical to expect this to make any more sense to non-English users, unless the type designer interprets these descriptions into every language...”

There could also be a list of common features that could be selected from a menu in the language of the designer. These common names could then be translated via lookup tables to the default language of the user’s computer. This may not be perfect but it sure breats the hell out of vague stylistic set numbers which communicate nothing. There could even be a script to look at what is in the OTF feature code and give a rough translation into the host language. If class names were standardized, this would be much simpler.

ChrisL

Currently, no names for any features are encoded in the font; only the four-letter code is. Because the features have static meanings, the application developer can translate them into whatever languages they need, along with the rest of their user interface.

I don’t have any particular objection to a system that would supplement the existing four-letter codes for stylistic sets with desriptive text. The ’name’ table is in fact designed to do a range of strange things that would easily encompass this. It would be the responsibility of the font designer to decide how many languages to translate this descriptive text into, and if they didn’t cover a given language, it would be up to the application to determine a fallback or simply display something generic like “stylistic set #4” - which is no worse than what we have today.

If somebody wants to go to the work of creating a formal proposal in the appropriate language for the OpenType and/or Open Font Format specs, they should feel free. That’s your next step, if you want to do something about what you see as a problem....

Cheers,

T

“If somebody wants to go to the work of creating a formal proposal in the appropriate language for the OpenType and/or Open Font Format specs, they should feel free.”

Thomas, What is the appropriate language and format? Can anyone make such a proposal? To whom would I send it?

ChrisL

PS: I started a new thread on feature sets to address this concept.

http://typophile.com/node/29648

JLT— I have them in the regular weight of Feijoa…

—K

Aside from the use of stylistic sets for this, MS says they are eager to hear suggestions for new tags, and will handle all the technical bits if they approve. Not sure of how often they do this, or if they have that all sewn up without interacting with Adobe. There is also a way to register features as not Adobe/MS; Emigre has done this. Nevertheless, to mimic the existing feature names, I suggest <scln> for Small Capitals (sized) Lining Figures. Perhaps there should be a <sctn> for Small Capitals (sized) Text Figures, as well, so that one or the other could be included, complimenting the default choice.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

I just got around to reading this thread. I thought I would mention one more thing about tabular old style figures: One thing that has been interesting to watch is Robert Slimbach’s evolving “design strategy” (to coin a phrase) for these glyphs.

When we began to convert our fonts to OpenType, the Adobe Originals which had old style figures to begin with (which then typically had tabular lining and proportional old style figures) all were upgraded to the full set of four number styles (adding fitted lining and tabular old style figures). We struggled for a while to adapt the existing old style figures to the tabular widths, and Robert or someone else would tweak a number or two to improve their looks. Robert, along with everyone else, would think of old style figures as “naturally” proportional. It seemed strange and awkward to try to shoehorn them into tabular widths.

Today, Robert simply designs all the figures in his new typefaces to be tabular. He’s found that the numbers, both lining and old style, work with tabular widths quite well if they’re conceived that way to begin with. It’s much easier to design them that way and then re-fit them for their proportionally-spaced companions, rather than going the other direction.

> He’s found that the numbers, both lining and old style, work with
> tabular widths quite well if they’re conceived that way to begin with.

Maybe he’s found what he wanted to find? Just like with his non-trapping.
The numeral one does not work well in a tabular scheme, period.

Anyway, now that we know what Robert Robert Robert thinks, what do you think?

hhp

Hrant, you’re like one of those people who listens to a radio station they hate and then complains about it. If you’re not interested in anything which originates with Robert, then just skip the post.

Here’s the deal: I’ve worked with Robert quite a while. He shares some of his ideas with me, and sometimes they make an impression. Since Robert is not one to participate in Typophile threads and the like, I occasionally will pass on something I’ve learned or observed from him if I think it’s relevant. I can tell that you’re not interested in hearing about it, but it’s not going to stop, so what’s the point of being a grouch about it?

Anyway, back to the topic at hand:

Maybe he’s found what he wanted to find? Just like with his non-trapping. The numeral one does not work well in a tabular scheme, period.

Duh. The point was that, if one has a font in which tabular numbers will be included, it saves time and effort to design them on tabular widths first, and then make adjustments for proportional versions, rather than the other way around. Obviously the ’one’ will always be problematic, so the choice in solving that problem becomes either to not make tabular figures at all, or consider better ways to design them.

Anyway, now that we know what Robert Robert Robert thinks, what do you think?

Robert has far more experience with designing fonts than I do, so it seemed to me that his approach might be more valuable — but since you asked, it makes sense to me. It’s not that it’s such an original or ingenious idea, but I find it interesting that one can become so accustomed to this notion that old style figures are inherently proportional, and exacerbate the challenge of fitting them to tabular widths. By changing one’s habits, one can save some labor by approaching them from a different direction.

This is not a radio station. Which is lucky for me, since I don’t listen to radio.

> If you’re not interested in anything which originates with Robert

I’m sorry, I didn’t realize you originate with Robert.
Sounds more extreme than the name of one of his fonts.

I’m interested in your opinion, not least because you’re here. I’m also interested in the opinions of people who are not here, but when they’re not here to elaborate and/or defend, it’s kind of annoying when it’s presented as authoritative. Yes, one shouldn’t shoot the messenger, but shouting at the messenger can be therapeutic.

> Obviously the ‘one’ will always be problematic

I’m glad you’ve now corrected “He’s found that the numbers, both lining and old style, work with tabular widths quite well if they’re conceived that way to begin with.” which is something pretty specific you claimed above, and which was specifically what I was countering above. The numeral one (you know, the most frequently ocurring numeral) does NOT end up working “quite well” tabularly, no matter where you start what.

So now I’m not sure: what does Robert -really- think again?

> his approach might be more valuable

It is, but:
1) Yours is not worthless.
2) Again, you’re here, and that’s valuable.

> I find it interesting that one can become so accustomed to
> this notion that old style figures are inherently proportional

Indeed. Please re-read my second post in this thread.

hhp

BTW, no takers on the quiz in my third post?

hhp

Hrant, I know you’ve been through all this with practically everyone else here, but just for the record, I don’t think your approach enhances or enriches the discussion here. I do not understand why you choose to be gratuitously argumentative when the meaning is reasonably clear. For example:

I’m sorry, I didn’t realize you originate with Robert.

I don’t. Obviously, the idea I was describing originated with Robert.

The numeral one (you know, the most frequently occurring numeral) does NOT end up working “quite well” tabularly, no matter where you start...

To fixate on the problems of a particular number is a valid discussion to have, but a distraction from my original point. Numbers are a set, and I am talking about considering the success of the set overall — just like deciding whether an alphabet works “quite well” without fixating on some particular letter, the shape of which one is stuck with. “Quite well” is relative and subjective, so despite ’one’ being problematic, one can consider the overall set of tabular numbers successful to some degree or another and fairly apply that description, I believe. If you don’t agree, that’s fine.

So now I’m not sure: what does Robert -really- think again?

As I said, I believe Robert is happier with tabular numbers when they are designed first for tabular widths and adapted for proportional spacing. “Quite well” is my characterization, but I believe it’s fair to say he’s “satisfied” and considers it an improvement over the previous practice of designing the old style numerals proportionally to start. I am not interested in becoming a middleman for Robert on this board, so I kindly ask that you consider the overall idea, which I believe is pretty clear without analyzing every word.

... it’s kind of annoying when it’s presented as authoritative.

I don’t see how it’s presented as more “authoritative” than anything else anyone says here. Really, I’m just trying to pitch in and contribute an interesting idea or two here. That you find this all so provocative is far beyond my intention, and also tiring.

Again, you’re here, and that’s valuable.

What I suppose will continue to be a problem for you is that I have spent the last nine years working here directly with Robert. It will be difficult for me to talk about type without occasionally referring to things he’s said or done. If you are getting the impression that Robert is somehow hiding behind me or using me as a mouthpiece, I assure it’s not so. I’m just sharing my experience.

And elaborate defense to avoid admitting a mistake
is what’s “gratuitously argumentative” in my book.

hhp

Christopher, as one of my pet peeves is the conflation of argument and quarrelling, please allow me some some definitional clarification:

conversation = talk about any topic, often for the pleasure of it, changing topics at will.

discussion = conversation that sticks to one topic

argument = 1. a reason given for or against a claim concerning a particular topic. 2. a discussion containing such reasons.

quarrel = a personal dispute involving the alleging faults or wrongdoing of the other person.

insult = attack on the other person’s character.

To me Hrant’s arguing is a positive feature of his participation, as it is thought-provoking and interesting. He often has interesting points to make. And that is a valuable contribution even when they are mistaken points—which I think they are half the time.

In my view, what makes Hrant’s manners barbarous is that instead of sticking to argument proper, he regularly resorts to insults and turns the argument into a quarrel.

This is to the point where I am resolved to avoid discussion with Hrant.

Hrant is a thoughtful and interesting fellow who is often the life of the party on Typophile. But he is also so relentlessly quarrelsome that he regularly spoils the party. An unusual combination—the one and only hhp.

You can have small-cap lining numerals in your font, but there is no need to hijack any feature for that. You just implement them the way they should be done, i.e. in the “smcp” feature (where else?)

I’ve posted an appropriate code snippet here:
http://typophile.com/node/29648/#comment-170126

A.

Yes, only barbarians don’t use press releases to manipulate people and cover up the truth. To remain civilized, one must ignore the fact that one is dealing with actual people, and focus on dead-end theorizing, with a smile. A cocktail party. Or a remote-controlled war. That is what ensures the status quo, the maintaining of Traditional Values.

hhp

(where else?)

Small lining figures have to be made anyway, for arbitrary fractions, and for superior and inferior figures, so it’s not much work to do a set that sit on the baseline and line with the small caps, and include them in the “all small caps” feature — but the “caps with small caps” feature should use proportional OSF, shouldn’t it?

I thought the point of the OP was that you couldn’t put small lining and small text figures in the same smcp?

Choz Cunningham
!Exclamachine Type Foundry
The Snark

There are two separate OpenType features:

c2sc — this is in the “third level” InDesign menu, and only works for OT fonts.
smcp — this in in the “second level” InD menu, and produces faux small caps if there are no true small caps in the font, and proper (caps-with-)small-caps if there is the smcp feature in the OT font.

So if the foundry doesn’t include any figures in the smcp feature, the user will get the default figures; however, the foundry may have lining figures as default, and include OSF figures in the smcp feature. Whatever, if the foundry includes small-cap-height lining figures in the c2sc feature, then the user will get the 3rd style I showed above.

And elaborate defense to avoid admitting a mistake is what’s “gratuitously argumentative” in my book.

Hrant, I was trying to explain the substance of my original point, which you have consistently ignored in favor of your own tangential arguments — the pertinence of which I have yet to be convinced. This is the second thread in which I have tried to do so, and by now I am fairly well convinced I am wasting my time.

Nick,

it is indeed an interesting suggestion to associate old-style numerals with “smcp” (since this usually means mixed uppercase and smallcaps settings) while associating the lining smallcap figures with “c2sc” (because usually, this means that “c2sc”+”smcp” are activated together to get all-smallcap setting).

The code snippet I posted in the other thread could be extended accordingly.

A.

It’s an interesting idea, but personally I would be inclined to keep it simpler for the user and have both ’smcp’ and ’c2sc’ apply the small cap figures, and then have the various number features (’lnum’, ’onum’) change the style further if desired. It seems like it would adapt to the application UI’s a little more naturally.

Chris, I wouldn’t privilege the functionality of a UI over typographic functionality. What you are proposing as a default for ’smcp’ (centre example) is not very useful.

With regards to Joshua’s and Tiffany’s assessments of what the standard figures for use with small caps should be, based on usage situations, it’s debatable but certainly varied. IMO the primary usage of small caps, across the board, is in Caps-with-small-caps settings. This applies to what I consider to be the two main instances: (i) With extended U&lc text, either for paragraph lead-ins (see example), or for highlighted names. Personally, I prefer all small caps in these situations, but my taste is somewhat old-fashioned and probably in the minority. In these mixed settings, OSF is surely the norm — although I would be interested in seeing some of Joshua’s typography. (ii) A complete setting in Caps-with-small caps, such as a subheading on a package; again, OSF seem to harmonize better in this more “decorative” situation.

In the second place, on a purely empirical analysis, surely caps-with-small-caps has a visual similarity with OSF — both mainly occupy an “x-height”, with the occasional extender. This is why I believe the centre setting above doesn’t look as good as the other two, because the figures lack presence. So, to keep it simple for the user, it makes sense to pair the figure and SC styles on the basis of formal harmony, rather than arbitrarily assign one figure style to both SC variants.

In the third place, both the OpenType feature code, smcp, and Adobe’s UI implementation of it, “small caps” are incorrect and misleading, They would be more accurately named as “cwsc” and “caps with small caps”. By the same token c2sc should be “alsc” (all small caps).

Also, Adobe’s UI implementation of the four OT figure styles (lnum, pnum, onum, tnum) is problematic, presupposing a set of four combinations of these. But what if a font has only lining figures? The OSF options still appear in the OT menu. (Quark does a more logical job of implementing figure styles in its UI.) So again, it’s not a good idea to put a less than perfect UI in the driver’s seat. And I hope that Thomas will agree, as his philosophy of “the fonts will survive” is part of my reasoning here.

Nick,

“c2sc” is *NOT* all small caps. “c2sc” is small caps from capitals. It only transforms uppercase to small caps, leaving the lowercase untouched. The Adobe UI checkbox “All small caps” turns on “c2sc” and “smcp” at the same time.

OpenType Layout features can specify what gets substituted but they cannot necessarily specify what does NOT get substituted by the means of other features being applied at the same time. Therefore, a name such as “cwsc” (“caps with small caps”) would promise something it couldn’t deliver. It would promise the user that he gets both caps and small caps. However, if the user applies “c2sc” and “smcp”/”cwsc” at the same time (as the Adobe UI element “All small caps” does), then the result would be all small caps. So the caps wouldn’t be there anymore though one of the feature names would suggest that they are there.

Short: each feature should mind its own field.

The only reasonable alternative for “smcp” would be “l2sc” (lowercase to small caps), but it doesn’t really matter much since the four-letter OpenType Layout feature codes are not actually designed to be exposed in user interfaces.

A.

Thanks for the clarification Adam.

each feature should mind its own field.

I agree, and applications should also, with appropriate naming.

Here’s my ideal menu format for figures:

And here’s the menu for small caps:

Nick,

1. A separate “small caps lining” switch for figures would presume that there is a separate feature for small caps figures. Currently, there is none, and I don’t think registering one would be a good idea. If you do, what do you do if you want to include a set of petite caps lining figures to accompany your petite caps (“pcap”)? Register a yet another feature?

2. I think “Caps with small caps” can be shortened to “Small caps”, and that’s what Adobe did. Linguistically, “caps with small caps” sounds awkward, especially if translated into other languages (German: “Großbuchstaben mit Kapitälchen” or “Versalien mit Kapitälchen”). This becomes far too long for a UI entry.

3. I do sympathize with the complaint regarding the UI for the basic figure styles. In Apple’s UI, the alignment and the proportion are separated. On the other hand, having multiple selections always introduces complexity to the flow. Your UI is two-tier — Adobe certainly did not want to produce a “tree structure”. I for my part think Adobe did a reasonable job in compromising flexibility and usability.

4. Your UI sketch seems to have extra checkboxes next to the categories and checkboxes next to the entries in the categories. What is supposed to happen if a user clicks on the box “Lining”? Will “Tabular” be automatically selected? What will happen if the user selects “Tabular” in the “Lining” group? Why are there two ways of selecting “Tabular Lining” — through “Lining” and through “Tabular” in the “Lining” group. Or is “Lining” not a clickable item? If so, why does it have a checkbox?

In my work as FontLab product manager, I get to discuss and optimize user interfaces a lot, and have spent some time studying usability issues. I must admit that your menu is not so good, usability-wise. Sometimes, it’s necessary to step out of the “designer’s mind” or the “engineer’s mind” and to adopt a “user’s mind”. I believe this is what Adobe did in the Creative Suite apps.

A.

I wouldn’t privilege the functionality of a UI over typographic functionality.

Sorry, I didn’t mean to say that — and I wasn’t thinking of any particular UI (e.g. InDesign). I only meant that it made more sense to me to have numbers which are designed to match the small caps in both small caps features, and that that would benefit the interface by being a natural place for the user to look for them (since there is not a feature specifically for such numbers). So, in other words, putting glyphs in the appropriate feature should make finding and using them easier.

Having such numbers in both smcp and c2sc doesn’t seem so important to me (maybe just c2sc is enough), but I wouldn’t want to put one kind of number in c2sc and another in smcp. I think that would be getting a little complicated.

Notice, by the way, that in my suggestion, if you had some text to which you had already applied old style figures, applying small caps to some text containing numbers would get you small caps and old style figures (because the onum feature would be superceding smcp).

In any case, I am still not so sure it’s a good idea in general to have number substitutions happening in small caps features. (And by “not so sure,” I mean that I think there are decent arguments on both sides of the issue.)

1. A separate “small caps lining” switch for figures would presume that there is a separate feature for small caps figures.

Not necessarily. This would simply activate the smcp feature, and presumably the foundry would have placed lining small cap figures in the feature. If they had not put any figures in the feature, the default figures, or whatever other figures had been previously specified, would remain, and no change would occur. There are many precedents for clicking on a feature and nothing happening. However, if the foundry had put OSF in the small caps feature, it wouldn’t work properly — but why would they, if they were familiar with a UI implementation like this?

But a separate feature for small cap lining figures is a great idea, and would probably please Joshua, Tiffany, et al.

2. I think “Caps with small caps” can be shortened to “Small caps”,

Sure, the full “Caps with small caps” is cumbersome, but it is correct, and makes perfect sense as the alternative to “All small caps”.

Your UI is two-tier — Adobe certainly did not want to produce a “tree structure”.

I don’t think having a two-tier implementation is bad, in fact, it exposes the logic behind the choices the user can make. Anyway, both tiers are visible on the same palette, and the default would be “pre-selected”, which I don’t show in my diagram.

What is supposed to happen if a user clicks on the box “Lining”? Will “Tabular” be automatically selected?

Whatever is the default will already be showing. So for a standard font, “Lining” will be checked, and “Tabular” underneath it. Then if the user wants proportional OSF, click on Old Style, and Proportional under that, and the previous selections toggle off.

Sometimes, it’s necessary to step out of the “designer’s mind” or the “engineer’s mind” and to adopt a “user’s mind”. I believe this is what Adobe did in the Creative Suite apps.

Adam, I know it’s hard to imagine how an interface works from a static diagram, but my scheme is perfectly viable, usability-wise. As an art director who has been a page-layout application user for 18 years, both Quark and now InDesign for 4 years, I would say I qualify for “user’s mind”.

I agree with you that the CS apps are in general user-friendly, but with the exception of OpenType implementation, which is a dog’s breakfast — inconsistent across applications, and split between two buried levels of palette in InDesign. Consider that on the first level there are both “small caps” and “superscript” — one implements the correct OT feature if it’s in the font (but doesn’t let you know whether or not), the other gives you faux, and also doesn’t tell you. By trying to please too hard, the UI design is compromised.

Really, a warning should pop up when users click on faux effects. You know, like the ones in FontLab that say “You are trying to apply a dangerous operation...” in bold face every time I import metrics into a font.

“Warning: you are attempting to apply a faux typographic effect that may cause discerning readers to wince.”

>OpenType implementation ...is a dog’s breakfast — inconsistent across applications, and split between two buried levels of palette in InDesign.

Right on, Nick. Everything on one layer, with defaults checked.

If we had the whole of open type formatting options on one dialogue box similar to the one he shows above it would be a definite improvement. Dialogue boxes can be big, if they are clear.

Whatever is the default will already be showing. So for a standard font, “Lining” will be checked, and “Tabular” underneath it.

But the app isn’t going to know what the default is (unless it’s picking something for itself). The so-called default figures are whatever glyph is named “one,” “two,” etc. If a font has proportional old style figures with these names, the app will see these as “default,” but has no way of knowing if they are tabular, proportional, or whatever. It has to apply a layout feature before it can “know” what it has.

BTW, you guys should stop using “tabular” to mean fixed-width, because some people use “tabular” to mean lining, and it’s best to stay away from such people. :-)

hhp

Chris, couldn’t the app figure out what the default is (tab/prop, lining/osf) from the information in the lnum, pnum, onum, and tnum classes?

If “one” appears in both the tnum and lnum classes, then the default figures must be tabular lining.

Hrant, “tabular” is the term used in the OpenType feature code definitions, and in the CS interfaces.
It is the standard usage, whether we like it or not.

OT is one thing, personal communication among people who should know better is another. “Latin serif” is also a “standard term”, for wedge serifs, but anybody using it (like Jim Parkinson, in the description for Azuza*) is asking for trouble.

* http://www.myfonts.com/fonts/parkinson/azuza/

hhp

Chris, couldn’t the app figure out what the default is (tab/prop, lining/osf) from the information in the lnum, pnum, onum, and tnum classes?
If “one” appears in both the tnum and lnum classes, then the default figures must be tabular lining.

That’s asking a lot of the app and the font, I think. The font would have to use particular numbers (e.g. ’one’) in those features (which it often will, but isn’t required to), and the app would have to figure it all out and hope the features are configured in a predictable way.

Constraining the features to satisfy the app’s UI is bad, right?

I don’t see the problem.
If a font has OpenType figure features, then the basice figures “zero”, “one”, etc., will be included in the appropriate figure classes, and the app should be able to determine the default from that. It’s the definitions of the classes which are calling the shots, not the application. The categorization of figures into OpenType classes becomes the issue, not the application’s interpretation.

In fact, why can’t InDesign do this already, so that the default figure style is accurately signified, rather than just called “default figure style”?

In fact, why can’t InDesign do this already, so that the default figure style is accurately signified, rather than just called “default figure style”?

I imagine the answer has something to do with backwards compatibility. Anything like you suggest should probably be incorporated manually at design time.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

Nick,

> Not necessarily. This would simply activate the smcp
> feature, and presumably the foundry would have
> placed lining smallcap figures in the feature.

But this would be absurd: I check on the “smallcap figures” switch and all my text (including numbers) turns into smallcaps. Since this is how the feature typically works, its place is under “smallcaps” and not “smallcap figures”.

However, for the Latin or Default languagesystems, the principle of OpenType is that lookups associated with a certain feature are executed on the entire portion of text that is in the scope of the operation, period (e.g. on the entire selection or on all the text covered by a style that employs a feature).

This is why the format is simple and successful, and why there are many implementations of it. If you start asking for special behaviors, guessing around and artificial intelligence being applied, you’re asking for trouble.

Christopher,

> In any case, I am still not so sure it’s a good idea in
> general to have number substitutions happening in small
> caps features. (And by “not so sure,” I mean that
> I think there are decent arguments on both sides of the
> issue.)

What exactly are the arguments against?

Glyph case conversion features (“case”, “smcp”, “c2sc”, “pcap”, “c2pc”) have their own specifics. The general idea is to allow conversion between different cases of letters and supporting glyphs. The cases envisioned by OpenType are: lowercase, uppercase, smallcaps, petite caps.

There are several kinds of glyphs that are subject to case conversion. They all exist in various scripts, such as Latin, Cyrillic, Greek and other writing systems that differentiate letter cases.

There are four classes of letters:

* LC: “text letters”, i.e. lowercase letters (including accented letters of various kinds),
* UC: uppercase letters,
* SC: smallcap letters,
* PC: petite cap letters (rather uncommon, of course),

There are also — at least potentially — other kinds of supplementary characters that may have different glyph forms depending on which letter case they are used with:

* punctuation characters (hyphens, parantheses, brackets, dashes, exclamation marks, question marks, apostrophes, quotation marks etc.),
* free-standing diacritic marks (spacing and combining),
* numerals,
* currency symbols,
* mathematical operators and other characters.

Each of the supplementary characters can, potentially, have separate glyph forms (or at least positioning) that correspond to each of the aforementioned case classes (LC, UC, SC, PC).

For lowercase-to-uppercase conversion, the general agreement is that the conversion of *letter* case should be done by the application itself, based on Unicode case conversion information.

Therefore, the “case” feature should only involve supplementary glyphs that differ in appearance depending on whether they’re used in uppercase-only or in mixed-case (i.e. primarily lowercase) text. However, it is up to the type designer to include or not include specific glyphs in that conversion. In other words, an “All uppercase” or “All capitals” UI operation should perform the Unicode case conversion (on the visual level) *and* should apply the “case” feature — this is in fact what happens in Adobe InDesign.

In most fonts, the default type of numbers (numerals, figures), associated with the Unicode codepoints for European numerals, is lining. Usually, lining numerals are suitable for setting UC, and to some extent, LC. Traditionally, “oldstyle” numerals were used for LC setting but these days, it is no longer so. Therefore, the “onum” feature allows the user to switch from the default (typically lining) figures to oldstyle numerals.

However, in some fonts such as the Microsoft ClearType fonts (e.g. Constantia), the default form of the numerals is oldstyle. These numerals go well with the default text case (which is LC) but don’t work at all with UC text. Of course there is an “lnum” feature that allows the user to switch from oldstyle numerals to lining numerals on a discretionary basis, but in a well-made font, switching the case from lowercase to uppercase should also automatically trigger the switch of numerals to corresponding forms (just like it would for parantheses, hyphens, dashes, currency symbols etc.) Therefore, a substitution of the default (oldstyle) numerals with uppercase (lining) numerals should happen not only in the “lnum” feature (which is for the user’s *discretionary* choice) but also in the “case” feature (which governs the more general case change). Microsoft has not done it and when I pointed this out to John Hudson and Geraldine Wade, they agreed that this is something at least to be considered in a revision.

oldstyle and lining figures are both two kinds of text figures that go along lowercase or mixed-case text. We agree on that. To choose between these two kinds of figures, we have “onum” and “lnum”. Fine. The lining figures *may happen* to be a suitable set to go along all-caps setting, but do not necessarily have to. In most typefaces, lining numerals are shorter than caps. In an OpenType font, one could imagine having a yet separate set of lining figures, taller than the text lining figures and truly aligned to the top of uppercase letters. This set would be inserted through the “case” feature. Even a typeface like Matthew Carter’s Georgia that only has one set of unified hybrid (semi-oldstyle) text figures could use a second set of uppercase figures. These would be substituted using the “case” feature, just like other case-sensitive supplementary characters.

I firmly believe that visual case conversion *must* involve numerals as well — there is no reason to exclude them, just like you wouldn’t exclude the endash, the parantheses or the dollar sign.

For the two cases: smallcaps and petite caps, the case conversion is only performed on the glyph level and there is no external reference material (such as the Unicode case conversion rules). Therefore, both the conversion of letters and the supplementary characters must happen in the font. In the “smcp” and “pcap” features, only the lowercase letters should be converted to the small or petite caps, respectively, while uppercase letters should be left untouched. Conversely, in the “c2sc” and “p2sc” features, only uppercase letters should be converted while the lowercase letters should be untouched.

But what about the supplementary characters? Of course, all of them (punctuation, currency symbols, *and* numerals) should be covered if they are designed, and that regardless of whether the feature converts lowercase or uppercase into the smallcaps or petite caps. This means that both “smcp” and “c2sc” should convert lowercase numerals into numerals suitable for smallcaps setting.

Here, we come to the conclusion. The type designer should not think in terms “Do I include hybrid or lining or oldstyle numerals in my font?” This is the wrong question to ask yourself. The right question is: what kinds of numerals (and other supplementary characters) do I need to include in my font *depending on their function*? The visual appearance of the figures is a secondary question, and a design question only.

I would classify figures into five *functional* categories:
* LCF: Text / lowercase figures — figures to be used in running text, i.e. typically appearing in all-lowercase or mixed-case context.
* UCF: All-caps / Uppercase figures — figures to be used in all-caps settings such as headlines.
* SCF: (If your font contains smallcaps) smallcaps figures — figures to be used in smallcaps settings.
* PCF: (If your font contains petite caps) Petite-caps figures — figures to be used in petite-caps settings.
* MTF: Mathematical and tabular figures — figures to be used in mathematical / scientific / financial context, without letters.

*Each* of these groups may have one or several stylistic variants. All figures to be used in text can be proportional. There can be two sets of LCF (lining and oldstyle) or just one (hybrid). SCF and PCF can also come in two kinds, lining and oldstyle (lining for all-smallcaps setting while oldstyle for caps-and-smallcaps setting), or just in one kind (either hybrid or lining). MTF are usually monospace but can be just lining or also have an oldstyle set. Finally, UCF are typically lining and proportional.

The actual question of how many figure sets do I need to design for my font only comes after this analysis. Leaving PCF aside for the time being, let’s concentrate on the four functional categories of figures: LCF, UCF, SCF and MTF. Let’s imagine that you want to have both lining and oldstyle flavors of proportional LCF. And let’s imagine that for SCF you want two kinds of figures, one that works in all-smallcap settings (lining) and the other that works in mixed caps-and-smallcaps settings (oldstyle). For MTF, you want a lining and an oldstyle set.

So you might end up having:

* TWO SETS OF LCF:

three.lnum_tnum (monospaced lining) — gets inserted in the features: “lnum” and “tnum”:
— feature lnum { sub three.onum_pnum by three.lnum_pnum; } lnum;
— feature pnum { sub three.lnum_tnum by three.lnum_pnum; } pnum;

three.onum_pnum (proportional oldstyle) — gets inserted in the features: “onum” and “pnum”:
— feature onum { sub three.lnum_pnum by three.onum_pnum; } onum;
— feature pnum { sub three.onum_tnum by three.onum_pnum; } pnum;

* TWO SETS OF SCF:

three.lnum_smcp (smallcap lining) — gets inserted in the features: “lnum” and “c2sc”:
— feature lnum { sub three.onum_smcp by three.lnum_smcp; } lnum;
— feature c2sc { sub [three.lnum_tnum three.lnum_pnum three.onum_tnum three.onum_pnum] by three.lnum_smcp; } c2sc;

three.onum_smcp (smallcap oldstyle) — gets inserted in the features: “onum” and “smcp”:
— feature onum { sub three.lnum_smcp by three.onum_smcp; } onum;
— feature smcp { sub [three.lnum_tnum three.lnum_pnum three.onum_tnum three.onum_pnum] by three.onum_smcp; } smcp;

* ONE SET OF UCF:

three.case (uppercase) — gets inserted in the feature “case”, replacing most or all other figure kinds

* TWO SETS OF MTF:

three.lnum_tnum (monospaced lining) — gets inserted in the features: “lnum” and “tnum”:
— feature lnum { sub three.onum_tnum by three.lnum_tnum; } lnum;
— feature tnum { sub three.lnum_pnum by three.lnum_tnum; } tnum;

three.onum_tnum (monospaced oldstyle) — gets inserted in the features: “onum” and “tnum”:
— feature onum { sub three.lnum_tnum by three.onum_tnum; } onum;
— feature tnum { sub three.onum_pnum by three.onum_tnum; } tnum;

Now, it is up to you to decide if you want to rationalize some of the sets away. For example, you could decide not to have monospaced oldstyle figures (three.onum_tnum). You could decide not to have oldstyle smallcap figures (three.onum_smcp). This leaves you with:

three.lnum_pnum (proportional lining) — gets inserted in the features: “lnum” and “pnum”
three.onum_pnum (proportional oldstyle) — gets inserted in the feature “onum” only
three.lnum_smcp (smallcap lining) — gets inserted in the features: “c2sc” and “smcp”
three.case (uppercase) — gets inserted in the feature “case”
three.lnum_tnum (monospaced lining) — gets inserted in the features: “lnum” and “tnum”

Further on, you could decide that you don’t need an extra set of smallcap figures but instead, smallcap settings will always be associated with your proportional oldstyle LCF. This does away with three.lnum_smcp. You could also decide that your proportional lining LCF are good enough to serve as UCF. This leaves you with:

three.lnum_pnum (proportional lining) — gets inserted in the features: “lnum”, “pnum” and “case”
three.onum_pnum (proportional oldstyle) — gets inserted in the features: “onum”, “c2sc” and “smcp”
three.lnum_tnum (monospaced lining) — gets inserted in the features: “lnum” and “tnum”

You might also decide that you only need two sets of figures: lining tabular (that serve as lining LCF, as UCF and as MTF) and proportional oldstyle (that serve as oldstyle LCF and as SCF). Hence:

three.onum_pnum (proportional oldstyle) — gets inserted in the features: “onum”, “pnum”, “c2sc” and “smcp”
three.lnum_tnum (monospaced lining) — gets inserted in the features: “lnum”, “tnum” and “case”

Finally, you could decide to have just one set of figures only, monospaced hybrid, and use them everywhere: LCF, UCF, SCF and MTF. But regardless of which degree of the design simplification you choose, you should always be aware of the various *functions* that your figures should serve. The more different kinds of figures you include in your font, the more their design can be custom-tailored to those specific functions. The less figure sets you include, the more compromise you need to work into your design.

Of course, in the cases elaborated above, “three” is only used as an example, I’m talking about the whole zero-nine set. Also, one of the sets (typically lnum_tnum or onum_tnum or onum_pnum or lnum_pnum) would serve as the default set of glyphs for the European figures. That particular set would not use any glyphname suffix, i.e. it’d be just “three”, and would be associated with the appropriate Unicode codepoints).

The bottomline is, figures should be associated with both the figure style selection features (lnum, onum, pnum, tnum), as well as with case conversion features (case, c2sc, smcp, pcap, p2sc), appropriately.

Regards,
Adam

But this would be absurd: I check on the “smallcap figures” switch and all my text (including numbers) turns into smallcaps.

Well, if you are going to use small cap figures, you probably intend to use them with small caps! Surely the absurdity would be to use small cap figures with upper or lower case.

In any event, “special behaviour” (selecting only the characters you want changed, not the entire text block) is not as you say an anomaly within OpenType, as many figure features require it — fractions and superiors/inferiors for instance. And the Ordinals feature does in fact require “artificial intelligence”, in the form of contextual rules, to make it apply correctly.

This means that both “smcp” and “c2sc” should convert lowercase numerals into numerals suitable for smallcaps setting.

Right. I like the way you have assigned “Small cap lining figures” to the “c2sc” feature, a brilliant solution to the problem! It depends on the application applying both c2sc and smcp to implement “all small caps”, which is quite logical.

In an OpenType font, one could imagine having a yet separate set of lining figures, taller than the text lining figures and truly aligned to the top of uppercase letters.

That’s what I’ve done in Austin. Here are the figure sets, as per your scheme, Adam. One day I may yet finish the typeface and release it...

An ascending OS “2”! Awesome. Where did you get the idea?

hhp

> Well, if you are going to use small cap figures,
> you probably intend to use them with small caps!
> Surely the absurdity would be to use small cap
> figures with upper or lower case.

What I meant is that the user would not expect that an UI operation in the figures section would do anything to the letters. :)

A.

Where did you get the idea?

I’d seen it in Perpetua many years ago, and first appropriated it for Fontesque in 1993. I subsequently tried it on several types, but it never really worked, so I didn’t implement it again until Austin, where it seemed OK—and necessary, given the large ball terminal in the Scotch Modern genre, which wouldn’t fit comfortably into a two with OSF “x-height”.

Yes, Gill’s work is the only (other) place I’ve seen it.* It’s great to see a
contemporary designer do it - I myself have been a fan of the idea since
the late 90s (before noticing Gill’s stuff actually).

* And that of course is the answer to my quiz
in this thread (see my last post of 11/17).

hhp

Thanks Hrant, props for championing the idea.

What exactly are the arguments against [putting figure substitutions in small cap features]?

Here’s one: Both lining and old style figures have a history of being used with small caps. One can argue for one’s own preferences, but I don’t think that any particular style can be considered objectively correct. Since there are a number of OpenType features to handle (popular) figure styles, one could say that a user can use one of those features to access the figure style they want, rather than having the small cap feature do it for them. (Smallcap-style punctuation is a little different, since there is no separate layout feature for it — so it seems appropriate to include these non-alphabetic glyphs along with the letters.)

What vexes me about the small cap figure style is that the above argument doesn’t apply so convincingly. Still, I am left with the overarching idea that figure style, whatever it might be, should be handled as a separate choice.

For Garamond Premier Pro, we changed our approach a little from preceding fonts and drifted slightly toward this idea. Only alphabetic substitutions are made in ’smcp’, whereas ’c2sc’ changes letters, punctuation, and numbers (to old style). The idea with this is that in mixed-case settings (e.g. ’smcp’), old style figures do not necessarily work better, and smallcap punctuation (e.g. questiondown.sc, ampersand.sc) can actually look strange. Of course there’s nothing preventing a user from applying old style figures to a mixed-case setting if that’s what they want.

Adam, I think your treatise makes a convincing case for its position, and at the very least is a thorough illustration of its ideas. It doesn’t yet convince me that there are no alternative philosophies.

One of the things I like about OpenType features is that they allow much latitude for a designer to express their ideas and preferences through the choices they make in the features while still remaining “legal” in the OpenType sense. I think this thread is exposing a lot of choices that many might not have been thinking about, so I am glad we’re talking about it!

Christopher,

by no means I’d say my view is the only one valid — of course I do consider my view a very good one ;) The design of OpenType Layout features involves both technical and usability considerations. My personal view is always to optimize/maximize usability (which is a subjective criterion, of course) without invalidating the technical considerations. So while I’m against “hacking” features, I’m all for pushing the boundaries to the greatest extent.

The case conversion features are usually more accessible in application UIs (e.g. in InDesign “all caps” and “small caps” are right in the Character palette rather than in the OpenType submenu) and more comprehensible to users, while the figure style selection features are much more specialty-oriented. Things like “all caps” or “small caps” are understandable to a large number of users while “oldstyle tabular” is not necessarily so. I think upon selecting the letter case, the typeface should present itself in the “most optimal” way to the user, including selecting the best figure style. The user should always have the ability to override that preset.

If case conversion lookups (case, smcp, c2sc, pcap, c2pc) are placed earlier in the font than the discretionary figure style selection lookups (lnum, onum, pnum, tnum), the user always will have the ability to override the “case-default” figure style. But I think it’s still useful to have different figure styles become default depending on the letter case. This is basically where my “treatise” leads.

Best,
Adam

upon selecting the letter case, the typeface should present itself in the “most optimal” way

Yes, because, the optimality of any figure style for a particular feature depends to an extent on the typeface. One key factor in this suitability is the role of “x”-height. Consider that the height of small caps varies with typeface; usually it is slightly larger than lower case x-height, sometimes the same size or quite a bit larger. Between the different x-heights of Sc and lc, the old-style figures may correspond to either, which certainly affects how they perform in an all-small cap setting. In some faces where there is a noticeable difference between Sc height and OSF x-height, such as Caslon (above), that creates a quaint effect which may be desirable in the type designer’s opinion, or perhaps not, which has a bearing on what is considered to be the best choice for default SC figures—OSF or lining. At any rate, that kind of decision should, I feel, reside with the foundry.