Superior numbers have a higher baseline than superior letters. Why?

Superior numbers are used to annotate text, while superior letters--as in your examples for Monsieur, Mademoiselle and Saint--are used as abbreviations with a stylistic flair. Superior text should line up at the tops of the letters with uppercase letters. Superior numbers are placed higher, I suspect, so that they can be more readily seen, since their function is not to continue the text, but to mark it.

The misplaced period, however is a mystery to me...someone didn't have their thinking cap on when they did this.

But the superior numbers might need punctuation, too. What if a word references more that one footnote (e.g., success ¹,²), or has decimal footnotes (e.g., success ¹.²)? Both situations are typographically common, and should be available, shouldn't they?

What if the numbers came down to the letters' baseline? Would they lose their readily-seeable quality?

Or could the letters' baseline be raised up in this function, so that they could be used in footnotes (e.g., "1a" as a footnote). Could abbreviations be referenced by another feature, so that both numbers and letters could have proper punctuation?

Why? Because people who design typefaces aren't the ones that have to use them. I keep saying that a working compositor has to be able to modify fonts in order to do his/her work; the imagination of authors knows little bounds.

> Superior numbers are used to annotate text, while
> superior letters—as in your examples for Monsieur,
> Mademoiselle and Saint—are used as abbreviations
> with a stylistic flair.

This is a very simplistic and naiive view. I have just returned from Warsaw where I spoke with some typesetters who hate the fact that superscript letters and superscript figures have different baselines because in scientific publishing, both letters and figures are used to reference footnotes. In more complex scientific books, you often have two parallel kinds of footnotes, one being referenced with superscript numbers, the other being references with superscript letters.

I strongly believe that one needs four kinds of small-sized "alphabets" in a font:
a) bottom visibly below baseline
b) bottom equal with baseline
c) top equal with caps height or ascender line
d) top visibly above the caps height or ascender line

These small-sized alphabets should ideally include complete sets of figures, letters and puncuation.

Unfortunately, the OpenType specification is extremely messy. It provides two features for small-sized characters that are located at the bottom ("sinf" for the "a" set and "subs" for the "b" set) but only one, extremely ambiguous feature for small-sized characters that are located at the top ("sups"). The "sups" feature tries to unifies glyphs that are used for completely different purpose. Its description reads:

"Replaces lining or oldstyle figures with superior figures (primarily for footnote indication), and replaces lowercase letters with superior letters (primarily for abbreviated French titles)."

The denotations "superior figures" and "superior letters" are vague. The designers of the OpenType spec failed to recognize that the typesetting practice needs both figures and letters is the "d" set form (placed above the the ascender/caps height line), which are used to denote footnotes, and also needs letters in the "c" set that are aligned at the top of caps height/ascender line, or sometimes even located below.

In addition, the OpenType spec defines the "ordn", "numr" and "dnom" features that have somewhat similar purposes.

French, Spanish and Latin languages often makes use of elevated small-sized glyphs within the text. The French titles (Mssr), the Latin ordinals (2o for secundo), the French ordinals (7éme) all require for elevanted small-sized glyphs that visibly belong to the text, so they are located at the top or even slightly below the caps height. This has NOTHING to do with the small-sized superscript glyphs (both figures and letters) used in footnote references or mathematical expressions. It escapes me why there is a "sups/subs" feature pair intended for textual use but there is only one "sinf" feature intended for scientific use. A "ssup" feature paired with "sinf" and representing the "d" set should have been be defined in the OpenType spec years ago instead of overloading the "sups" feature with two distinctly different-purpose uses. The problem that Dan touched on is clearly an exemplification of that.

I think the textual use of the "sups" feature should be deprecated and moved to a separate feature. Either a new feature should be registered, or the use should be moved to another feature, e.g. the "ordn" feature that should be implemented in a simplified way.

Below is the recommendation that I can make to the font developers:

1. Scientific subscript glyphs ("a" set)

1.1. Design a full set of small-sized glyphs (figures, uppercase and lowercase English letters, punctuation, even accented letters) that are placed below the baseline (e.g. so that the vertical centre of the scientific inferior "x" is just above the the baseline). Use the glyph name suffix ".sinf" for them, e.g. "one.sinf", "a.sinf" etc.

1.2. Define a class "sinf1" with the basic forms that correspond to these glyphs (i.e. "one", "a" etc.) and a class "sinf2" with the .sinf glyphs.

1.3. Define the "sinf" feature:

feature sinf {
sub @sinf1 by @sinf2;
} sinf;

These glyphs can be also used as part of the afrc ("nut fraction") feature.

2. Text subscript glyphs ("b" set)

2.1. Design a full set of small-sized glyphs (figures, uppercase and lowercase English letters, punctuation, even accented letters) that are placed ON the baseline. Use the glyph name suffix ".subs" for them, e.g. "one.subs", "a.subs" etc. These glyphs may be slightly larger than the scientific subscript glyphs.

2.2. Define a class "subs1" with the basic forms that correspond to these glyphs (i.e. "one", "a" etc.) and a class "subs2" with the .subs glyphs.

2.3. Define the "subs" feature:

feature subs {
lookup subs1 {
sub @subs1 by @subs2;
} subs1;
} subs;

These glyphs can be also used as denominators in the dnom feature

feature dnom {
lookup subs1;
} dnom;

and as part of the frac feature.

3. Text superscript glyphs ("c" set)

3.1. Design a full set of small-sized glyphs (figures, uppercase and lowercase English letters, punctuation, even accented letters) that are of the same size as the text subscript glyphs, placed so that the top of the "h" is at the the ascender line or the caps height. Use the glyph name suffix ".ordn" for them, e.g. "one.ordn", "a.ordn" etc.

