And what are the superior a through t for?

R\V

It's not absolutely essential to know what the glyphs are for, just check out what they look like in some standard OT fonts. Adobe bundles such with CS, and Gentium is another good reference (it's free, too).

If you must know:
http://www.microsoft.com/typography/otspec/features_ae.htm

The colonmonetary is the "colon" currency symbol, which looks like a C with two diagonal bars through it. Because it's a currency symbol, it's commonly designed on tabular widths (that is, the same as your tabular figures).

The onefitted is the proportional version of the numeral one.

But as Nick says, you can learn a lot just by looking at the glyphs in an existing font.

Cheers,

T

Robby,

please don't use the glyph names from the "Adobe OT PS Standard Names (CFF)" encoding. Weird as it may seem, they're not compatible with Adobe's current recommendations for glyph naming. This encoding lists names that are internally represented by numbers rather than names in a CFF table.

Adam

Adam,

That's not quite right. The correct thing to say is, do not use the “Adobe OT PS Standard Names (CFF)” encoding. This is because it is safe to use glyph names from that encoding, as long as they're also present in the Adobe Glyph List For New Fonts http://partners.adobe.com/public/developer/en/opentype/aglfn13.txt

This means that, only the glyph names listed below should NOT be used.

Note: fi and fl are between parentheses because Mac OS X (as of 10.4.8) still relies in glyph names (instead of the 'cmap' table). This means that if the font doesn't contain these two glyph names, the OS will perform font-flaback on the characters U+FB01 and U+FB02.

(109 fi)
(110 fl)
150 onesuperior
164 twosuperior
169 threesuperior
229 exclamsmall
230 Hungarumlautsmall
231 dollaroldstyle
232 dollarsuperior
233 ampersandsmall
234 Acutesmall
235 parenleftsuperior
236 parenrightsuperior
239 zerooldstyle
240 oneoldstyle
241 twooldstyle
242 threeoldstyle
243 fouroldstyle
244 fiveoldstyle
245 sixoldstyle
246 sevenoldstyle
247 eightoldstyle
248 nineoldstyle
249 commasuperior
250 threequartersemdash
251 periodsuperior
252 questionsmall
253 asuperior
254 bsuperior
255 centsuperior
256 dsuperior
257 esuperior
258 isuperior
259 lsuperior
260 msuperior
261 nsuperior
262 osuperior
263 rsuperior
264 ssuperior
265 tsuperior
266 ff
267 ffi
268 ffl
269 parenleftinferior
270 parenrightinferior
271 Circumflexsmall
272 hyphensuperior
273 Gravesmall
274 Asmall
275 Bsmall
276 Csmall
277 Dsmall
278 Esmall
279 Fsmall
280 Gsmall
281 Hsmall
282 Ismall
283 Jsmall
284 Ksmall
285 Lsmall
286 Msmall
287 Nsmall
288 Osmall
289 Psmall
290 Qsmall
291 Rsmall
292 Ssmall
293 Tsmall
294 Usmall
295 Vsmall
296 Wsmall
297 Xsmall
298 Ysmall
299 Zsmall
301 onefitted
302 rupiah
303 Tildesmall
304 exclamdownsmall
305 centoldstyle
306 Lslashsmall
307 Scaronsmall
308 Zcaronsmall
309 Dieresissmall
310 Brevesmall
311 Caronsmall
312 Dotaccentsmall
313 Macronsmall
315 hypheninferior
316 Ogoneksmall
317 Ringsmall
318 Cedillasmall
319 questiondownsmall
326 zerosuperior
327 foursuperior
328 fivesuperior
329 sixsuperior
330 sevensuperior
331 eightsuperior
332 ninesuperior
333 zeroinferior
334 oneinferior
335 twoinferior
336 threeinferior
337 fourinferior
338 fiveinferior
339 sixinferior
340 seveninferior
341 eightinferior
342 nineinferior
343 centinferior
344 dollarinferior
345 periodinferior
346 commainferior
347 Agravesmall
348 Aacutesmall
349 Acircumflexsmall
350 Atildesmall
351 Adieresissmall
352 Aringsmall
353 AEsmall
354 Ccedillasmall
355 Egravesmall
356 Eacutesmall
357 Ecircumflexsmall
358 Edieresissmall
359 Igravesmall
360 Iacutesmall
361 Icircumflexsmall
362 Idieresissmall
363 Ethsmall
364 Ntildesmall
365 Ogravesmall
366 Oacutesmall
367 Ocircumflexsmall
368 Otildesmall
369 Odieresissmall
370 OEsmall
371 Oslashsmall
372 Ugravesmall
373 Uacutesmall
374 Ucircumflexsmall
375 Udieresissmall
376 Yacutesmall
377 Thornsmall
378 Ydieresissmall
379 001.000
380 001.001
381 001.002
382 001.003
383 Black
384 Bold
385 Book
386 Light
387 Medium
388 Regular
389 Roman
390 Semibold

