See this:
http://talleming.com/2008/04/16/fraction-fever/
and the fraction feature in the "features.family" file contaned in the example font provided by Adobe here:
http://www.adobe.com/devnet/opentype/afdko/ExampleRomanFonts.zip

Tal also has an updated version

http://talleming.com/2009/10/01/fraction-fever-2/

Ah! I'd missed that!

I think, Tal’s code has not necessarily to be used for the feature "frac", but could be used for an additional ss feature.

The Minion Pro example font is great, thanks for sharing.

Is there any point to including pre-built fraction glyphs in the font if this code essentially takes care of all fraction possibilities?

I've been including both for several years. Neither of our comps uses the "prebuilts." Just be sure your kerning is good with the arbitrary fractions, and there is no need for the prebuilts.

Not all programs support Opentype features, and not all that do support them in full ...

It's not as if there are lots of predefined fractions in Unicode either :-) We're talking about 1/2, 1/3, 1/4 and 3/4 for minimal support, and (I think) the eights for "full" support.

Thanks, thanks, thanks...
Tal Lemings frac-fever works fine. But: In the end of the script there is a line with a so-called 'thinspace'. What's that?

In the end of the script there is a line with a so-called 'thinspace'. What's that?

http://www.fileformat.info/info/unicode/char/2009/index.htm

The thinspace (a fifth of an em [or sometimes a sixth]) is too wide, isn’t it?

Yes, the thinspace seems to be the wrong character. It must be a space, that is either typographically correct with regard to its width, or that has exactly the same width as the regular space, intended to be manually replaced by a smaller space, or that has a width of zero (with the intention, that the user adds the typographically correct space, if required). If the correct space does not have an Unicode point, the space should be replaced by either a (non-breaking zero) width space or a non-breaking regular space.

What do the professional typographers say?

It shouldn't be a Unicode space.
I name the thin-space glyph used for fractions as "space.frac".

Integer followed by fractions in the manuscript is typed "number-space-number-slash-number", and the code distinguishes between integers (followed by space) and numerators and denominators (separated by slash).

So a style sheet can be applied globally to a block of text (recipes, say), and there is no need to laboriously select out each fraction.

However, after the integers and fractions are sorted out automatically, the space remains, so replacing it with a thin space does the trick. In fact, it is better visually than butting fractions right up to integers, because the sidebearings on the numerator are so small. Of course, one could add positive kerning between integers and numerators, but this code makes that unnecessary.

But the thinspace has an Unicode point, Nick. What’s the width of your "space.frac"?

I eyeball it, so it varies from font to font.

The reason for using "space.whatever" as the glyph name is to preserve the integrity of the text.
Unicode "thinspace" is not widely supported.

Why do you have abandoned a width of the space.frac just in case of the second font?

The reason for using "space.whatever" as the glyph name is to preserve the integrity of the text. Unicode "thinspace" is not widely supported.

I don’t understand, what you mean, because space.whatever is less widely supported. I mean, what could happen, if you would use a space with an Unicode point? I thought, that calling it thinspace is a bad idea, because a thin space is defined as the fifth or the sixth of an em, which is (if the em is 1000 units wide) at least more than the triple fold of the average of your space.fracs.

Wouldn’t it be good to have Unicode spaces, that are defined as multiples and fractions of the width of the regular space in the font?

Why do you have abandoned a width of the space.frac just in case of the second font?

As I said, I "eyeball" a lot of things to do with type design, and don't always do them to the same formula. That's my philosophy for keeping my eye sharp and the fonts looking good. It does produce some inconsistencies, but spacing is an expression of taste, not mechanic principle.

...what could happen, if you would use a space with an Unicode point?

I have been led to believe, by Thomas Phinney and John Hudson primarily, that the original text of a document should remain intact when it is rendered in an OpenType-enabled document. For reasons of searching, and repurposing text.

In this instance, if one searches for, say, "15 15/16" in a pdf document, one won't find it if the space has been replaced by Unicode thinspace. Furthermore, if one copies the text, and sets it in a font which doesn't support Unicode thinspace, there will be a ".notdef" in the middle of the number.

Thomas, John, did I get that right?

For reasons of searching, and repurposing text.

That’s plausible. Comparable with the naming of small caps.

Type designers and typesetters sometimes have a different viewpoint. I see about 300 manuscripts a year. Been that way for about 30 years. The number of ways people type fractions after numbers varies. For manuscripts coming from publishers anyway, we almost never see a space between a number and a fraction. Usually they use a code around the fraction, rarely a hyphen. Sometimes just the general instruction.

