Understood but I've been told by people at FontLab to not use the PUA for alternate glyphs therefore the glyphs exist as name only with no unicode value so customers that don't have Adobe products may not be able to access the alternates even if you have a proper substitution in your opentype features.
The only problem of using the PUA I can think of would be your glyph unicode values may conflict with other fonts that have glyphs occupying the same spaces, when a customer switches from one font to another their letters may change or drop out.
For this reason alternates shouldn't be used in large bodies of text where you'd end up making too many corrections because you changed to a different font family.
Glyphs that are unmapped can't be copied and pasted, Adobe products are an exception allowing you to copy and paste unmapped glyphs between Adobe applications.
Now there's a problem with Windows 8.1, I'm finding the salt and swsh features don't work properly in Adobe products installed under Windows 8.1, for example when you double click on N.alt you'll get the regular N instead, click on N.swsh and you'll get the regular N again.
My OT features are correct and work perfect under previous versions of Windows using Adobe CS5.
The solution around this is to place your stylistic alternates and swash letters as a stylistic sets ss01, ss02 etc. and remove the original salt and swsh features completely.
If there's ever a problem with the Adobe glyph map not working properly after an operating system upgrade the customer could still access alternate glyphs using a third party character map. If the alternate glyphs are unmapped the customer may be out of luck and that font that you worked hard on creating beautiful alternates is now a piece of junk from the customer's point of view.
My question still is, should we use the PUA or not? What are the potential problems I'm told will occur if I do use the PUA?
If I unmap the alternate glyphs and they're no longer in the PUA the number of people that can access the alternates has dropped dramatically.

The biggest problem with PUA is that it results in mangled text. PUA codepoints for glyph variants get inserted into text, replacing semantically meaningful character codes. This means that documents using PUA codepoints can't be reliably searched, sorted, spellchecked, or subject to any other normal text processing function such as changing fonts, copying and pasting into email or a plain text environment, or even easy and consistent editing.

As a general principle, don't use PUA for anything with semantic content. So yes, it is okay to use PUA for ornaments or for a client's logo in a font, but as soon as you have text entities that need to be interchangeable, you should be avoiding PUA. The only times I ever use PUA for semantic content is when I have a client who is working with a closed production workflow that requires it, and even then I do everything I can to encourage them to find a different workaround and to avoid using the PUA encodings whenever possible.

Thanks John for your explanation but it raises another question, if the PUA is not where you place alternates that may be used as text then where do you place them or what unicode range would you put them under?
I see some foundries leaving their alternate text based glyphs as name only, the unicode value is blank so there's no code page where the glyphs may be found.
Wouldn't this cause the same problem for search ability, copying and pasting etc.?
Where can you put alternate semantic glyph content in your font or should the glyphs hang with no encoding?
So if alternate semantic glyphs are present in the PUA they can't be processed like normal text but if the glyphs have no encoding and exist as name only am I correct in saying that they also can't be processed like normal text?
I'm also wondering why Adobe Minion Pro from 2010 has just over 400 semantic glyphs in the PUA of the font.
I'm close to releasing a new multi weight font family with lots of alternates and I want it to be right when it goes out.
Thanks again for your comment,
Michael

I researched the Windows 8.1 issue with Stylistic Alternates, when the substitution line below is entered in the salt feature of an Opentype font it will work in Windows 7 but not in Windows 8.1, when you click on A.alt2 or A.alt3 you'll get A.alt of the regular A appear at your cursor.

sub A from [A.alt A.alt2 A.alt3];

Only single substitutions will work in the salt feature in Windows 8.1

sub A by A.alt ;

If you have multiple alternates of a glyph the solution is to place them in a stylistic set such as ss01
If you have multiple versions of swash letters then also put those into a stylistic set.

The test was done with a single Opentype font generated from
FontLab 5.2.1 build 4868 and tested with Adobe CS5 in Windows 7 and Windows 8.1

Minion Pro was one of the last fonts which Adobe released before they revised their own position on using PUA codepoints, so that's why you find them in Minion but not in subsequent fonts.

Substitutions of the type sub X from [X X1 X2...] are really best reserved for the aalt feature rather than salt or ssnn.