3.2. Define a class "ordn1" with the basic forms that correspond to these glyphs (i.e. "one", "a" etc.) and a class "ordn2" with the .sinf glyphs.

3.3. Define the "ordn" feature without using any contextual lookups:

feature ordn {
lookup ordn1 {
sub @ordn1 by @ordn2;
} ordn1;
} ordn;

These glyphs can be also used as numerators in the numr feature

feature numr {
lookup ordn1;
} numr;

and in the frac feature.

4. Scientific superscript glyphs ("d" set)

3.1. Design a full set of small-sized glyphs (figures, uppercase and lowercase English letters, punctuation, even accented letters) of the same size as the sinf glyphs, placed so that the vertical centre of the scientific superior "h" is slightly below the caps height. Use the glyph name suffix ".sups" for them, e.g. "one.sups", "a.sups" etc.

3.2. Define a class "sups1" with the basic forms that correspond to these glyphs (i.e. "one", "a" etc.) and a class "sups2" with the .sups glyphs.

3.3. Define the "sups" feature:

feature sups {
sub @sups1 by @sups2;
} sups;

These glyphs can also be used in the afrc feature.

5. Map the text and scientific variants as stylistic alternates and sets for each other:

feature ss01 {
sub @sups2 by @ordn2;
sub @subs2 by @sinf2;
} ss01;

feature ss02 {
sub @ordn2 by @sups2;
sub @sinf2 by @subs2;
} ss02;

feature salt {
sub @sups2 by @ordn2;
sub @subs2 by @sinf2;
sub @ordn2 by @sups2;
sub @sinf2 by @subs2;
} salt;

-- Adam

Thank you Adam, I think this article should be stored in the wiki.

BTW, if group shares the same glyphs it should be possible to use
the pos command to move the glyphs up and down instead of creating new glyphs.

pos [glyphs] (0 80 0 0); right?

Hi Dan,

I think size and positioning also varies from typeface to typeface, and foundry to foundry. Is your sample representative of other typefaces?

Hallo Herr Twardoch,

this is a nice solution. But I feel uncomfortable about using ssXX features for this.
The definitions for sups/sinf and numr/dnom are unfortunate indeed, they completely confuse text and mathematical contexts. Is the subs feature (with a "b") supported by applications right now? Also, I cannot remember having seen it in any font.

As to size and positioning, are different sets of superior/inferior numerals really a solution? I think, only in case that true mathematical superior/inferior features have been defined.
I have in mind another aspect. Someone told me he prefers mathematical superiors which are a bit larger than those used to indicate footnotes in text. So, I would suggest to modulate these details, size and positioning, by using character styles in the layout applications. (Similarly, styles can address typographers' preferences for larger or smaller SCs in all small caps setting ...)
Speaking as a type designer: I am convinced that it is my job to care for, and anticipate, as many typographic contexts as possible, and am upset when I find out that others don't do their job properly. But speaking as a typographer: There are things that I want to care for myself. Using character styles is the easiest way.

My personal conclusion so far, with the features currently supported in mind, is: adjust numerals and characters for text context, so as footnote indices first of all. Real mathematical setting is a special issue which might require special fonts because even well equipped OTFs don't have all glyphs necessary.

And I wonder if numr/dnom better be kicked out of fonts. frac does not need them.

Karsten

But the superior numbers might need punctuation, too. What if a word references more that one footnote (e.g., success ¹,²), or has decimal footnotes (e.g., success ¹.²)? Both situations are typographically common, and should be available, shouldn’t they?

Naïvely and simplisticly, I think you solve the problem as best you can, depending on the program you're using. If it's a word-processing program, type the numbers-with-punctuation, then naïvely and simplisticly format them as superscript. In a page composition program, you could use the actual superscript characters, then naïvely and simplisticly baseline-shift the punctuation up. Or not...

Naïvely and simplisticly…

Isn't OpenType supposed to save users these work-a-rounds?

From a practical point of view, I think this situation would seem to push fonts in two different directions.

Firstly, I think that what Adam has proposed is spot on, and I have found myself heading in that direction, as I added more and more characters to superior and inferior sets.

But it is horribly messy to proliferate like this when you also have four different sets of figures!

So I believe that a sensible course would be to provide two kinds of mega font, one which proliferates the superior/inferior alphanumerics, and one which proliferates the figure categories.

Really, shouldn't a scientific font have only one set of figures: tabular lining?

Or can we expect to see the typical Pro font of the future, as bundled by MS and Adobe, containing tends of thousands of glyphs supporting full figure variants, full superior/inferior variants, with full language support (poly Greek + Cyrillic), with small caps and swash features -- and all this in a range of optical sizes and several weights. Yes, Minion Pro 2009!

"Yes, Minion Pro 2009!"

With all that stuff, wouldn't it have be called:
"Minion Super-Duper All Pro Fruit of Thy Womb Adobe"?

ChrisL

Sergey Malkin (Microsoft Typography) and I have been discussing the need for a mathematical or scientific superiors feature. When used for exponent values, superior numerals should be higher than superior letters (hence what you observe in some fonts); however, there is a need also for aligning superior letters and numerals (which is why I do not raise my 'sups' numerals so high). The distinction is exactly the same as that between 'subs' and 'sinf', and we need a superior feature that corresponds to the latter.

>the need for a mathematical or scientific superiors feature.

The numerator feature can provide this, sort of, but as its name suggests it is only for figures.

Going by Adam's suggestion of four separate fully-charactered "mini-fonts" it would appear that presently we have two superior features -- superiors and numerators, and two inferior features -- scientific inferiors and denominators.

Here's how I'm presently using them: the nut fractions are activated by the fraction feature (making them the default, not the "afrc" alternative), made from superiors and inferiors. The "regular" fractions are activated using numerators and denominators.

Perhaps it would have been better to have come up with a different naming system: logically it would be: large superiors, small superiors, large inferiors, small inferiors. Or some such thing.

But it is too late now, ennit?!

Sounds like the Superior solution Nick :-)

ChrisL

A mathematical feature would also be good for replacing x's by multiply, dash by minus, and quote marks by inches/degree of arc.

the nut fractions are activated by the fraction feature (making them the default, not the “afrc” alternative), made from superiors and inferiors. The “regular” fractions are activated using numerators and denominators.

Meaning that the 'regular' fractions may never be seen in many applications. The 'numr' and 'dnom' features only exist because Adobe originally designed a large and cumbersome three-feature implementation for making fractions. I showed them how to do it with one feature instead, but by that time they had chosen to reveal the 'numr' and 'dnom' features in their application UI (bizarrely, considering the original intent of these features, which did not require user interaction). But I doubt if many other developers will follow suit: the features look obsolete, and the existing description does not suggest that they needed to be exposed to the user anyway. Only someone copying Adobe's implementation is likedly to expose them.

A mathematical feature would also be good for replacing x’s by multiply, dash by minus, and quote marks by inches/degree of arc.

These are character level concerns, not something that one should try to resolve at the glyph display level. The letter x is not × and the latter should not be encoded as the former. Characters have semantics and properties. If someone case mapping to a string of characters that includes a x posing as ×, you get X in the text string but might not even know it if you are seeing something that looks like ×. Or how about if you have a string that includes a variable x and an exponent value: you don't want a generic 'Mathematic Forms' features displaying the variable as × when trying to get the exponent value to be the right size and position.

Meaning that the ‘regular’ fractions may never be seen in many applications.

Yes, it's a choice on my part that when you use this font, you get nut fractions as standard.
The three pre-built fraction glyphs are that way too.
Given that it's more complicated for users to make numerator+denominator fractions (two 3rd-level menu clicks in InD, rather than one), I wanted to make it easier for them to get the nuts.

I didn't know the story. I'm just working with the basic features that show in InD, in CS1, as my benchmark. Lacking the presence of the "afrc" feature in the InD OpenType menu, it makes sense to me to use the "numr" and "dnom" features to give users access to an alternate fraction form.

...you don’t want a generic ‘Mathematic Forms’ features displaying the variable as × when trying to get the exponent value to be the right size and position.

Good point. I guess I was thinking more of a "math forms lite", for simple access to the basic math operators, like when you're doing a lumber catalog and you have product dimensions of 2" x 4". It's always struck me as a self-indulgence of the computer industry that Minus and Multiply are not on the North American keyboard -- but the ASCII tilde and ASCII circumflex are.

I'll just add that there are deliberately two fraction features, and using one to mean the other is doing a real disservice to your users. Please, bug people to support the 'afrc' feature. If you really want nut fractions to work today in InDesign, use a stylistic set on top of 'frac' as well as putting them in 'afrc' - but don't lie about your features. Everybody hacking features in crazy ways will tend to create chaos.

T

I have been looking at my daughter's old Calculus book (for typographic reasons only) and seeing some complex math issues that make me wonder how much an OTF font can do and how much a real math setting program is required. I know very little about higher math so I am unable to do right by it as a type designer. Where do we draw the line for math features? As Nick said, “math forms lite” and what would it be?

ChrisL

...but don’t lie about your features. Everybody hacking features in crazy ways will tend to create chaos.

Don't mistake what seems obvious to you for the truth.
It is not my intention to mislead people.
When I release the face, it will come with a PDF, and perhaps a printed piece for purchasers, which will list and explains the features.

As for chaos, think of my nutty fraction as one small antidote to the MicroDobia mindset that seeks to button down the whole planet -- standards are good, but one can have too much of a good thing. Besides, methinks it somewhat disingenuous of you to protest about chaos after enabling the foundry community with such a sprawling toolbox of OT features!

To me, the choice of fraction style is no different than, say, the choice of "a" or "g" variant -- who is to say that one form is standard and relegate the other to a stylistic set? I believe that the foundry should choose the variant that it thinks is appropriate to the typeface.

Albany is a very close revival of a specific face from an 1869 scientific work. All the fractions in the book are nut fractions, and what is now the "standard" fraction would quite simply be "slack" and entirely inappropriate to this sort of modern typeface.

I whole-heartedly agree with Adam Twardoch's suggested implementation, and it is consistent with my own practices in using type in designing papers. Although not semantically precise, the 'ordn' glyphs seem to share size, baseline, and some intuitive overlap with the letter forms used in abbrevations such as Mlle. Compare to the numero character or Nr. in German.

Nick Shinn's point that frac/afrc should be considered stylistic variants is also on the mark, and his example of Albany makes that point very clearly -- the form the designer chooses for the three fraction characters that are standard in the Latin-1 range (as well as the others in the Unicode 0x2150 range, if used) should determine which style goes in which feature. Even if standard slashed, rather than nut, fractions are considered normative, which form of the fraction should be implemented in the default 'frac' function depends entirely upon the face in question, not an arbitrary dictat by the specification authors. Let's not forget that type ultimately is design, not software.

OK, off my high horse, I have what is perhaps a naive question: besides its potential equivalence to the 'dnom' set, for what typographic purposes are the small, baseline-level 'subs' alphabet generally used?

Cheers,
Brent Sleeper

It's too bad we're off on this dumb tangent, because the original thread was pretty interesting and useful.

