Special form abbreviations

Kristian M's picture

I conducting an abbreviation research to see what is best for my production rate regarding glyph names.

Alternative [alt]
Small Caps [smcp]
Alternative Small Caps [????]
Petite Caps [pcap]
Alternative Petite Caps [????]
Standard Numeral Caps? (cant’t find a better word for it) [????]
Alternative Standard Numeral Caps [????]

What I need is basically a system that makes it easy to add new forms (swash, small caps, old style numerals etc.) with consistent four-letter suffix? So that I can keep true to it.

(I hate to write for example “one.onum_tnum” or “oneonum.tnum” . . .)

If a smart standard exist (that is shared by some developers) -- it would be perfect!


Mark Simonson's picture


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.

Frode Bo Helland's picture

Alternative petite caps? I call bullshit! Also, "salt" or "calt" are OT features -- "alt" is not.

A system: a.smcp.ss01

Kristian M's picture

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?


Frode Bo Helland's picture

I can actually think of settings where alternate petite caps makes sense, but for the most part it sounds pretty useless for anything but bragging.

Any situations where OT feature names doesn't work?

Kristian M's picture

Can’t think of any right now :-/


Frode Bo Helland's picture

It is also possible to write "a.smcp_ss01". Most of the time in my workflow, new letterforms belong to a particular OT feature and can be named after it. The rest of the time one can pretty much get by with "alt" (or for pseudo-random features, numbered alts).

Mark Simonson's picture

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

Kristian M's picture

Thank you!

Igor Freiberger's picture

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.

Theunis de Jong's picture

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

After processing, when OpenType features have been compiled, they only contain references to glyph indexes. Glyph names can be preserved in the 'post' table, but the OT specs do not refer to a maximum name length (other than "a Pascal string", and I'd have to check if this is an 8-bit, 16-bit or even 32-bit number).

Is this constraint a remnant of Ye Olde PostScript Type 1 specs? Constrained for backwards compatibility somewhere inside ADFKO?

Mark Simonson's picture

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.

gargoyle's picture

Is this constraint a remnant of Ye Olde PostScript Type 1 specs?

That seems to be the case— backwards compatibility. Although it's also mentioned in the OT Feature File spec.

Theunis de Jong's picture

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 de Jong's picture

Ah, wait a minute. Culling the name interferes with "name based" semantic lookup:

Even when the original font file is present, glyphs which do not match characters in the Unicode specification may still be usefully connected to a Unicode character by the glyph name. For example, naming a decorative variant of "t" as "t.alt" allows a PDF producing program to note that "t.alt" carries the same semantics as "t", for searching.

A reasonable scenario.

Adobe's sample glyph name "Lcommaaccent_uni20AC0308_u1040C.alternate" is too long, though.

Té Rowan's picture

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

Kristian M's picture

This is exactly what I’m been looking for! Thank you Igor!


Syndicate content Syndicate content