Concerning your question about accessing alternates, remember that unicode defines characters, not glyphs, which is why it isn't necessary to assign unicode values to alternate glyphs except perhaps for compatibility with older applications.

If you have a font containing A and A.salt, things will behave differently depending on whether you assign A.salt a PUA value or give it no unicode value at all.

If you assign it no unicode value, then any documents containing that character will represent either A or A.salt by the same unicode value (U+0041) with some indication of whether the 'salt' feature is turned on or off. The alternate glyph will only be accesible via the salt feature meaning you won't be able to make use of it in non-OT savvy applications.

If you choose to assign A.salt a PUA codepoint (let's use U+E000), then the character will be accessible either by entering U+0041 and applying the salt feature (in applications which support this) or by entering U+E000 directly (an option available in all applications). However, if a user chooses the latter option, the glyph which appears won't be interpreted as the character 'A' but as the semantically undefined character U+E000. Therefore, using PUA points will allow alternates to be accessed in non-OT savvy applications, but the alternates won't be searchable, spell-checkable etc. Moreover, you're creating a risk that even when using OT-savvy applications a user might select the character from a character map (which, depending on the application, might result in U+E000 rather than U+0041) rather than via OT features without realising the consequences of this action.

So, I'd say that if you need to support non-OT applications, you can assign PUA codepoints for cases where the user wants to *display* the alternates without necessarily needing to search the document, but that if you do so you'd want to stress in your readme file that alternates should always be accessed using OT features unless its absolutely impossible to do so and then hope that people actually read the readme file.

Maybe that will help clarify John's points.

André

The whole reason why the character/glyph distinction exists is so that a cleanly encoded semantic character string can be represented by an arbitrary collection of glyphs. So as soon as a font contains more than one way to display a single Unicode character, it makes sense that you need something like OpenType Layout glyph processing that maps from the default encoded glyphs (from cmap) to the unencoded variant. Trying to come up with a workaround to access variants without glyph processing inevitably means breaking character encoding.

>Moreover, you're creating a risk that even when using OT-savvy applications a user might select the character from a character map (which, depending on the application, might result in U+E000 rather than U+0041) rather than via OT features without realizing the consequences of this action.<

So by not placing glyphs in the PUA it looks like we're protecting people from making a critical mistake they may not be aware of and that's using an alternate glyph for text purposes you shouldn't use alternates in.

A professional trained type designer once told me if include alternates in my font I needed to plan them all in advance and create a custom encoding file in FL and this would build the database creating the alternate glyphs with codepoints, however when you went to glyph properties the unicode field was blank for each alternates.
Creating encoding files is fine if you've got many people working on the project but I work solo and I get inspiration for new alternates along the way.
To me the custom encoding file looks like a script for Cmd+G or Ctrl+G, if there's a unicode value to go with the glyph name in the encoding file then FL will create the glyph and assign the correct unicode value.
Alternate glyphs will be created however there will not be a unicode value assigned so it will hang by name only, apparently it's fine for a glyph to exist and be usable with out a unicode value in applications such Adobe CS and CorelDraw.
When it comes to making alternates usable in applications such as MSWord, forget it, the customer using alternates where they shouldn't creates support emails which we want to keep to a minimum.

When a customer asks why they can't access alternate glyphs in MSWord or Windows character map I'll have to say sorry it doesn't recognize them.

I did find a pdf from Adobe dated 2006 that said they no longer put glyphs in the PUA but in 2011 Adobe's Minion Pro still shows alts in the PUA however nothing from Adobe since uses the PUA.

Thanks guys for your assistance it's been a long road getting back up to speed after a long eighteen years of care giving, I don't know how I ever found time to make fonts at all.

Michael

It's not true that MS Word cannot access unencoded alternate glyphs.

The latest versions of Word for Mac and Word for Windows provide access to some OT features such as different figure styles, stylistic sets (only one at a time, though), ligatures, and contextual alternates. These work even when alternate glyphs are unencoded. Unfortunately, many OT features are missing, such as (true) small caps, titling alternates, swash alternates, discretionary ligatures, historical alternates, stylistic alternates, etc.