But lest anybody be taken in by Nick and Brent's specious logic, it's not "my truth" - it's in the OpenType spec in black and white.

Yes, both forms of fractions are stylistic variants of the general concept of fraction. And, despite the bias in the spec's names for the two kinds of fractions, each is an independent layout feature. Which style goes with which feature is defined in the OT spec. I pointed out how Nick could make things work the way he wants completely within the OpenType spec. If a couple of vendors want to make broken fonts, that's their problem. Too bad they'll be making it their customers' problem, too.

This feels as silly as saying that because you want to make the default figures in your font oldstyle figures, you're going to reverse the coding of the oldstyle and lining features, so people will get the figures you want instead of the figures they want, when they invoke a specific figure style.

If people want to change the spec, that's cool. Get involved with the ISO process and you can have as much say as anybody else in the new Open Font Format, the ISO equivalent of OpenType, which is starting from OpenType 1.4.

I'm especially entertained by the argument that boils down to "features are confusing, and it's all Adobe and Microsoft's fault for making them, so we might as well use them for whatever they want because it's confusing anyway."

Oh, and if you feel you must lower the level of the argument by using phrases like "MicroDobia mindset that seeks to button down the whole planet," feel free. it won't stop me from trying to deal with actual issues. I'll continue to bite my tongue when witty counter-insults spring to mind.

Sigh,

T

You're right, Thomas -- Dan Reynold's original question really is the interesting part of this thread, so I hope the discussion about the typography itself (rather than the OpenType tangent) continues.

On completely red-herring-flavored note, the Unicode spec makes clear that all of the precomposed fractions (0x00BC-0x00BE and 0x2153-0x215F) can take either the nut or vulgar form, without affecting their semantic value. I add this only to note that the actual glyphs in a font can take whichever form the designer wants, regardless of whether or not it also is appropriate to misapply the frac/afrc features.

Cheers,
Brent Sleeper

Chris, you need a dedicated layout engine to do math typesetting properly. MS Office 12, now in beta so I guess I can talk about it, includes a new equation editor, math engine and also a special math font, based on Jelle Bosma's CT font Cambria and called Cambria Math, which Tiro built for MS. I can't talk about any of the details of how the math layout engine and font work, but it is very complicated and only a small portion of what needs to be done is handled via OpenType Layout tables.

Thanks John. I guess the under part of my question is what should I do as a type designer to make type usable to people. I realize the real math intense stuff is a very specialized (perhaps small?) segment of type users. I still want to be sure that type I produce will be usable by not only ordinary publishing software, but specialized math software as well. I at least I don't want to make problems. That is why the math issue seems important. I don't know who was involved in setting up the opentype standards. I assume some math type users must have had a say. Did what came out of it all seem to solve the problem? Is it an issue of just using the standards in their simplest way or should we look for more creative solutions within the standards?

ChrisL

Specialised math software requires specialised maths fonts. It really is a very distinct market, and the majority of fonts simply are not of any use for typesetting mathematics. Similarly, a dedicated maths font may not be suitable for typical publishing needs, because of mathematicians' preferences vis a vis glyph shape and spacing.

On the other hand, there is a subsection of mathematical symbols that may be encountered in non-maths text, e.g. basic arithmetic symbols, exponents (superior numerals), and also symbols or special usages of characters from other sciences, such as the inferior numerals used in chemistry, e.g. CF₂Cl₂. So it makes sense to cater to preferred display of these, but there is no catch-all solution. I think the examples Dan shows at the beginning of this thread, with superior numerals and letters misaligned and of different optical weights, are a mistake; but then I make fonts for humanities scholarship, in which one needs aligned superior numerals and letters for apparatus critici. I'm aware that the positioning I use for these may be considered too low for exponent values by mathematicians. Hence what I see as the need for a feature to distinguish regular superior glyphs from mathematic superior glyphs, in the same way that the 'sinf' feature distinguishes scientific inferiors from... well, actually from something that doesn't really have a conventional use: little letters sitting on the baseline, according to the feature description (this is why I use the same glyphs for both 'sinf' and 'subs'). This is what is known as irony: we have two distinguishing features where we don't need them, and lack them where we do need them.

By the way, a maths typesetting system would probably ignore all this. There would be optically scaled variants for use at super- and subscript sizes, and also smaller versions still for superscript applied to superscript in equations, but the positioning of these would be determined by the layout engine.

I concur with John - math typesetting is remarkably complex, and most of it is beyond what is reasonably going to be handled in the font infrastructure.

Another way of thinking about this is to consider math typesetting as a "complex script" kind of language that is much more complicated than any other. The layout engine needs to know all about this language in order to deal with it correctly, and what the font supplies is only a small part of this.

Now, that being said, there are certainly issues of what characters a hard-core math font should have, and how they should be designed, etc. Johannes Kuester has given some interesting talks on this at various conferences. Some of his presentations and others are saved here:
http://www.tug.org/twg/mfg/ (one suspects that some of the content on this site might be TeX-specific, but a lot of it looks pretty broadly useful at first blush)

Regards,

T

I can second Thomas' recommendation of the TUG Math Font Group and Johannes Küster as good places to start. Küster's presentations are targeted at designers and touch on a lot of key design issues, such as clear differentation among significant glyphs, relative sizes and forms of operators, etc. (BTW, the archival source of the documents is at Typoma.)

Also, check out the American Mathematical Society. Working with the TeX community (which is predominantly mathematicians), AMS has established well-defined character repertoire. The set of official AMS math fonts might be useful to study for illustrative purposes. An interesting piece of the AMS set is the Euler family, designed and donated by the indomitable Hermann Zapf. Donald Knuth writes about working with Zapf on this project in his book Digital Typography.

