Private Use Area for ligatures and alternates

Adam LaddAdam Ladd Posts: 18
edited February 15 in Technique and Theory

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:

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

  2. 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!

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...
    1. 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.
    2. 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.
    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. 

    I would advise going with unmapped. Most users could not care less about OpenType features, and don't know what the PUA is. 
  • 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.
  • 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.  :(
  • 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)
      As you can see, this is a recipe for all kinds of problems.
    • James PuckettJames Puckett Posts: 1,363
      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.
    • Adam LaddAdam Ladd Posts: 18
      edited February 16
      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).
    • 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.
      Perhaps a good distillation for when it may be more appropriate add the PUAs than not. Display fonts can be more accommodating. But a heavy-lifting type family would be more of a concern because of the broken functionality.
    • edited February 16
      @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.
    • 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.
    • 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?
    • 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?
    • 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

      T
    • 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. 
    Sign In or Register to comment.