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

Primary tabs

63 posts / 0 new
Last post
Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

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

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 Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

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

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

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

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

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?

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

"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

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

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

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

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.

John Nolan's picture
Offline
Joined: 6 Dec 2002 - 11:00am
0

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.

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

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.

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

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

ChrisL

Vincent Connare's picture
Offline
Joined: 6 May 2005 - 4:33am
0

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.