Another well-regarded math family is Charles Bigelow and Kris Holmes' Lucida series; TeX-compatible extensions to both Lucida serif and Lucida Bright are available. I believe Adobe sells the former, but the Bright math extensions have gone through a series of distributors. I think Ascender may be the current commercial distributor, but TUG also recently became a source for non-commercial licenses.

Beyond the typography, the predominant technology issue for the past decade has been converting and integrating a complex set of legacy TeX encodings to Unicode. The Unicode Consortium has a technical memo on their site that talks about some of the very basic issues. The TUG math working group has several much more detailed papers as well.

John's observations about Office 12's math engine are interesting -- TeX has been the predominant approach to typesetting math papers for more than a decade. TeX is crufty but wonderful, too. Thomas' comparison of math layout to a complex, non-Latin script is very apt.

Cheers,
Brent Sleeper

...if you feel you must lower the level of the argument

Sorry if I over-reacted Thomas, but I was upset at being accused of lying about my features. I'm just an indie font guy working on his first full-featured OpenType font, trying to make useful, unusual fonts, and trying to understand the complexities of the format.

I've explained the typographic reason behind my choice of nut fractions as default.
Perhaps I have made a mistake and misunderstood the way things work. But I am not attempting to deceive and create chaos.

If people want to change the spec, that’s cool. Get involved with the ISO process and you can have as much say as anybody else in the new Open Font Format, the ISO equivalent of OpenType, which is starting from OpenType 1.4.

I don't know how the ISO process works, but I think all that would be necessary would be to get the feature names changed to "diaf" (diagonal fractin) and "nutf", as that's what they really are, and that's probably not worth the effort.

Anyway, I don't think I'd want to get involved in that process. And if I don't, does that mean I have to make my fonts conform to it on every single spec? As I said, the non-conformity of the feature would be explained in the accompanying pdf/specimen.

However, the spec might not be where my problem really is, as I will try to explain in the bottom paragraph below.

This feels as silly as saying that because you want to make the default figures in your font oldstyle figures, you’re going to reverse the coding of the oldstyle and lining features, so people will get the figures you want instead of the figures they want, when they invoke a specific figure style.

Your simile is silly, because a figure style (either oldstyle or lining) is on by default, whereas a fraction style has to be applied -- the situation is quite different.

There are no oldstyle figures in Albany. It is a modern face, and moderns do not usually have oldstyle figures. I'm making the same kind of distinction with its fractions.

It wouldn't matter so much, if there were two fraction choices in the OpenType menu palette: Diagonal Fraction (corresponding to "frac"), and Nut Fraction ("afrc"), then the user could choose, and in Albany the "Diagonal fraction" menu item would be "braced" (not available).
If that was the case with CS InDesign, on which I base my font usability, then I would not be considering reversed coding.

Back to the original question about the height of superior numbers and letters... Late night trivia and/or pedantry for folks looking to make the next Grande font.

Linguists use a very long list of superior small cap and superior miniscule letters (a smorgasbord of forms derived from Latin, Greek, Cyrillic, and the IPA) to indicate various phonetics. Most, but not all, of these are in Unicode (as "modifier letters").

I would characterize them as meeting Adam Twardoch's category "c" -- their x-height generally aligns with the font's overall ascender height. The superior small caps are drawn to be visually identical in height to the superior miniscules. (This same x-height sizing rule also is true for the non-superior/non-modifier small cap letters in phonetic use.)

Brent Sleeper

But what is the outcome of this thread?

I think A.T.'s suggestion for four small-sized alphabets of different vertical placement makes sense. It is a formal distinction first of all & does not specify whether a particular set of alphabets is for text or mathematical use.
However, Mr Twardoch wrote: "The denotations “superior figures” and “superior letters” are vague. The designers of the OpenType spec failed to recognize that the typesetting practice needs both figures and letters is the “d” set form (placed above the the ascender/caps height line), which are used to denote footnotes, [...]"
Personally I prefer the "c" set (top aligning with caps height) to denote footnotes. Obviously, typographic preferences matter. So it is to be decided whether these features should be distinguished by "semantics" (what are they to be used for, what is their meaning?) or by "form" (what is their vertical alignment like?). I opt for the latter, but would welcome any solution if it is only systematic. The feature names should reflect this. Remains the question if existing features should be merely redefined (esp. numr and dnom) for there already is some consensus as to vertical alignment, or new ones be defined.
That there is a need for clarification is out of question for me.

frac & afrc -- In case afrc will be supported at all in future, a more specific feature description were welcome. (E.g. what about nut fractions like 1/12? Is distribution of space in the numerator handled by layout engine or by feature?) If feature tag definitions would show another entry: feature is supported, features is likely to be supported, &c, many requests would be obsolete.

The real problem with OpenType features -- what are they to do, what is the layout engine to do -- seem to be communication. This bothers me.

On the other hand what we do is "just fonts".

Cheers,
Karsten

Karsten: Yes, the main issue with nut fractions is that it is rather difficult to figure out how to do complex or arbitrary fractions in that format. Adobe's default assumption has been that it has to be handled by the font, as one can with diagonal fractions. However, in my initial pondering, I'm having difficulty coming up with an approach to contextual programming that would be at all manageable. For instance, the overall width of the fraction is determined by the longer of the numerator or denominator, and that overall width also affects the positioning of all the digits of both the numerator and denominator. So the X-position of the first digit of the numerator is dependent on both the total fraction width and the number of additional digits in the numerator. I am reasonably sure this is technically solvable, but it would be some very lengthy code indeed, and would either involve an awful lot of additional characters or an awful lot of contextual positioning. My first off-the-cuff calculation is that allowing for, say, max six digits of numerator and denominator would require 116 variants or possible positionings for each digit, including both numerators and denominators. (Insert your own belief-system-appropriate request for luck or divine intervention.)

