In my browser I see some figures bombed into the headline at the place of the quotation marks … I’m verry sorry.
(It seems to get right in the topic’s list)

I used *english* quotation marks. ;-)

That's best answered by Adam.

However, I think you are lamenting about the wrong thing.
The issue is not that FL favors some PUA schemes over others. I assume that if FL would get hold of others they would include them too.
The issue is that the presence of special PUA schemes suggests they are kind of "standards" that type designers should address -- rather than discouraging use of PUA altogether.

Area201D
That's where the aliens are kept, is it not?

A more helpful pop-up would be the Open PUA code points, rather than the ones already spit on.

… if FL would get hold of others they would include them too.

You can’t incorporate different schemes for one and the same space.

… the Open PUA code points, rather than the ones already spit on.

The use of this area is subject to constant change. Since the area has been declared as “private” (which is quite silly in itself, but let’s leave this aside) no authority can claim to define its content. The only sensible solution I see is to just omitt any subheadings under “Privat Use Area”. Otherwise FL suggests they are kind of “standards” that type designers should address which would be misleading.

This is informational. If a major software developer has used PUA codepoints for some particular purpose -- most likely legacy -- then there is a risk that these codepoints might come with assumptions attached in that software, and it would be a good idea to avoid using these particular PUA codepoints. Alternatively, if you specifically want to make a font that is compatible with the use of PUA in particular software, then you want to know what this use is. And it would be perfectly possible for FL to expose multiple and conflicting uses of PUA codepoints in this way. All you are looking at is a labelling system.

John, do correct me if I'm wrong. If these areas in the PUA are 'taken', I can think of two possible problems.

1st: if one puts a character into one of these areas and has to ascertain it's a certain glyph, that would make it part of the standard Unicode set -- not defined by unicode.org, but that doesn't matter because we have to adhere to stay 'compatible' anyway -- no matter who created the rule, you'd have to stick to it "to stay compatible".

2nd: if these code points are assumed to contain a certain glyph, where would one find which glyph to put where? One would hope that it gets put into the new up-and-coming FL, added to the code page templates.

See page 11 of this Unicode PDF:
http://unicode.org/book/ch13.pdf

Unless one actually has a need to produce a font that is compatible with a particular company's use of PUA codepoints, it is best to avoid that relatively small set of codepoints, just in case some piece of software is making assumptions about those codepoints. That said, the nature of the PUA is explicitly such that neither software developers nor font developers should expect any degree of safety in making assumptions about the use of any PUA codepoint beyond their own internal use. The basic rules of the PUA apply as much to the ‘Corporate Use Sub-Area’ codepoints as to any other PUA codepoints, so there is nothing to prevent another company or an individual using the same codepoints for other purposes or even claiming them as their own ‘corporate use area’.

Corporate use of the PUA has occasionally been an issue for me in my work, but only because I'm making fonts for companies that have already made use of some PUA codepoints and I need to make sure that I use fresh ones that their software does not associate with other characters.

The logic behind this, I'm guessing, is that these companies have made regular usage of those code points and because they produce software used by millions of people, those areas have been "reserved" for them by FontLab.

Adobe uses regular regions of the PUA for small caps, oldstyle figures, swash characters, etc., which have not been assigned specific Unicode points. While condoning to their lead isn't a standard practice, their labels in FontLab was likely due to convention rather than promotion.

Anyway, those big companies developed the common font formats that we all use today — might as well give them first dibs.

John: This is informational.

Thank you but I don’t want to be bothered by MS or Adobe product “information” while I’m at work. The more if I happen to deal with that codespace in a way different from how others do it.

… that neither software developers nor font developers should expect any degree of safety in making assumptions about the use of any PUA codepoint

Come on. You know perfectly well that we produce fonts incorporating many hundreds of PUA codepoints under the assumption that they are of *particular* usefulness for our clients – who rely on it.

All you’ve said so far does not touch the fact that there is no decent reason for FL to label any PUA section in any specific way. Moreover, nobody has a right to label parts of that area with his own name and the suffix “reserved”, this is plain impertinent.
The very nature of this area is to be *used* not *reserved.

For example: some of the so-called SIL-parts contain characters (e.g. in Dolous SIL) which moved into the official standard a time ago. What possible reason should anybody have to take care of that outdated occupation?! Rediculous. (except SIL staff, of course)

So the current FL practice remains sheer advertising and this is highly questionable. Hallo, Fontlabbies, just tell us you’ve got $$$$$$$$$ for it and we close this in peace ;-)

You know perfectly well that we produce fonts incorporating many hundreds of PUA codepoints under the assumption that they are of *particular* usefulness for our clients – who rely on it.

You may. I avoid PUA like the plague. The only time I ever use PUA is for non-semantic glyphs such as ornaments.

