oneonum.tnum

Don't do that. The part of the name before the period should be a standard character name. However, anything after the period is totally up to you. Whatever makes most sense to you and works with your development tools is all that's required.

I’m not talking about OT-feature definitions or making an alternative version of petite caps. I’m trying find/ build a short rational suffix system that I can use in my production today and tomorrow.
However it would be convenient (today) if the suffix could correlate with the OT-features some how?

“I call bullshit!” the name – or perhaps the idea of being able to substitute a “petite” shape for another in general?

BW,
KTKM

Can’t think of any right now :-/

Bw,
Kristian

You do need to keep in mind that there is a limit to how long a glyph name can be (31 characters).

I did face the same question months ago while developing a very large font with dozens of alternative glyphs. After some tries, I built a schema combining suffixes when needed:

Case groups: .uc, .sc and .pc
Design alternative: .da
Linguistic alternative: .la

When using two suffixes, the last one is always the case as it represents the larger group. In other words, the name goes from the more specific to the more general (glyph > variation > case).

Thus a regular small caps a is a.sc while an alternative design for the same letter is a.da.sc. A special character with locale variation would be uniXXXX.la and the petite caps variant for this is named uniXXXX.la.pc.

To save room for long names I use just two letters in each suffix, no matter if the related OT feature uses four characters.

For number groups I use a letter for case [u, s, p, o] and a letter for the spacing criteria [proportional/tabular]. This results in .op/.ot for oldstyle proportional/tabular, .pp/.pt for petite caps figures and .sp/.st for small caps figures. An alternative design (as an open 4 instead of a closed one) receive the .da suffix, resulting in .da.op, .da.st and so on.

Although a bit complex at first look, this became very handy to manage a large project with multiple groups of glyphs.

Hmm. I did see that somewhere, but I just tested it in FontLab by making a very long glyph name, and it still compiled and generated okay. So, maybe that's not true, or maybe the limit was changed at some point.

Yes, the limit is mentioned in Adobe's guides. In the same vein, in FontForge:

If you intend to use feature files, then lookup names should be: less than 31 characters [...]

(Aside: less than 31 ... :?)

Thus my thinking it's an ADFKO limit and for Type 1 fonts only, not an OpenType one.

The backwards-compatibility bit makes sense, at least. Inside a Type 1 font, individual glyphs are still indexed by name -- how quaint!

Underlying reason: I'm creating my own Type 1-flavored fonts, including necessary OTF code. The latter does *not* force short names, but the former does. Since any user supplied glyph names *inside* the font are "for internal usage only", I probably could cull long names and replace them with a simple numeric counter inside the CFF.
(I used to think Adobe InDesign was able to show "custom glyph names" but somehow that stopped working, or perhaps it never did.)

@Theunis – Turbo Pascal's STRING type has a maximum length of 255 characters with the length stored in the first byte of the string. I think that's pretty much standard for those microcomputer Pascals that have a STRING type.

Other Pascals, like FreePascal and GnuPascal, may offer longer and wider strings, but these may well have length and data stored as separate records or even be C strings!

Oh, and there are some Pascal manuals available from Bitsavers. I've seen Borland manuals there.