Indeed Miguel, that's what I meant. Not to say that none of your glyphnames may appear in the “Adobe OT PS Standard Names (CFF)” encoding, but that this encoding as a whole is not a good source for "good glyph names".

A.

What do you now recommend naming small caps, old style, superior, and inferior numbers?

William, you can find Adobe's recommendations for glyph names on these two pages:

— Unicode and Glyph Names
— Glyph Names and Current Implementations

The short answer is, read section 6 of Unicode and Glyph Names page.

For small caps*, for example, a.small, aacute.sc, or agrave.smcp are all sound names.

* If you care about unique glyph-character correspondence, you'll need to have two sets of small cap glyphs: one that matches the lowercase set, and another that matches the uppercase set. This means you'll end up with two small cap 'A's, one named a.sc, and another named A.sc. The first should be used in the 'smcp' feature, and the second in the 'c2sc' feature, as the code below illustrates:

feature smcp {
sub a by a.sc;
} smcp;

feature c2sc {
sub A by A.sc;
} c2sc;

Thanks, Miguel. Will do.

Just saw your note about 'unique glyph character correspondence'. What difference does this make?

Let's say that you decide to only have a.sc. This means that your 'c2sc' feature will look like this:

feature c2sc {
sub A by a.sc;
} c2sc;

In environments where character codes (Unicode codepoints) need to be reconstructed from glyph names — like when copying text from a PDF, for example — the text string 'AAA' styled with your 'c2sc' feature, will end up being converted to 'aaa', because that's the result of parsing '/a.sc/a.sc/a.sc'.

William,

as Miguel said, for casing features, you have three choices:

1. Duplicate your small caps glyphs so that there is one set that corresponds to lowercase glyphs, with names such as "a.smcp", "agrave.smcp" (or "a.small", "agrave.small" or "a.sc", "agrave.sc" but *not* "asmall" or "agravesmall") and one set that corresponds to UPPERCASE glyphs, with names such as "A.c2sc", "Agrave.c2sc" (or "A.smcp", "Agrave.smcp" or "A.small", "Agrave.small" or "A.sc", "Agrave.sc" but *not* "Asmall" or "Agravesmall"). In such case, the "smcp" feature would replace "a" with "a.smcp" and the "c2sc" feature would replace "A" with "A.c2sc".

2. Have one set of small caps glyphs named as if they were variants of UPPERCASE glyphs, i.e. "A.smcp", "Agrave.smcp" (or "A.small", "Agrave.small" or "A.sc", "Agrave.sc" but *not* "Asmall" or "Agravesmall"). In such case, the "smcp" would replace lowercase with those glyphs, and the "c2sc" feature would replace uppercase with those glyphs.

3. Have one set of small caps glyphs named as if they were variants of lowercase glyphs, i.e. "a.smcp", "agrave.smcp" (or "a.small", "agrave.small" or "a.sc", "agrave.sc" but *not* "asmall" or "agravesmall"). In such case, the "smcp" would replace lowercase with those glyphs, and the "c2sc" feature would replace uppercase with those glyphs.

Adobe follows variant 1, which allows them 100% glyph correspondence. With class kerning and composites, handling these duplicate glyphs is pretty easy in the production process. Also, it's easier to write OpenType Layout features because your font would have suplicate "S.c2sc" and "s.smcp" (as there is both "S" and "s" in your font), but you'd only need "germandbls.smcp" as there is only "germandbls" without an uppercase variant).

With this variant, if my source text reads "The typeface Constantia was designed by John Hudson" and I style "Constantia" and "John Hudson" with "all small caps" (i.e. both "c2sc" and "smcp" are applied), the document goes to PDF and is then retrieved by Acrobat or Google, the text will still read "The typeface Constantia was designed by John Hudson", so there is no semantic loss.