Nick:

I wasn't trying to make it personal - let's try to keep this on the level of what will best serve the end user's needs. My take is that your proposal is to have the features of the font lie about what they are. It's really the font doing the lying, not you. And of course, lying can be perfectly ethical under certain circumstances. Whether and when it makes sense to have a font lie about the nature of its OT features is a tricky question. In fact, when and whether to use OT features or Unicode in such ways is a topic that I proposed for an upcoming type mini-conference (on which, more in the New Year).

So, your basic problem is that InDesign currently only supports 'frac' and you want your users to be able to get to 'afrc'-type glyphs easily. I suggested a work-around, but it was certainly more awkward than simply reversing the features.

As has come up before (and those who've heard this shtick can stop reading now), my own take on this is that it is almost always a Really Bad Idea to put bogus info into fonts to work around current application limitations. My main rationale for this is that your fonts will likely have a life-span of 15+ years, while app versions are frequently replaced. If in five years we are dealing with the bogus font info when the apps have been updated to handle the feature we were trying to hack around in the first place, then we can look forward to another 10+ years of living with that.

Of course, fonts that are only intended for usage in a closed system, or that are sold by vendors who think they can simply upgrade all their customers to a new version when needed, are less troublesome in this regard.

I recognize that there will be diverse opinions on the wisdom of font hacks to work around limitations of current applications. However, I also think it's important to be clear about what's going on when a font lies about its OT features or Unicode codepoints for some short-term gain. I realize that "lie" is a strong word, but I think it's appropriate to use for cases when a font is deliberately built with incorrect information or representations in it to achieve some specific goal. By "incorrect" here I mean "clearly not complying with the relevant specification" (OpenType or Unicode).

For an example of a font that lies about its Unicode encoding, and for understandable reasons (whether or not one thinks the reasons sufficient), I give you the dreaded pi/dingbat font. Or even a regular text font that has some added dingbats or logos. Nobody wants to put the company logo at some Unicode private use area codepoint that can't even be keyed? It seems so much easier to just put the logo in the slot for some symbol that the particular user/client/company doesn't care about, but is still keyboard-accessible. The same line of thinking is easily applied to dingbat/pi fonts.

Cheers,

T

Thomas, I agree with you in principle, but not in the real world.

There is zero likelihood that Adobe (or any other) layout applications would ever include the menu item "nut fraction".

Why give space to a feature that 99.9% of fonts don't support, that 99.9% of users would never use?

As long as layout applications offer "fraction" and even in the inconceivable event that they were to also offer "alternate fraction", my use of the fraction feature for nut fractions will make sense to the user, even if it doesn't comply with the spec 100%. You type "figure-slash-figure," you highlight them, you select the OpenType "Fraction" feature, and you get a mathematically correct fraction.

...that are sold by vendors who think they can simply upgrade all their customers to a new version when needed

I'm not loading all my fonts with stuff that will be out of date the next round of layout app upgrades, which seems to be the implication. I just have this thing about nut fractions. What's the point of cultivating a fastidious and unpopular taste if I can't share it with kindred spirits?

"I just have this thing about nut fractions. What’s the point of cultivating a fastidious and unpopular taste if I can’t share it with kindred spirits?"

Sometimes I feel like a nut...:-)

ChrisL

Nick wrote: There is zero likelihood that Adobe (or any other) layout applications would ever include the menu item “nut fraction”.

If you're referring to the UI label for the feature, I expect that we'd call it a "stacked fraction" and rename the other kind "diagonal fraction." I am quite certain that the likelihood of the feature appearing is higher than zero, but it may not be large, 'tis true. The only other typeface that I know to contain nut (stacked) fractions is Palatino Linotype. Does anyone know of others, or plan to develop them?

Cheers,

T

I’m having difficulty coming up with an approach to contextual programming that would be at all manageable.

Here's my hack:
I set my sights quite low, restricting the range for numerator and denominator to 1-99, and assuming that there would be no "greater than one" fractions. It required making two horizontal "nut dash" glyphs, one for single digit denominators, and one for double digit denominators. I also made an alternate set of numerators with extra sidebearings (@numr2), for use in situations such as 7/16. Some kerning was required to prevent the composite fraction from being too close to the adjacent full size figure.

I fine-tuned the size and y position of the superior figures and scientific inferior figures to work in this feature; that's also a good size for them in other uses. And I co-ordinated the position of the em and en dashes, and math symbols, to centre vertically on the nut dash.

For fractions with more than two-digit numerators or denominators (such as are used to represent ratios) rather than use the fraction feature, typographers are advised to "composit" the fractions themselves, from sups, em dash (horizontally scaled) and sinfs, suitably kerned. You'd have to do that anyway, but at least with this system the component parts are all the right size and vertical position.

feature frac {

sub @FIGURES' slash by @numr2;
sub slash' @FIGURES @FIGURES by nut2;
sub @FIGURES @numr2' nut2 by @sups;
sub slash by nut;
sub [nut2 nut] @FIGURES' by @sinf;
sub @numr2' nut by @sups;
sub @FIGURES' @numr2 by @sups;
sub @sinf @FIGURES' by @sinf;
sub @sups @numr2' by @sups;

} frac;

I didn't mind doing this extra figure work as I only have one set of figures in the typeface, tabular lining.

Thomas:
Justin Howe's Foundry Caslon features nut fractions, as does Carter's Big Caslon, Monticello and Galliard (CC version). Some of the old URW expert sets have nut fractions.