The moral is, any typesetter worth their name (never mind those of us claiming to be compositors) has to look and resolve things. If you want to put in a thin space, fine.

Just don't count on a word space being in the file.

The space I put in between a fraction and a full-size number is a kern. Define a class that has all the numerators. Another class that has all the numbers -- lining and oldstyle. Kern the classes. One of the few class kerns I use. If you set the left sidebearing of the numerators about the same, this works fine. As far as that goes, the same (more of less constant left sidebearing) is needed if you use a thinspace. Kern numerators and denominators with each other and with the fraction character. All this takes about an hour. The kern values between the numerators are very good candidates for your kerns with the superscript numbers, by the way. Depends on how you set things up.

If you want precomposed fractions, Unicode allows for the half and quarters in the Latin Supplement (00A0 range), then in U+2153 through U+215E, there are codepoints for the thirds, fifths, sixths, and eighths.

@ charles

Simplified, the space (or any other character except from the slash) indicates the begin of the fraction in Tal’s feature file (if a figure is following). If there is no other character between two figures in front of a slash, both figures will be substituted by numerators. We are talking about the character, by which the space shall be substituted.

By the way, the indicator doesn’t have to be a slash. Maybe it is better to substitute a class, that contains all characters except from the figures, the numerators and the slash, by a space.frac. A whole keyword could be substituted instead – 2frac1/2, where frac is the keyword. (But in this case Tal’s code could be probably shortened.)

For manuscripts coming from publishers anyway, we almost never see a space between a number and a fraction.

Nonetheless, I think it is a best practice to type the space in the MS, in sync with a font that has the fraction feature which replaces it by a thin space. After all, this can save compositors a huge amount of work in a fraction-heavy document.

Nick, it doesn't matter what you think best. I'm not being sarcastic, it doesn't mater what I think best, either. What matters is what people do; what I'm reporting is what we see with manuscripts coming from academic publishers. Scholarly book publishing -- which oddly enough, includes a fair number of cookbooks -- is perhaps a small segment of the "manuscripts" out there. I don't know how magazines work, or for that matter, commercial book publishers.

What I am saying is it is not OK for typographers to say "I don't care how people do it," my way is best. You will be ignored by both authors and editors.

For anyone, if you handle a lot of manuscripts, I'd advise doing some pre-processing in a text editor (or in InDesign, if your up to the scripting). That way, if you need a space to trip the fraction feature, you put it in. If the space gets in the way, as with our practice, you take it out.

For some things, the type designer's only recourse, and only obligation, is a readme file that tells people how to use the features available with the fonts.

Hello Nick and Charles, I don't think that you disagree. It doesn't matter how text indicates fractions as long as it does indicate them. Code around fractions, which Charles mentions, is as fine as a preceding space. The typographer may use GREP to convert what he gets into what he needs, be it InDesign markup (for applying a character style with frac feature enabled to fractions only, or for a script to add kerning between number and fraction), be it a preceding space which allows Tal-style frac features to care for the space, or yet another approach.

Nick wrote:

I have been led to believe, by Thomas Phinney and John Hudson primarily, that the original text of a document should remain intact when it is rendered in an OpenType-enabled document. For reasons of searching, and repurposing text.

Absolutely agreed. There are two main things to watch for:
1) Having an OpenType substitution that exchanges a glyph that has one Unicode for a glyph that has a different one is Very Bad Form Indeed.
2) It's a Good Idea to use glyph naming conventions such that glyphs which have a Unicode codepoint are named in ways that reflect it, and glyphs which should "boil down" to a given Unicode codepoint, do so. See http://www.adobe.com/devnet/opentype/archives/glyph.html and especially http://www.adobe.com/devnet/opentype/archives/glyph.html#6 for details.

In this instance, if one searches for, say, "15 15/16" in a pdf document, one won't find it if the space has been replaced by Unicode thinspace.

This can happen in at least some routes of PDF creation, yes. It's a violation of the first principle above.

Furthermore, if one copies the text, and sets it in a font which doesn't support Unicode thinspace, there will be a ".notdef" in the middle of the number.

True, though it's a weaker objection. After all, that can happen any time one has a character not supported by a given font. In some environments (MS Word, web browsing) one will usually get "fallback" to a font that has the desired character, although that of course will be a different font than the rest of the text. Whether or not that's a problem can vary.

Thomas, John, did I get that right?

Indeed you did, old chap!

Cheers,

T