What should I call my glyphs?

Nick Job's picture

Is there an official standard of what I should be calling my glyphs?
(And if not, why not?)

I'm especially interested to know what to call:
- small caps
- tabular, proportional, oldstyle and tabular oldstyle numbers
- superiors, inferiors, numerators and denominators
- upper case lining characters
- nut fraction alternates
- stylistic alternates (e.g. single storey a)

Any others I should know about?

Anyone know how Adobe do it and is that the received wisdom?

Nick Job's picture

Thanks Kent. Is this the most up-to-date that Adobe has published (it's dated 2007 - three years ago) and is it what Adobe is now using?

I've got a recent Linotype font that's using .onum, .prop, and .onumprop as the numerical suffixes. (This assumes of course that the default is tabular. It also uses .nominator (rather than .numerator).

There's a thread somewhere that has a discussion on numeral conventions (.lnum_pnum, .lnum_tnum, .onum_pnum, .onum_tnum) but is this any sort of accepted standard or just robust, logical good practice?

.00's picture

Is that received or perceived wisdom?

As long as you separate the base glyph name from the suffix with a period you should be fine.

a.perceivedwisdom01

Nick Job's picture

Is that received or perceived wisdom?

That's what I'm asking you! Have you received it as wisdom? If you have, then you must have perceived it as such! If you have perceived it, you may still not have received it!

a.perceivedwisdom01

I know I can call them what I like really but isn't it about time it was standardised?

All those in favour say, I.alt01!

.00's picture

but isn’t it about time it was standardised?

I hope not.

Nick Shinn's picture

...is this any sort of accepted standard or just robust, logical good practice?

There appear to be house standards that vary considerably from foundry to foundry.

I must admit I use an antiquated system I adopted before I fully understood the way OpenType works.
It might be a good idea to have a widely observed standard, e.g.

.plf (proportional lining figure)
.tlf (tabular lining figure)
.posf (proportional oldstyle figure)
.tlf (tabular oldstyle figure)

Following on, a set of cap-height lining figures, to be deployed in the "case" feature, would be suffixed ".plf.case" or "tlf.case", to distinguish them from three-quarter height lining figures, which it is assumed would be the default lining figures, ".plf" and ".tlf".

I suspect that the lack of a standard system is the result of a "why bother?" attitude caused by the fundamental flaw in the OpenType figure system, namely that there is no way of identifying what style the default is just by looking at its name (it will always be the inscrutable e.g. "one") -- the only way is through a process of elimination.

**

The solution may be to have a duplicate set of glyphs for the default figure style, with the appropriate suffix, so that all four basic figure suffixes are represented in the font.

That way, a layout engine could always get the correct glyph, even without the appropriate OpenType feature.

**

Also related: the need to have separate sets of superior figures for mathematical and reference purposes, i.e./e.g. both "onesuperior" and "one.sups".

kentlew's picture

I don't think absolute standardization is important. I think some logic is useful. But it can be internal, working logic for any given working group. If you're a one-person studio, it can be personal idiosyncratic logic, if you want.

I believe Adobe has started varying from some of what is expressed in that document, but the principles still seem sound.

I seem to remember some recent Adobe Pro fonts with groups suffixed with random single letters. I presume this is just to make it easier to key all these alts when writing features. Having to type long suffixes over and over can get tedious, as well as prone to typos.

The flip-side is the challenge of remembering what random suffix goes with what alternate.

Nick [Shinn] -- I don't think you want a double period there in your .plf.case example. I believe that would lead to parsing problems when devolving. You might be better with .plf_case instead.

Nick Shinn's picture

Thanks for the tip, Kent.

Syndicate content Syndicate content