Of course, only Foundry Caslon is available in OpenType.

I'm glad you found my summary useful. No claims for absolute correctness of course, just an attempt to clean the stuff up.

As for the scientific superiors feature ("ssup"), it is a good thought. You may have noticed that I used a terminological distinction "text superscript/subscript" and "scientific superscript/subscript" in my summary. Currently, we have four features (sups, subs, sinf, ordn) but of course the ordn feature isn't *really* an appropriate complement to the other ones. A clean pairing sups-subs, ssup-sinf would be useful.

BTW, Johannes Küster's presentations on typesetting maths are available at his own homepage:
http://www.typoma.de/en/publications.html

A.

Nick,
Thanks for sharing your hack. I'll have to try that.

ChrisL

I wrote about this in the last century. When the small letters usually are made to line with the ascenders, http://www.microsoft.com/typography/developers/fdsspec/lowercase.aspx

This makes the x-height lower than they would be for ordinals. (Spanish a, o).

Numerals are usually for scientific notation alignment or shilling fraction alignment (baseline). There are many different positions for these and a one does all approach is difficult.

I was trying to find a scanned example from Geoffrey Dowding's Finer Points which includes nut fractions in-line with the running text (which look great) [Monotype Ehrhardt]. Then searching around a bit I noticed this, an alignment of the point I have not noticed before. As alignment of punctuation was mentioned in regard to ordinals I thought I would just add this in for typographic (rather than coding) flavour. This point punctuation are also used inside a table.

Are these mid-points?

From: Legros and Grant, Typographical Printing Surfaces p.163

Cool ne?
_________________________________
Michael Hernan

I have also run into this conundrum when redesigning my font to add Ordinal and Superscript features. I see there is no consensus on this, and plenty of scope for proliferation. These are my conclusions so far for superscript glyphs to include in the font:

1. Numbers should align with top of caps (with some overshoot for 0, 8, etc.)
2. Include uppercase superscript glyphs A-Z.
3. Letters (and ordinals) should use the baseline of superior ¹
4. Include basic punctuation: !%&(),-./;:?@[\]“” ‘’
5. Include at least Èè and Úú for ordinals if not a full set for superscript text.
6. A vertical scale factor of 60-65% seems to be about right.
7. Stacking fractions should align with top and bottom of lining figures.

I don't like the idea of including more than one set of small glyphs in the font — it is far too much work — I already have Petite Caps and OldStyle Figures.

I think it should be possible to define features using GPOS if one wants numerators, denominators, or subscripts (as well as scientific inferiors).

This is how I designed the ordinals feature (the Ordinals group includes A-Z, a-z, èÈúÚ, and OldStyle Figures):

feature Ordinals ordn {
lookup Ordinals;
}
group @Ordinals [zero-nine uniE2C0-uniE2C9 uniEAA1 - uniEABA uniEAC1 - uniEADA uniEB28 uniEB3A uniEB48 uniEB5A];
group @Alphas [A-Z a-z Egrave Uacute egrave uacute];

lookup Ordinals{
context (@Ordinals) @Alphas;
sub 0 Super;
} lookup Super {
sub [A-Z] -> [uniEAA1 - uniEABA];
sub [a-z] -> [uniEAC1 - uniEADA];
sub Egrave -> uniEB28;
sub Uacute -> uniEB3A;
sub egrave -> uniEB48;
sub uacute -> uniEB5A;
}

I've included superiors in a variety of types, and find it hard to generalize a set of principles that works for every kind of typeface.
In particular, x-height and whether ascenders are taller than cap-height have a lot of bearing on the matter.

Am presently doing a slab serif face, and noticing that the superiors need to be quite large.

This highlights a key issue for superiors/inferiors: finding the sweet spot of weight and scale that makes them look like they belong in the same font as the normal glyphs, and do not seem to be either faux (shrunken) or a bolder style.

While I think there is room for variance in the actual height of superscripts, I consider it very important that the superscript letters and numerals share the same alignment. Superscripts are used more frequently in academic publishing than anywhere else, and there are plenty of situations in which superscript letters and numerals are used together, e.g. in apparatus critici.

Some academic publishing also calls for uppercase superiors, and I've found these to be a useful way of setting the superiors height. If you align the top of superior caps to the lowercase ascender height, everything else sort of falls into place, and you get superiors that work equally well for notes indices, ordinals, and apparatus symbols.

Since our shop mainly sets type -- but also modifies fonts (when the EULA allows of course), I've run into the conflicting needs for superiors with differing heights above the baseline.

As John recommends, if there is to be a full set of alpha-numerics, they should all have the same baseline. And I agree that aligning with the top of the ascender of a lower-case letter is the right height.

But rather than proliferating the font with repeated glyphs, when we encounter a use requiring a different height, we create another *character style* in the layout program and shift the baseline in that style. You can also scale them a bit in that character style, should that be needed.

I understand the argument that not all text editors/layout programs permit this. But failing Unicode's desire to proliferate sets of superiors, or the OT spec proliferating features (neither of which I'd like to see), this seems the best way to work.

Put simply, if the font designer can give a good set of superiors, having a common baseline, those of us who use type are well served. If the superiors have a different baselines, or are of a different nominal size, you make our life quite difficult -- enough so that I'll go into the font and fix it.

Charles said:

“I agree that aligning with the top of the ascender of a lower-case letter is the right height.”

I initially inclined towards using this alignment too, but decided that since my fonts include capital ordinals for setting with All Caps text, that top of caps alignment (and therefore top of figure alignment), works best.

