My typeface has standard ligatures, stylistic alternates, and swashes. I will be selling the font and I want it to be as commercially viable as possible, and as useable as possible to potential buyers. So I am wondering if I should add Private Use Area codes to those mentioned glyphs?
Two arguments I've seen/received—I value both sides of the argument I received in the past, but because they are different, I'm trying to figure out what may be best:
So it seems safer, more commercially viable to indeed give those glyphs PUA codes… but perhaps the more “pure” practice is to leave unencoded.
I would appreciate any thoughts.
My DTP application, PagePlus, has an option to insert glyphs based on Glyph Index, which allows access to unmapped glyphs, e.g. Linotype Palatino Small Capitals, without using OpenType features. However, changing the font will change the glyphs that are displayed, which is not good. If I use the OpenType Small Capitals, there's not such a big problem. At worst, abc will be displayed instead of ABC small capitals.
- Unmapped may be best for the purists, as it discourages users from creating documents with a load of PUA characters, which do not display at all or which display differently if the font is changed.
- I have long mapped Petite Capitals, Alternative Fractions, etc., to PUA code-points, because in earlier versions of FontCreator that was the only way to generate them automatically using Complete Composites. The latest version 10.1 now supports Complete Composites based on glyph names, so it is no longer essential to map them.
I would advise going with unmapped. Most users could not care less about OpenType features, and don't know what the PUA is.
PUA is compatible with all applications and it gives the user the option of picking a glyph off a chart rather than toggling a bunch of features to see what happens. Customers seem to want PUA encoding for display type. For shuffling alternates (pseudo randomization) it can be difficult to control exactly the alternates you need. For example, you've got two lines of text and there's an M directly above another M and the shuffle landed on the very same alternate M. Gross! So you select the M and turn off the feature that activates the shuffle. But the M that was there just happened to be the original 004D M. You turn the feature back on, select the character before the M and turn off the shuffle feature. That resets the shuffle and the M is changed to one of the alternate glyphs...hopefully the one you wanted. But now everything on the rest of the line's shuffle has been offset and guess what? There's another vertically repeating glyph further down the line.
Let's say you want to create a title or logo using a shuffling alternates font. You want to precisely control which alternates are selected but some of them aren't accessible on the glyph chart and no combination of shuffling will let you get the one you want. Luckily the font designer thought to add multiple stylistic alternates but unfortunately, you're not using one of the few design applications that support stylistic sets and you just can't do it. You bought a font but there are glyphs you can't even manually select. Unhappy customer.
I used to map alternates to PUA, then I realized that it would be problematic (spelling/search) but then customers started contacting me and requesting it. I'm gradually going back and mapping everything to PUA, at least for display features.
Originally, I made the call to push for use of PUA, and got approval to do so. Some years later, I came to regret that decision, and eventually, at least for new fonts, Adobe stopped doing it. But, for the fonts that already shipped that way, Adobe had a backwards-compatibility problem, so they are stuck with continuing that. So, regret.
Basically, what we found was, very very few of our customers actually used the PUA encoding to access these goodies. The ones who knew so much that they could do such things and actually cared that much would tend to also use savvy apps. And this back in the days before Office supported such things.
Anyway, I originally was pro-PUA, and now I regret having gone there. I'll take this opportunity to apologize to my Adobe peeps for having saddled them with another “bit of legacy stuck to their shoe,” as David Lemon would put it.
As you can see, this is a recipe for all kinds of problems.
- Small Capital A = 1D00 (Phonetic Extensions)
- Small Capital B = 0299 (IPA Extensions)
- Small Capital C = D04 (Phonetic Extensions)
- Small Capital D =1D05 (Phonetic Extensions)
- Small Capital E = 1D07 (Phonetic Extensions)
- Small Capital F = A730 (Latin Extended-D)
I think @Ray Larabie 's example and points about including PUA codes for these glyphs is a selling point for those buyers using lower end software (who are knowledgable enough about it)—and their subsequent requests for PUA to be added to the alternate glyphs after purchasing a font—is on point with that side of the argument, and why one might lean towards adding the PUA codes. (And, I will say, this is for a display typeface, as noted.)
Unfortunately that doesn't seem to be the best nor purest practice, but without the codes, the concern indeed is customers who bought the fonts but can't use fully... PUA codes seemingly would help alleviate that—at least for display type it may be less problematic.
The challenge, it appears in current day, is there is such a large range of buyers to consider (from hobbyists to pro designers), software sophistication (or lack thereof) being used, and knowledge base (what to look for and how to use fonts with features).
Still, why would that make anyone happier than just PUA-encoded alone?
About composites, do you mean making a reference from one glyph to another? I once thought that was possible (while, well, reverse-engineering Arial) but I now tried exporting a font containing references into OTF in FontForge and the references were gone (unreferenced) upon export. Do I need to take additional steps to export references? Or do I need to use another tool and not FF?
Composites are indeed essentially references from one glyph to another, used with TrueType outlines. Subroutines are a more automated and flexible version that does not necessarily deal in whole glyphs, used with PostScript CFF outlines. Both have been possible and widely used pretty much forever.
I am afraid I am not a FontForge expert, but I believe it supports both mechanisms. Here's a bit: https://fontforge.github.io/accented.html
I'm guessing if I were to update the same font that has PUA encoding, I should continue to use the exact same encoding for everything, so when people replace the previous font with the updated version it doesn't screw up.
So for the uninitiated, do I just select the alternates and ligatures and run this script in Glyphs or is there some other recipe? https://github.com/mekkablue/Glyphs-Scripts/blob/master/Glyph Names/Add PUA Unicode Values to Selected Glyphs.py
Explain why it is not good practice for users to insert glyphs from the private use area (because if the document's font is later changed to a different font, the glyphs will either change to .notdef rectangles, or to completely different glyphs).
Tell them that these glyphs should be used by enabling OpenType feature such as Small Capitals or Stylistic sets.
If they still want a special version of the font for applications that do not support OpenType, charge them for the extra work needed.
FWIW it's the Wild West right now; there's no rhyme or reason as to what's what. If you don't have/need a master table (if you have different sets of alternates in each font) the easiest way to do this is to let the apps assign encoding behind the scenes. Not sure how Glyphs works but in FLS 5, simply select the unencoded alternates. Then Glyph ---> Glyph Names ---> Generate Unicode. In the popup, make sure the Assign PUA indexes to unencoded glyphs and Apply only to selected glyphs boxes are checked, and click OK.
Customers do seem to be aware that alternates and thus, PUA encodings, are unique to each font. I've never had an issue with them changing the font and complaining about subsequent missing glyphs in their document. There may be conflicts of course, but the kind of customer who asks for PUA encoding is probably not the customer who is also going to complain about the lack of an Apple logo, Tibetan or Klingon in your font.
If you feel like going down the rabbit hole: https://en.wikipedia.org/wiki/ConScript_Unicode_Registry
@Rainer Erich Scheichelbauer How is this done in Glyphs?
And if they don't already have LibreOffice, asking someone to install an office suite just to make an OpenType feature work is a bit much. Does anyone know any easier solutions for generating SVG text with at least some basic feature support? Inkscape seemed like they were going to start supporting a few features but that's been at a standstill for ages. What about light editions of high end vector apps?
If the application the customer is using has no OpenType support, how does the kerning work when they're manually adding PUA glyphs? Wouldn't an app that doesn't support OpenType features, not support kerning classes?
My point is: it all sucks and I'll probably relent and put back all the PUA encoding I ripped out over the last 20 years. Is there a magic Fontlab script for this or just drag & drop 'em?
Pretty damn good OT Feature support. Only CorelDraw has a better mechanism for accessing alternates. AD has a glyph browser as well.