Why not simply using a UCS to GML mapping, or whatever is now defined in later HTML DTD.
Simply?

I'm not sure I need it. The environment, which doesn't change anything I've mentioned, is:
1. Users have to be able to type the 8-bit ASCII name, with any DOS editor (e.g. QBASIC /EDIT) or OS/2 editor.
2. Based on codepage 850, the code may append a superscript 1,2 and/or 3 to names. Those characters aren't available when e.g. codepage 860 is in use.
3. Netscape is the targetted main (local) browser, but the HTML files are available online too. So far there is no specific reason to exclude more desktop environments, like SeaMonkey for OS/2, Qupzilla for Unix or Microsoft's latest Internet Exploder.
4. It looks likes my copy of Netscape for OS/2 stopped counting UTFs at 8 and Windows at 1250. Otherwise I would already have picked UTF-9 to replace ISO-8859-1. Hence the question if UTF-8 or Windows-1250 would be better ... or at least newer than ISO-8859-1.
5. My code does assume that codepage 850 is in use. Checking that is an on-topic coding style improvement: if the codepage is assumed to be 850, then check that the codepage is 850.
6. There may be conflicts, but so far there are none. I'm not using the Portugese codepage 860, but I'm using Portugese names.
7. So far all characters have a
&xxxxx; equivalent.
8. So far all characters are supported by codepage 850.
9. The app would have te be customized per user now. Each new high-ACII character in a new name requires a new case: to be appended. If a German user with a German keyboard would type München, which may introduce the first "ü", then I'm willing to insert code to replace their "ü" by an "¨". In other words: I'm not supporting any character of my own codepage, and not all characters of of all (single-byte) codepages.
10. Users will use names which are normal to them. If I would visit gazprom.com to find out its official name, I'll visit the EN or DE section, and not the RU section. I'll use Gazprom instead of Gasprom or a Cyrillic name. The reversed would be true too, so for a Russian user I may have to deal with all of ther Cyrillic characters.
It sounds more complicated than it is, but I will check the codepage. If the codepage is not 850, then the question still is if I can always try to stwitch to that codepage to produce my 850-based output, even with some Japanese OS/2 install.
I will look at the "simply"-stuff anyway, if anything to learn about a few APIs, but its added value may be NULL. I don't even support all typable characters of my codepage 850. I guess that the added value will increase if producing nnn; codes for all of the world's characters is suprisingly easy and simple.
Netscape remains a requirement, regardless of more modern charsets of other browsers. HTML was the selected output format for "reports", and Netscape for OS/2 is fast for local browsing and has ugly but rather clear TABLEs.
The superscript characters 1,2 and 3, which may be appended to names or text, represent foot notes. So I may have to change that code too, to use e.g. ³ instead of an appended single character. That way supporting e.g. codepage 860 will be easier. This change may be quite hard, because the code shouldn't change "¹" to "¹" next.
It's not possible to map every codepoint directly between different 8-bit codepages.
I've seen that with the superscript characters. Hence the possible rewrite of of the superscript-code...

To-do:
1a. Check the codepage
1b. Consider trying to set the codepage to the assumed codepage 850, if it's not 850.
2. Try to change the superscript-code, to avoid those single characters and make it easier to support more codepages.
3a. Take a look at the APIs mentioned earlier.
3b. If it is both easy and useful to use those APIs, then consider doing that it.
For output of ISO-8859-1 the IBM-819 codepage can be used. Windows 1250 is similar to IBM-852 for central/eastern Europe. For IBM-850 or other western codepages it would be better to use 1252.
As stated earlier, the number of visible Netscape codepage suppport is limited. I'm okay with ISO-8859-1, but of course a more modern alternative supported by Netscape would be even better. Apparently UTF-9 was such an alternative, but Netscape's last offer seems to be UTF-8.
Netscape isn't a must-have, but typically generated HTML files are browsed as local files. With Netscape opening such a file always is a matter of seconds, and output is "designed"with and for Netscape/2.
Oh, yet another reason to write a customized HTML generator for e.g. a theoretical user from Portugal is that generic text will have to be translated too. Column headers, and so on.
The HTML code itself won't be interesting nor on-topic. Rexx isn't that aware of codepages, but can create the same output. Converting the code to C didn't affect the HTML code.
Homework... Check the codepage, consider changing it to 850... Try to svoid single superscript-characters... Study APIs...