Private Use Area for ligatures and alternates
Adam Ladd
Posts: 263
Hi All,
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:
- Some have said “no” because those glyphs are connected to existing character unicode values (A.sso1 = A), so coding A.sso1 with a PUA code would cause breaks/incorrect mapping if fonts were switched by the user. And thus they should be left unencoded.
- But at the same time, those who have said “yes” did so because users who are working with less sophisticated software (this isn’t an issue for Adobe products nor in some cases newer versions of Word) won’t be able to access these ligatures and alternate glyphs unless I assigned a PUA to them. (I know PopChar is an option, but doesn’t seem to resolve all cases.)
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.
Thanks!
Tagged:
0
Comments
-
You just break search, spell checkers and hyphenation when using PUA. And people will see garbage when your font is not available. If you stylistic alternate glyphs are more important than all that...4
-
- 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.1 -
If you look at script, interlocks, swashes and being sold at distributors such as Creative Market, PUA seems to be a selling point. It shows up in ad copy quite a bit.
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.2 -
So, I went down this path 15-20 years ago, at Adobe. It was the subject of pretty intense internal discussions, at the time. I have heard some very smart people argue both sides of the debate.
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.7 -
Another conundrum is that a lot of Small Capitals have Unicode code-points in IPA or Phonetic Extension. I think it is mistake to map them to those code-points, but I have done it before, e.g.
- 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)
0 -
If the intended use of the font is things people will never open again after the job goes to print then PUA encoding should be fine. If this is a complex renaissance text face with quaint ligatures then definitely not.
1 -
Thanks much for your feedback and experiences, all, I can still see a case for both sides... and @Thomas Phinney , I appreciate the candor and insight.
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).1 -
James Puckett said:If the intended use of the font is things people will never open again after the job goes to print then PUA encoding should be fine. If this is a complex renaissance text face with quaint ligatures then definitely not.1
-
@Bhikkhu Pesala The phonetic “small capitals” are more like petite caps (x-height) than small capitals (small-cap-height). So yeah, it’s best if nobody uses them for small capitals.0
-
How about including duplicates of the affected glyphs (with one unencoded and one PUA-encoded slot per glyph)? Would that make everyone happy? Of course the file size would soar. Or maybe two separate font files could be created with clear explanation for the customers. Certainly, this last solution doesn't seem too crisp.
1 -
Duplicating glyphs shouldn't greatly affect file size, thanks to composites, subroutines, and class kerning.
Still, why would that make anyone happier than just PUA-encoded alone?0 -
If the OT lookups substitute for PUA-encoded glyphs, I thought searching through the text was impaired? As aforementioned.
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?1 -
In the cases when the OT feature lookups are being used to access glyphs, it doesn't much matter whether the glyphs are also encoded, or not.
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
T1 -
I've always used PUA encoding for alt glyphs, but have been thinking of stopping that practice. Is this a bad idea after already using PUA encoding for previous fonts? I'm basically just trying to figure out if I'm stuck and should just forever continue to use the same custom encoding table that assigns PUA's for alt glyphs since I already have started.
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.
0 -
Before this evening, I never even heard of PUA, then I had a very upset Creative Market customer read us the riot act about being swindled because we didn't PUA encode the fonts. I was floored!
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.py0 -
Yeah, I've been yelled at a few times for having unencoded glyphs. I wish they'd direct some of their voices towards application developers who don't support the OpenType features they want to use.3
-
Stuart Sandler said:Before this evening, I never even heard of PUA, then I had a very upset Creative Market customer read us the riot act about being swindled because we didn't PUA encode the fonts. I was floored!
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.3 -
Stuart Sandler said:Before this evening, I never even heard of PUA, then I had a very upset Creative Market customer read us the riot act about being swindled because we didn't PUA encode the fonts. I was floored!
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
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_Registry1 -
For clarity, I perceive this as a custom font generation request but have no intention of updating my retail library based on the needs of a Silhouette or Crickut super user. I just want to know how to do this if more folks ask.
@Rainer Erich Scheichelbauer How is this done in Glyphs?
0 -
Stuart Sandler said:How is this done in Glyphs?0
-
A lot of the PUA requests I get are people using a plotter/cutter suites. Almost all of these applications support SVG/EPS import so that could be a workaround. These customers are unlikely to have access to expensive vector apps like Corel Draw or Adobe Illustrator. I usually direct them to LibreOffice Draw as it lets the user easily enter text, covert to curves and export SVG. But there's no OpenType feature menu. The user needs to add tags manually to the font name. For example: Fontname:swsh=1
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?
2 -
There’s a fantastic typography plugin for LibreOffice I use all the time. That makes many of the most common OpenType features really easy to access by inserting the code+value to the font name. Anything else, as you mentioned, @Ray Larabie, can be added manually.1
-
For Windows users, Serif PagePlus X9 for only £20 or $25 is the best value that I know of for OpenType support, with SVG export. It is a lot easier to access OT features than it is in LibreOffice. It can also access unmapped glyphs from it's Insert Character dialogue.
1 -
Ray Larabie said:...
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?
...
Pretty damn good OT Feature support. Only CorelDraw has a better mechanism for accessing alternates. AD has a glyph browser as well.
3
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 801 Font Technology
- 1K Technique and Theory
- 618 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports