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?

> 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

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

Naïvely and simplisticly…

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

"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

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

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

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.

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

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

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

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.

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

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

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

"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

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.

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.

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

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

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.

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