Variant 2 is also acceptable. If my source text reads "The typeface Constantia was designed by John Hudson" and I style "Constantia" and "John Hudson" with "all small caps", the retrieved text will read "The typeface CONSTANTIA was designed by JOHN HUDSON". There is some semantic loss but all-uppercase text is always orthographically correct. (After all, small caps are just smaller-sized lowercase letters)

Variant 3 is the least preferrable. If my source text reads "The typeface Constantia was designed by John Hudson" and I style "Constantia" and "John Hudson" with "all small caps", the retrieved text will read "The typeface constantia was designed by john hudson". This semantic loss is unacceptable becauase all-lowercase text is not orthographically correct in this case.

As or the glyphname suffixes, you can use whatever you want: "a.smcp", "a.small", "a.sc", "a.SMALLC" etc. are all acceptable for the small caps "a" glyph. "one.onum", "one.osf", "one.oldstyle", "one.lc", "one.o" are all acceptable for the old-style/lowercase figure 1.

Fontlab Ltd. recommends to use glyphname suffixes that are tied to OpenType Layout feature tags that the glyphs are used in (or primarily used in). So if you follow variant 1 of devising small caps (duplicate sets), You can name the glyphs "A.c2sc" and "a.smcp". Then it's instantly obvious that the OpenType Layout feature definition will be

feature c2sc {
sub A by A.c2sc;
} c2sc;

feature smcp {
sub a by a.smcp;
} smcp;

If your font has just two sets of figures (lining with Unicode codepoints, and oldstyle as variants), You can name the oldstyle figures "one.onum" so the feature definition would be:

feature onum {
sub one by one.onum;
} onum;

If a glyph is only accessed through a combination of features, e.g. if you have four sets of figures (tabular lining, tabular oldstyle, proportional lining, proportional oldstyle), you can use the names "one" (for the tabular lining), "one.onum_tnum" (for the tabular oldstyle), "one.lnum_pnum" (for the proportional lining) and "one.onum_pnum" (for the proportional oldstyle). In the suffix, you can concatenate the OpenType Layout tags using underscore, and the sequence of these layout tags are alphabetical. Similarly, if you have a stylistic variant of a small caps "R", you can call it "R.c2sc_ss01".

If the same glyph is used in several features independantly (e.g. a stylistic variant of "R" could be used in "ss01" and "salt"), you can pick the suffix that is most specifically tied to the glyph. "ss01" seems to be more specific that "salt" so you can call the glyph "R.ss01".

When it comes to ligatures, Fontlab Ltd. currently recommends using suffixes in these as well. The standard "fi" ligature can be named "f_i.liga" while a discretionary "st" ligature can be named "s_t.dlig". This keeps your glyphnames in order and allows you to quickly allocate the ones you need.

For localized glyph variants, Fontlab Ltd. suggests using the OpenType language tag, i.e. the Serbian "b" glyph would be named "afii10066.SRB".

Regards,
Adam Twardoch
Fontlab Ltd.

Once more, thanks to Adam and Miguel for more salient clues in the OpenType feature mystery:-)

ChrisL

Thanks, Adam, much appreciated.

> For localized glyph variants, Fontlab Ltd. suggests using the OpenType language tag, i.e. the Serbian “b” glyph would be named “afii10066.SRB”.

Just a small note to say, although 'afii10066' is a perfectly legal glyph name, Adobe is moving away from afiiXXXXX glyph names, in favour of uniXXXX (or uXXXX*) names. So in the case above 'afii10066.SRB' can be replaced by 'uni0431.SRB' or 'u0431.SRB'.

*Currently, Mac OS X (10.4.8) relies on glyph names and doesn't support this form.

2. Have one set of small caps glyphs named as if they were variants of UPPERCASE glyphs

Surely this is the only option that should be offered, because it maintains typographic correspondence, i.e. the emphasis of the original document -- in the same way that bold and italic are retained in "reconstruction".

“one.onum_tnum”

This "_tnum" seems to be an oxymoron, as the four basic figure groups are presently understood to be:

onum = oldstyle + proportional
tnum = oldstyle + tabular
lnum = lining + tabular
pnum = lining + proportional

What about superior/inferior figures?

Presently FontLab names these, eg "onesuperior". Should they now be renamed eg "one.superior"?

Yes, and make sure they get the right Unicode.

U+2070 zero.superior
U+00B9 one.superior
U+00B2 two.superior
U+00B3 three.superior
U+2074 four.superior
U+2075 five.superior
U+2076 six.superior
U+2077 seven.superior
U+2078 eight.superior
U+2079 nine.superior

