lack of small-cap height lining numerals

jlt's picture

Can anyone tell me why so many of the new "all inclusive" pro opentype faces from a variety of foundries are being released with old-style numerals as part of the small-caps set?

I understand that there is a certain stylistic flair to using non-lining numerals with old style caps on title pages and in other decorative settings. However, it seems to me that small-cap heigh lining numerals are far more useful as part of the sc set/selection; 9 times out of 10, those will be what a typesetter wants when he or she is setting small cap text.

The most ironic part is that a few of these faces HAVE such numerals in the font, but just not assigned to the small cap set!

I assume I am missing something and everybody else in the world works very differently than I or any of the typesetters and designers I know. That's the only explanation I can come up with.

JLT

twardoch's picture

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.

Nick Shinn's picture

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:

twardoch's picture

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.

Christopher Slye's picture

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.)

Nick Shinn's picture

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."

William Berkson's picture

>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.

Christopher Slye's picture

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.

hrant's picture

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

Nick Shinn's picture

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.

Nick Shinn's picture

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.

hrant's picture

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

Christopher Slye's picture

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?

Nick Shinn's picture

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"?

Choz Cunningham's picture

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

twardoch's picture

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

Nick Shinn's picture

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...

hrant's picture

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

hhp

twardoch's picture

> 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.

Nick Shinn's picture

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".

hrant's picture

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

Nick Shinn's picture

Thanks Hrant, props for championing the idea.

Christopher Slye's picture

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!

twardoch's picture

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

Nick Shinn's picture

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.

riccard0's picture

A list of typefaces with small-cap height numerals:
http://typophile.com/node/70865

Syndicate content Syndicate content