I don't think there's any nefarious plot going on here - but then again, I am from SIL. I'm actually surprised to see this documentation of the SIL PUA ranges in FontLab. We didn't ask for it. It looks like Fontlab is only trying to serve their customers by gathering together info on the most common uses of the PUA. SIL's use of the PUA is publicly documented and follows the guidance of the Unicode Consortium.

Like John, we try by all means to avoid using the PUA. Most often it has been used as a practical temporary way to encode language data during the sometimes lengthy process of getting new characters accepted into Unicode. Around 80% of our PUA assignments are characters that have now been accepted into Unicode, and the use of them as PUA characters has now been deprecated (no longer recommended). Our detailed deprecation strategy is available, and explains why we keep characters at both new and old codepoints in our fonts. The other 20% are characters that Unicode rejected, ones that we have not yet proposed, or ones we ourselves have later deprecated.

FontLab's acknowledgment of the most common PUA uses is not advertising. They are only trying to let font developers know about them so they can avoid those places if they have customers that already use MS, Adobe or SIL fonts - or use them in the same way. Note that since this is a Private Use Area you can feel free to use the range however you choose. Nothing bad will happen if you assign random chars to fall in the 'SIL PUA'. :-)

Viktor, what you say is all perfectly reasonable. This wasn’t about who uses the PUA how and for what and for how long, what is put in and what is deprecated. All this is what the PUA is obviously intended for.

Accounting what has been said up to this point I’m the more convinced that it should be *avoided* to ascribe *any* kind of prescription to the PUA range. I’ll try to make the FontLab colleagues notice that.

John: I avoid PUA like the plague.

You may. I use the PUA when this is beneficial for those who buy my fonts. And some of them do use this space very seriously, may it be decent in your opinion or not. It’s just a matter of practice and agreement.

Thanks guys for your comments.

Andreas, a massive number of the PUA-encoded glyphs in your excellent survey are presentation forms of letters plus diacritic marks that have standard Unicode encodings using combining mark sequences. While I understand that there have been difficulties in the past in reliably rendering combining mark sequences, these difficulties have very largely disappeared, and maintaining non-standard encodings for these diacritic letters is very bad text processing and interchange practice. All you need is one user receiving the text and either displaying it in a font with different PUA usage or being unable to display it at all, and the whole ‘practice and agreement’ falls apart. Standards exist for a reason, and as soon as something is encodable via the standard private encodings should be deprecated as quickly as possible.

Yes John what you say is perfectly correct and most alert. And yet, you miss the point.
Ask Odd Einar Haugen and Jost Gippert if you wish. It was not my idea to encode these letters.

Andreas,

> Thank you but I don’t want to be bothered by MS or Adobe product “information”
> while I’m at work. The more if I happen to deal with that codespace in a way
> different from how others do it.

If you place your own copy of "uranges.dat" in the Data subfolder of the FontLab Studio shared user folder, FontLab Studio will automatically use that. Feel free to customize that file and remove any range labels that you feel "offensive". This is precisely why FontLab Studio is very customizable.

Since Adobe, Microsoft and SIL have publicly documented their use of the PUA, we are providing their assignments so that users of FontLab Studio who would like to adhere to their "quasi standards" can easily access them. You can publish your own PUA mappings in the "urange.dat" format on your website so that users who would like to take advantage of your use of the encoding space can easily do that.

I do not consider our information any more "promotional" than the fact that we use the Adobe Glyph List for New Fonts rather than providing completely invented glyph names -- because there is software in the world that actually makes use of those mappings. We try to be compatible with major software vendors' products so that the fonts our users generate can be, too. That's it.

Regards,
Adam

Thanks to Mr. Twardoch for stepping in!
The suggestion to customize that list is indeed a very valuable one. I tried out and … further description is in this new topic .

Since Adobe, Microsoft and SIL have publicly documented their use of the PUA, we are providing their assignments so that users of FontLab Studio who would like to adhere to their “quasi standards” can easily access them. You can publish your own PUA mappings in the “urange.dat” format …

And yet, it still seems more decent to me if FL does *not put any labels* under [PUA] at all by default. As it is, it is suggestive for the avarage user and that kind of suggestion is possibly misleading.

Andreas,

indeed, it is suggestive for the average user, and it has its reasons. One of the reasons is that some PUA codepoints actually are hardcoded into Windows' CJK processing so using them may result in non-functional fonts. For more details, see http://scripts.sil.org/PUACharsInMSSotware

Other major vendors also make use of certain PUA codepoints, as documented here: http://scripts.sil.org/VendorUseOfPUA

Since this may have repercussions on the functionality of fonts made by independent vendors, we think that labeling the PUA subsections has its merits.

Cheers,
Adam