U+2080 zero.inferior
U+2081 one.inferior
U+2082 two.inferior
U+2083 three.inferior
U+2084 four.inferior
U+2085 five.inferior
U+2086 six.inferior
U+2087 seven.inferior
U+2088 eight.inferior
U+2089 nine.inferior

This "_tnum" [in “one.onum_tnum”] seems to be an oxymoron, as the four basic figure groups are presently understood to be:

onum = oldstyle + proportional
tnum = oldstyle + tabular
lnum = lining + tabular
pnum = lining + proportional

Following the OT numeral feature logic, to address tabular oldstyle figures, both tnum and onum features need to be applied by the application. So mentioning both these features in the glyph name makes this obvious. The table should be:

width:
pnum = proportional
tnum = tabular
(Each of these features however covers both lnum and onum.)

alignment:
lnum = lining
onum = oldstyle
(Each covers both pnum and tnum.)

Miguel,
Does this mean I should change all the types I am currently working on to this new system? I am in the midst of organizing a workflow that is consistant rather than the hodge-podge learn-as-you-go thing I have been doing for the past 2 years. Will all this change again soon or can I bank on it not breaking in use for years to come?

ChrisL

PS: Looking forward to meeting you in New York!

Hi Chris,
I can't guarantee that things won't change in the future. All I can say is that this is the current best practice. Nonetheless, the glyph naming conventions outlined in the links above are pretty solid, so I'd say things are likely not to change significantly in the near future.

See you soon!

> onum = oldstyle + proportional
> tnum = oldstyle + tabular
> lnum = lining + tabular
> pnum = lining + proportional

No no no no :)

There are two typographic properties of figures:
a) case, i.e. vertical size and alignment, which can be uppercase (lining) or lowercase (oldstyle/floating)
b) width, which can be monospaced (tabular) or proportional.
These properties are controlled *independently* of each other by OpenType Layout features.

The "onum" feature switches UC figures (*lnum) to lc figures (*onum). The "lnum" does the reverse.

The "pnum" feature switches monospaced figures (*tnum) to proportional figures (*pnum). The "tnum" feature does the reverse.

If your font has four sets of figures (uppercase monospaced, uppercase proportional, lowercase monospaced and lowercase proportional):

* the "onum" feature switches from uppercase monospaced to lowercase monospaced and from uppercase proportional to lowercase proportional;
* the "lnum" feature switches from lowercase monospaced to uppercase monospaced and from lowercase proportional to uppercase proportional;
* the "pnum" feature switches from uppercase monospaced to uppercase proportional and from lowercase monospaced to lowercase proportional;
* the "tnum" feature switches from uppercase proportional to uppercase monospaced and from lowercase proportional to lowercase monospaced;

So, conceptually, you have four sets of figures:
* "onum_tnum": lowercase monospaced,
* "onum_pnum": lowercase proportional,
* "lnum_tnum": uppercase monospaced,
* "lnum_pnum": uppercase proportional.

*One* of these figure sets would be your *default* figure set, for which you wouldn't use a glyphname suffix and you would assign the Unicode codepoints to them. These could be the uppercase monospaced figures, but could be also a different figure set. For the three remaining sets, you'd use glyphname suffixes.

If you have four figure sets, each of the four features (onum, pnum, lnum, tnum) should *always* substitute two sets by two other sets.

More on this here und here.

A.

A postscriptum to Miguel's posting:

According to the more strict Adobe policy (which separates glyphs inserted through OpenType Layout from glyphs inserted through their Unicode codepoints), your font should have two sets of identical (duplicate) superscript and subscript figures, named and encoded as shown below. This encoding and naming ensures that the original text string will always be accurately reconstructed.

(U+2070) "uni2070" and duplicated as (unencoded) "zero.sups"
(U+00B9) "onesuperior" and duplicated as (unencoded) "one.sups"
(U+00B2) "twosuperior" and duplicated as (unencoded) "two.sups"
(U+00B3) "threesuperior" and duplicated as (unencoded) "three.sups"
(U+2074) "uni2074" and duplicated as (unencoded) "four.sups"
(U+2075) "uni2075" and duplicated as (unencoded) "five.sups"
(U+2076) "uni2076" and duplicated as (unencoded) "six.sups"
(U+2077) "uni2077" and duplicated as (unencoded) "seven.sups"
(U+2078) "uni2078" and duplicated as (unencoded) "eight.sups"
(U+2079) "uni2079" and duplicated as (unencoded) "nine.sups"
(U+2080) "uni2080" and duplicated as (unencoded) "zero.sinf"
(U+2081) "uni2081" and duplicated as (unencoded) "one.sinf"
(U+2082) "uni2082" and duplicated as (unencoded) "two.sinf"
(U+2083) "uni2083" and duplicated as (unencoded) "three.sinf"
(U+2084) "uni2084" and duplicated as (unencoded) "four.sinf"
(U+2085) "uni2085" and duplicated as (unencoded) "five.sinf"
(U+2086) "uni2086" and duplicated as (unencoded) "six.sinf"
(U+2087) "uni2087" and duplicated as (unencoded) "seven.sinf"
(U+2088) "uni2088" and duplicated as (unencoded) "eight.sinf"
(U+2089) "uni2089" and duplicated as (unencoded) "nine.sinf"

