I tried mapping it to 11111 (just a test) and that it accepted but if I then do “test font” and do alt+11111 I get something entirely else …
It is possible that you mapped to 11111 using hexadecimal and then used Alt using decimal, so it would not work. I just tried the Test Font facility of Font Creator 5.0 with my Quest text font and Alt 59143 which is a ct ligature and the system refuses. It appears that the Test Font facility will not accept Alt values above 255. Trying the Alt test in Microsoft WordPad might be better.
As a test to get into the swing of things, perhaps you might like to try a copy of my Quest text font, which is a free download from the following web page.
http://www.users.globalnet.co.uk/~ngo/fonts.htm
Quest text also has its own thread in the Gallery in the High-Logic webspace.
http://forum.high-logic.com:9080/t/quest-text-font/671/1
Trying Alt 59143 should give you the ct ligature design. That corresponds to U+E707 in the Unicode Private Use Area.
So, if you were using that encoding, map your character to U+E707 in Font Creator, that is use 0xE707 in the text box of the Mapping panel of the Properties facility, then install the font and use Alt 59143 within WordPad.
Certainly. if you were to use U+E707 for one of your symbols that would be incompatible with my use of U+E707 for a ct ligature glyph. However, that does not matter as such, since each person may use the Unicode Private Use Area as he or she wishes. However, if there is any possibility that you would like to publish your symbols and for your symbols to be included in other fonts, such as Quest text, then choosing a different encoding is a consideration which, though not a Unicode requirement, would be a practical consideration. However, various people use the Private Use Area for various things so finding a coding which clashes with nothing else anywhere may be a difficult task, if indeed it is possible. I would recommend that a choice somewhere within U+E000 to U+EFFF would perhaps be best as that is below the U+F000 to U+F0FF range which is used in part by Microsoft Symbol fonts and below the upper reaches of the Private Use Area which are more likely to be used by internal codes within proprietary software packages due to the Unicode guidelines of how to use the Private Use Area which are in Chapter 15 of the Unicode Standard mentioned above.
I would suggest that, if your system can handle (16-bit) Unicode characters rather than just 8-bit characters, that mapping of your own characters into the Private Use Area would be better than placing them at arbitrary positions. This is not only an aesthetic consideration as some software may well make presumptions about a character based on its Unicode code point, such as it being a right-to-left character or whatever, so using the Private Use Area is safer from a programming standpoint as well.
As to using Access, I have only used Access a little and then only in learning exercises. Although I am a programmer I have not used Access in a programming manner. Access is made by Microsoft. Some parts of the Unicode Private Use Area can sometimes be handled strangely by some Microsoft products. This is because of a legacy of they using some parts of the Private Use Area for Chinese or Japanese or Korean and some Microsoft products in some circumstances sort of presume that someone using the Private Use Area is intending to use those characters. The best way is to try a coding and test it and if it works then fine, but if it goes strange, like needing the space bar pressed before a character is displayed, then choosing a different encoding is the best thing to do!
I hope that this helps.
William
. . . . DOUBLE EXCLAMATION MARK
. . . . TRADE MARK SIGN
. . . . UP DOWN ARROW
(257) . . . . WHITE SMILING FACE
. . . . FEMALE SIGN
. . . . MALE SIGN
(262) . . . . BLACK SPADE SUIT
(261) . . . . BLACK CLUB SUIT
(259) . . . . BLACK HEART SUIT
(260) . . . . BLACK DIAMOND SUIT