OpenType Superiors Feature: Why do letters and numbers have different baselines?

Primary tabs

63 posts / 0 new
Last post
Dan Reynolds's picture
Offline
Joined: 20 Jul 2002 - 11:00am
OpenType Superiors Feature: Why do letters and numbers have different baselines?
0

When comparing the "superiors" feature with the "fractions" feature in a number of OpenType fonts from Adobe and Linotype (and others?), some questions arise. Specifically, in the superior glyph range, why do letters have a different baseline from numbers and punctation? This is not the case with glyphs covered by the fractions feature.

Here are some examples illustrated:

Superior numbers have a higher baseline than superior letters. Why? (Illustrated above: [normal capital H], [superior 1], [superior 2], [superior 2], [superior 3], [superior a], [superior b], [normal lowercase c])


What this leads to, is impossible typography, as pictured above. The period should have the same baseline as the superior letter, no? Instead, it has the baseline of the numbers.


Fraction numbers are larger than superior numbers. This is understandable.


Fraction numbers and letters share a common baseline. This seems to make typographic sense. Why here and not with superiors?

Could this have something to do with a legacy work-around? If a type designer, or major type foundry, were to change this, would it cause any problems? Are there users who expect the superior feature to be defined in this manner?

Nick Curtis's picture
Offline
Joined: 21 Apr 2005 - 8:16am
0

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.

Dan Reynolds's picture
Offline
Joined: 20 Jul 2002 - 11:00am
0

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?

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

Jeffrey's picture
Offline
Joined: 15 Aug 2007 - 3:25am
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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;
}

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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.

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Michael Hernan's picture
Offline
Joined: 24 Sep 2005 - 2:45pm
0

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

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

John Savard's picture
Offline
Joined: 23 Nov 2009 - 8:42pm
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

Michael Hernan's picture
Offline
Joined: 24 Sep 2005 - 2:45pm
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Michael Hernan's picture
Offline
Joined: 24 Sep 2005 - 2:45pm
0

Sometimes ordfeminine & ordmasculine have small underlines.

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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

Nick Curtis's picture
Offline
Joined: 21 Apr 2005 - 8:16am
0

Okay mods—

This last entry is clearly spam…

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

Is the underline appropriate for all languages?

Bhikkhu Pesala's picture
Offline
Joined: 10 Jul 2010 - 3:28pm
0

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.

Adam Twardoch's picture
Offline
Joined: 3 Dec 2002 - 7:36pm
0

> 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

Andreas Seidel's picture
Offline
Joined: 8 Mar 2002 - 3:44am
0

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?

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

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

Nick Curtis's picture
Offline
Joined: 21 Apr 2005 - 8:16am
0

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

Dan Reynolds's picture
Offline
Joined: 20 Jul 2002 - 11:00am
0

Naïvely and simplisticly…

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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!

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

"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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

Sounds like the Superior solution Nick :-)

ChrisL

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

Brent Sleeper's picture
Offline
Joined: 15 Feb 2005 - 12:21pm
0

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

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Brent Sleeper's picture
Offline
Joined: 15 Feb 2005 - 12:21pm
0

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Brent Sleeper's picture
Offline
Joined: 15 Feb 2005 - 12:21pm
0

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