(The ".sups" and ".sinf" suffixes can be anything else, e.g. ".superior" and ".inferior" etc.)

A more economic way would be just one set of glyphs (just like you'd only use one set of small cap glyphs, "A.smcp"). This naming and encoding does not guarantee 100% reconstruction of the original string (because e.g. U+2070 will be reconstructed as U+0030).

(U+2070) "zero.sups"
(U+00B9) "one.sups or "onesuperior"
(U+00B2) "two.sups" or "twosuperior"
(U+00B3) "three.sups" or "threesuperior"
(U+2074) "four.sups"
(U+2075) "five.sups"
(U+2076) "six.sups"
(U+2077) "seven.sups"
(U+2078) "eight.sups"
(U+2079) "nine.sups"
(U+2080) "zero.sinf"
(U+2081) "one.sinf"
(U+2082) "two.sinf"
(U+2083) "three.sinf"
(U+2084) "four.sinf"
(U+2085) "five.sinf"
(U+2086) "six.sinf"
(U+2087) "seven.sinf"
(U+2088) "eight.sinf"
(U+2089) "nine.sinf"

Adam

According to the more strict Adobe policy (which separates glyphs inserted through OpenType Layout from glyphs inserted through their Unicode codepoints), your font should have two sets of identical superscript and duplicated as subscript figures

There's something wrong here.
There's no need for all this redundancy in the font -- why can't the layout application use Unicode codepoints for determining OpenType layout features?

No no no no :)

Adam, Karsten, I understand the principle of "two variables produces four instances", and have made dozens of OT fonts with four sets of figures that work just fine.

I came to the conclusion that
"onum = oldstyle + proportional"
by looking at the way characters were named in Adobe fonts, i.e. "oneoldstyle", and figured the rest out from there.

Looks like Adobe made a mistake by coming up with run-on names such as "asmall", "oneinferior", and "oneoldstyle" -- so don't roll your eyes at me, and how about admitting it?

***

Adam, please stop refering to "monospaced", "lowercase" and "uppercase" figures.
The correct terms are "tabular", "oldstyle" and "lining", cast in concrete as OpenType features!
http://www.microsoft.com/typography/otspec/features_ae.htm

What is the point of having standards if you don't stick with them?

You guys are making this up as you go along, changing your minds all the time.

Now I have to encode a simple "alternate set" as:

- Salt
- Titling
- SS01

...just to get it to work in past, present, and future versions of CS software!

Sure, it's software, and the bugs can always be fixed, but this thing is getting out of hand -- the kind of glyph proliferation that has been happening to the *ideal* opentype font in recent months is ridiculous. It's coming at me from every direction -- language support, legacy application support, "reconstruction" support.

What type designers -- and the font industry -- need is some good standard templates, not to have to figure things out for themselves on constantly shifting terrain.

Adam, Karsten, I understand the principle of “two variables produces four instances”, and have made dozens of OT fonts with four sets of figures that work just fine.

Sorry, I know. I just feared the table would irritate people who still have to fumble out how it works. (The logic of numeral feature styles is rather strange at first glance.)

What type designers — and the font industry — need is some good standard templates, not to have to figure things out for themselves on constantly shifting terrain.

My impression is that this will continue to be the status quo until finally Microsoft will come up with truely OT-savvy* applications (not a mere WPF, but WPF used by Word &c) -- of course with their own interface to access OT features. And it may take one or two more steps until Apple, Adobe, MS finally assimilate their slightly different approaches, so that user can use OT fonts the same way throughout different OSses and applications. No idea what this means in terms of years.
Prove that I am wrong and I'll be happy.  :)