Deciding on just how many glyphs to support is hard as my fonts include full support for Latin Extended Additional. Thus far I have decided on most of Latin 1 Supplement, and a few from Latin Extended A and Additional that I need for Pali/Sanskrit. Including the full set of Latin (and Greek) glyphs for Superscripts/Ordinals would be way too much work.

Garava Ordinals

I found that it is very easy to add a GPOS lookup for subscripts. Using the same glyphs that I added for the Ordinals feature, I added a Subscript feature with gpos lookup to move the glyphs down to bisect the baseline.

feature Subscript subs {
lookup Subscript;
} lookup Subscript {
pos [uni00B9 uni00B2 uni00B3 uni2070 - uni207E uniEAA1 - uniEADA] -> ,-990;
}

I then added an almost identical feature to move the superscripts down to align with the baseline.

feature Shillings shll {
lookup Shillings;
} lookup Shillings {
pos [uni00B9 uni00B2 uni00B3 uni2070 - uni207E uniEAA1 - uniEADA] -> ,-534;
}
This seems like an efficient solution. The user types 123 abc etc., and applies the superscript feature to get superscripts, then also applies the subscript or shilling feature to get subscripts or baseline subscripts.

A similar feature could be applied to move lowercase ordinals higher than the uppercase ordinals.

If your font is just for yourself, your trick for inferiors will get the ink on the paper in the right place.

However, if the font is for general use, you have to check that the text exported from, say, InDesign or any other text editor/layout program, doesn't have the wrong character. Depending on how the font is made, I could write the substitution code along the lines you suggest, where the 2 in H2O would set as an inferior with your font, but would, in a subsequent text file, be a superior.

In short, repositioning a character to look like another character which has a different Unicode number is not nice.

Thanks for the feedback. I had to drop the idea to use GPOS anyway, since it seems that PagePlus X5 doesn't yet support GPOS features.

My latest fonts have glyphs that are used for both ordinals and superscripts, while subscripts are composites of superscripts. I included a basic set of punctuation and about 100 Latin Extended characters for superscript text. Ordinals include just A-Z, a-z, and Èè Úú.

Uppercase superscripts align with top of Caps, and baselines of lowercase superscripts align with uppercase.

If anyone wants to try the fonts in InDesign I will be interested in your results. I am new to this, so I am sure there will be some problems.

My Fonts Page

Bhikku, I am a bit late to respond (to a different thread), sorry, but I don't think your ordinals code is correct.
Please see this thread:
http://typophile.com/node/74330

The ordinals feature works for me — have you tried the font?

After a digit, all alphas are superscripts until a non alpha character is typed — that is any punctuation, space, or digit (other than A-Z, a-z, Èè or Úú).

Works for 1st, 2nd 3rd, 1ST: 2ND; 3RD; 1èm, 2o, 3ú, or 7/16ths 31/32nds etc.

After a digit, all alphas are superscripts...

But that should only occur in ordinal situations.
Consider, for instance, an address like 221b Baker St.
Or an era like the 1960s.
Or 50k (either a sum of money or a race distance).
Those would have superscripted alphas if your feature were applied as a paragraph style sheet.

I suspect there may be yet other kinds of letter-number sequence that occur in text where ordinals would not be appropriate.

I suppose one could limit the ordinals group to only s, t, h, r, n, d, o, è, ú, and S, T, H, R, N, D, O, È, Ú, but that seems far less flexible. As you say in the linked thread, "This works for English," but what about other languages, and what about text set in all capitals or small capitals, e.g. 4TH JULY?

Calibri, Constantia, etc., just apply superscripts to all text with the ordinals attribute, regardless of whether it follows a digit or not.

In PagePlus it is easy to enable or disable the Ordinal feature from the text context toolbar.

If one is going to have an Ordinals feature, it should at least be different than the Superiors feature, or else it is redundant, so why bother?

So your code, which discontinues the feature after a non-alpha character is OK, as is mine, which is English-specific.

The reason my code doesn't cover superior capitals is because I have yet to produce a font with those glyphs!
However, I have considered it; I particularly like the idea of superior capitals with dots underneath them, a style which was used in the 19th century for abbreviations.

As for other languages, I haven't gotten around to that just yet.

Nick: If one is going to have an Ordinals feature, it should at least be different than the Superiors feature, or else it is redundant, so why bother?

Two reasons:

1. So that feature tagged text created in a font that supports the ordinals feature displays with appropriate ordinal forms in your font, even if these forms are identical to the superscript feature forms and are even referenced from the same lookups;

2. Users working with tagged text (e.g. XML) might have have defined a distinction between superscript and ordinals, and it is convenient for them if these are mapped to corresponding features in style sheets, again independent of how the results are either displayed or arrived at in a particular font.

I will have to admit that I would expect superior letters to have exactly the same baseline as superior digits, so that I can refer to x squared, or x raised to the power of a, with equal facility. But many typefaces are not primarily intended for the typesetting of mathematical formulae.

But many typefaces are not primarily intended for the typesetting of mathematical formulae.

Yes. And if you will read the whole thread, you'll note that "mathematical formulae" are not the only, or in this thread, even the primary concern.

Sometimes ordfeminine & ordmasculine have small underlines.

Is the underline appropriate for all languages?

Sorry for the lazy Post! I am doing a writeup of ordinal usage and will post up.

In the mean time here are a couple of links:

Links and further Reading

Conversation about the underscore:
http://forums.adobe.com/thread/565418?decorator=print&displayFullThread=true

Typophile thread about kerning ordinals:
Node 67507

Typophile thread about various uses of ordinals:
Node 16879

Okay mods—

This last entry is clearly spam…

Spam paid by whom...? SOftmaker distances itself from these rumours, true or false. Rather a desperate act to somehow make contact, be useful... But still, it does seem rather pointless.