Where do I put the extra characters?

RichardK

I'm working on a font that has the standard letters a-z and A-Z. However, I also made another version of those characters, with fancy curls and such. The question is, where do I store those extra characters in the Unicode table? I thought I found a nice spot at the end of the Unicode table, but that turned out wrong. Those characters at the end are so-called Full Width Characters, meaning they sit in the middle of a square space. That destroys the spacing in my texts.

One other option is to store those extra characters in a random location, replacing the text with gibberish if you change the font. Or...

Please advise!

Mislav Serdarušić

I believe those special characters are called Alternates and I would also like to know how or where to place them for the future projects.

Thomas Phinney

Typically, in modern fonts, these are left unencoded. You do not assign Unicode values to them at all. If you feel you must encode them for some reason, give them Private Use Area (PUA) codepoints. https://en.wikipedia.org/wiki/Private_Use_Areas — but of course that will not help the problem of the text turning into gibberish if you change the font!

Instead (or in addition, whether or not you encode them), you should make them accessible by means of OpenType layout features. That means that each glyphs are accessed by means of the base character plus OpenType feature(s), and if the user switches fonts, that underlying character (the text) is always preserved. This also allows things like spell checkers to behave correctly, so it is just generally a Good Thing.

Exactly which OpenType feature(s) you use depends on the exact nature of the alternate glyphs. Perhaps “swsh” (swash) is appropriate, for fancy curls. Or maybe “salt” (stylistic alternate).

You may notice that there are a fair number of fonts from Adobe that use PUA codepoints for alternate glyphs, as well as having appropriate OpenType features. That was a decision made by me in the quite early days of OpenType, and if I had it to do over again, I wouldn’t do it. Honestly, hardly anybody ever used the PUA codepoints as an access route, and now that is just weird crud left in the fonts. 

Cristóbal Henestrosa

I’d say the best approach is to store them as swashes or stylistic alternates. So they don’t have proper Unicode values, BUT they can be activated in the appropriate software, such as InDesign or Illustrator. In what software are you working on?

John Hudson

Further to what Thomas wrote, I only use PUA encodings for variant glyphs if a client specifically requests, and then only after we have talked through the pros and cons. Typically, the only clients who opt for PUA are a) working with texts in which the specific variant form of the glyph is meaningful to the publication (e.g. ‘diplomatic’ transcriptions of inscriptions) and b) are working with one or more know pieces of software that are unable to access the variants reliably via OpenType Layout features. I would avoid using PUA for purely stylistic variants for which OTL features are better in every respect.

Ray Larabie

Private Use Area (PUA) encoding for alternates has become the standard for display typefaces on platforms such as Creative Market. Many novice users and enthusiasts depend on applications like Canva, PowerPoint, and other tools that do not support OpenType features, making PUA encoding crucial for customer satisfaction. I often receive support requests from customers who struggle with accessing alternates, and I guide them on how to copy and paste PUA characters. It is advisable to place the glyphs between E000 and F8FF, preferably closer to E000, as that is where customers will likely search for them in a character map or glyph table. For non-display fonts, it might be better to leave them unencoded. OpenType features have existed for 25 years, and it is likely that applications not supporting PUA will continue for the foreseeable future. While I understand the drawbacks of including PUA for more serious text typefaces, some customers using basic applications desire decorative elements like swashes, and it seems unreasonable to require them to purchase new software to access those features.

PabloImpallari

I produce my fonts according to the specs.

If the user can't use it in a specific app and ask me about it, I told them that they should complain to the app developers to fix the buggy app to support standards, or use other app instead. Because it's an app problem, not a font problem.

I do understand that the people selling commercial licenses are forced to produce non-compliant fonts. For business reasons it makes total sense for them .. but in doing so they remove the incentive of the app developers to improve their apps.. hence perpetuating the cycle.

RichardK

Thank you all for the input. I think I'll give the PUA approach a try and see what develops. I make fonts for the public domain, and have no idea what software the users have. There is a small group, however, working with CNC milling machines that only work with .ttf files. For them I convert the .OTF to .TTF.

Mark Simonson

I agree with @PabloImpallari on this in the sense that I don't use PUA. At the same time, I don't have much hope that, by doing so, app makers will be incentivized to add OT feature support to their apps. I don't know what it would take, but to me it's like pushing a rope.