Would it be possible to make some sort of a software matrix that would reside with the systems font engine that would contain all the assorted figure naming conventions and point them all to the same glyph rather than cramming all this redundancy into each and every font? It would function like a Rosetta Stone and could work like a substitution feature where you might say:
Sub glyph names a b c d for glyph Z or unicode number XXXX. This would take the hex off of legacy fonts and put it on the system software which changes every year anyway.

ChrisL

Nick,

did you test your fonts in various applications that support advanced typographic OpenType Layout features, or just in Adobe applications? One shouldn't presume that one particular implementation is enough to test against. (For example, do you test your features in TextEdit on Mac OS X 10.4? Or in Mellel?) BTW, I'm not implying that there is something wrong with *your* fonts. I haven't seen your OT code, and perhaps everything is all-right with it.

"You guys are making this up as you go along, changing your minds all the time." — I read some bitterness in what you're saying, but I believe you're being a bit naiive. I think you expect that some superminds behind the scenes had figured everything out back in 1999 (when OpenType was introduced), envisioned all kinds of typographic uses and cases for the layout features, all kinds of problems that a developer may run into. But of course, this was never the case. In the past years, OpenType has always been a work in progress. This is normal: when the specification was written, there were practically no applications that used it (except the Microsoft complex-script engines for Arabic, Indic scripts etc.), and there were only a handful fonts. When you look at the features as they were defined in Adobe Garamond Pro (one of the first OpenType fonts made by Adobe) and in Palatino Linotype (one of the first OpenType fonts with advanced typographic features made by Microsoft), there are a *lot* of bad practices.

I'm a person who's been trying to monitor whatever the "big guys" (Adobe, Microsoft, Apple) are doing, communicate with some independent developers (such as John Hudson), add my modest bit of knowledge about typesetting practice and about linguistic aspects, and distill this into designer-comprehensible talk. What I'm suggesting are "best practices as I see them", or perhaps "best practices as Fontlab Ltd. sees them". There is a certain amount of subjectivity -- you can always do this or that *differently* if you know why you're doing this. There are cases where you don't want to supply glyphnames at all in your fonts, there are cases where you want to write some features differently from what I recommend etc. I've done some thinking about this topic, but everyone is welcome, or actually even encouraged, to do his own thinking.

You're free to accept my advice, and you're free to reject it. You're welcome and encourage to comment and challenge my advice and my thinking -- as I never claimed that I know it all.

Best,
Adam

I'm not bitter Adam, just frustrated working on the never-ending font, as I discover something new each month that should be included or changed.

But perhaps I'm naiive, in wanting to produce fonts that function perfectly, as that no longer appears to be possible, and they're turning into just another piece of buggy software that needs constant upgrades to keep all the features working properly and in sync with applications.

I treat your recommendations very seriously, and as I've said before, you are in the perfect position, with FontLab, to take the lead and establish some standardized OpenType font formats that independent foundries can use. Nobody wants to be the little shop whose customers have to figure out its quirks. And the customers -- the typographers -- would like to see some consistency, so that they don't have to read a pdf manual for each font just to figure out how the features of Foundry A differ from Foundry B.

I'd love to be able to scroll down to a "FontLab Latin Text" codepage and have all the characters (including smcp, sinf, sups, etc.) pop up in grey, with proper unicoding and feature sets pre-built. The I click on "one.superior", and FontLab renders a scaled, positioned version of the "one.lnum_pnum" glyph in the character position. Pre-built family-naming would be handy too.

> I’d love to be able to scroll down to a “FontLab Latin
> Text” codepage and have all the characters (including
> smcp, sinf, sups, etc.) pop up in grey, with proper
> unicoding and feature sets pre-built. The I click
> on “one.superior”, and FontLab renders a scaled,
> positioned version of the “one.lnum_pnum” glyph in
> the character position. Pre-built family-naming
> would be handy too.

How much would you be willing to pay for this functionality?

A.

How much would FontLab be willing to charge?

Nick,

seriously, there are various options available -- scripts and extension files provided by indepenetent developers, core functionality within FontLab Studio, a separate tool. They could be custom-tailored or general-use.

A.

/Track/

I’m not bitter Adam, just frustrated working on the never-ending font, as I discover something new each month that should be included or changed.

Although there are things that have changed, including Adobe's choices for glyph names, there has never been any significant change in how we associate glyphs and features in this area (onum/tnum/lnum/pnum). Not since we shipped our first featureful OpenType fonts seven years ago.

Cheers,

T