Generally speaking, this has to be determined by criteria external to the Unicode Standard. Such criteria have to take into account user expectations, and must reflect the degree to which a certain shape is normative in a particular usage. The zodiac symbols are a good example, because users employ both symbolic and graphical representations; hence the Linotype Astrology font approach makes good sense in supporting both usages.

Where a Unicode character name does specify something like particular colour arrangement -- e.g. black on white -- then that can usually be expected to form user expectation, such that someone may legitimately complain if this character is represented in white on black. If U+26E8 were simply named CROSS ON SHIELD, then I think reversing the colours would be legitimate and while some users might not like it they would have no grounds to complain.

Note that some mathematical symbols in Unicode have recognised variant forms that are meant to be displayable using Variation Selector code. This is supported in OpenType using a format 14 cmap table, which maps combinations of character code and VS codes to glyph variants.

Thanks for the reply. Your position on U+26E8 makes sense.

More generally, what I'm trying to decide is, when encoding a pi font, whether it's better to assign non-PUA unicode values to symbols only when an exact match can be found, or whether a 'close' match is sufficient.

I'd prefer to avoid PUA codepoints where a more appropriate assignment exists. The big problem here, though, is figuring out exactly what constitutes a close match. The standard doesn't always specify why certain symbols were encoded in the first place, which makes it difficult to figure out whether a precise shape might be expected in some technical contexts.

André

As I hoped I tried to convey, there is no general answer to your question independent of the usage of the font.

> The standard doesn't always specify why certain symbols were encoded in the first place

I go to
http://search.cpan.org/~ilyaz/UI-KeyboardLayout-0.13/lib/UI/KeyboardLayo...
and I see
http://scriptsource.org/cms/scripts/page.php?item_id=entry_detail&uid=ng...
http://scriptsource.org/cms/scripts/page.php?item_id=entry_detail&uid=kt...
These are 2 examples of how to find documents specifying the “whys” of encoding (the nDDDD ones). The first page was found via going to Scripts/Cyrillic/search-for-Unicode Status; the second one can be reached via Scripts/Latin. I cannot find “Unicode Status” for “Miscellaneous symbols” though… Maybe googling for site:scriptsource.org "unicode status" "miscellaneous symbols" (or some such) may help you…

I see
http://scriptsource.org/...
http://scriptsource.org/...
These are 2 examples of how to find documents specifying the “whys” of encoding (the nDDDD ones). The first page was found via going to Scripts/Cyrillic/search-for-Unicode Status; the second one can be reached via Scripts/Latin. I cannot find “Unicode Status” for “Miscellaneous symbols” though…

The ScriptSource community have been adding Unicode Status pages for various scripts just because the background information for characters is, as you've found, difficult to find. I'm glad you have found the info helpful, but please understand that this is a work-in-progress -- and we invite anyone with relevant knowledge to contribute to the project.

I would point out that for characters that have been in Unicode for a long time documentation is both harder to find and, in a practical sense, generally less important to developers. For that reason ScriptSource contributors have focused on characters added more recently.

Case in pont: the zodiac characters you mention (U+2648, U+2653) are very old -- dating back to Unicode 1.1.