Private Use Area for ligatures and alternates

Adam Ladd
Adam Ladd Posts: 263
edited February 2017 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!

Tagged:

Comments

  • Georg Seifert
    Georg Seifert Posts: 674
    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...
  • Bhikkhu Pesala
    Bhikkhu Pesala Posts: 210
    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. 
  • Ray Larabie
    Ray Larabie Posts: 1,431
    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.
  • Bhikkhu Pesala
    Bhikkhu Pesala Posts: 210
    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 Puckett
      James Puckett Posts: 1,992
      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 Ladd
      Adam Ladd Posts: 263
      edited February 2017
      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).
    • Adam Ladd
      Adam Ladd Posts: 263
      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.
      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.
    • Denis Moyogo Jacquerye
      Denis Moyogo Jacquerye Posts: 191
      edited February 2017
      @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.
    • Adam Jagosz
      Adam Jagosz Posts: 689
      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.
    • Thomas Phinney
      Thomas Phinney Posts: 2,883
      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?
    • Adam Jagosz
      Adam Jagosz Posts: 689
      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?
    • Thomas Phinney
      Thomas Phinney Posts: 2,883
      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
    • Josh_F
      Josh_F Posts: 52
      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. 
    • Stuart Sandler
      Stuart Sandler Posts: 361
      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
    • Ray Larabie
      Ray Larabie Posts: 1,431
      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.
    • Bhikkhu Pesala
      Bhikkhu Pesala Posts: 210
      edited February 2018
      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
       I would advise not being intimidated by an irate customer. The correct practice is not to encode these additional glyphs. Palatino Linotype, which was created in 1996, has a whole bunch of uncoded glyphs. Gabriola, which is much more recent, also does this

      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. 
    • Jess McCarty
      Jess McCarty Posts: 97
      edited February 2018
      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
      It's not best practice but with PUA encoding having become so widespread in display fonts, and with so many retail customers demanding it, I've reluctantly started to adopt PUA encoding for alternates within new releases. 

      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
    • Stuart Sandler
      Stuart Sandler Posts: 361
      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?
    • Rainer Erich Scheichelbauer
      Rainer Erich Scheichelbauer Posts: 157
      Stuart Sandler said:
      How is this done in Glyphs?
      There is a self-explanatory script in my repo that does this: mekkablue scripts > Glyph Names > Add PUA Unicode Values to Selected Glyphs.
    • Ray Larabie
      Ray Larabie Posts: 1,431
      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?
    • AbrahamLee
      AbrahamLee Posts: 262
      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.
    • Bhikkhu Pesala
      Bhikkhu Pesala Posts: 210
      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.


    • Mike Wenzloff
      Mike Wenzloff Posts: 106
      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?
      ...
      Affinity Designer by Serif. Available for both Mac & PC. About $50 USD if not on sale (which seems to happen with new versions).

      Pretty damn good OT Feature support. Only CorelDraw has a better mechanism for accessing alternates. AD has a glyph browser as well.

    Categories