Riamus2:
mIRC substitutes fonts if the font does not appear to display the character properly. It will choose another font on your system in an attempt to correctly display that character. I don't know the inner workings of that, but I have a feeling that it's based on how the font you're using is written. If mIRC can't tell if the font supports a character, it will try another font. It could be that Terminal isn't as compatible with mIRC's font-linking as other fonts.
I wish it were. Terminal is the only bundled CP437 font in Windows, is the default cli font, and is commonly used by SSH/telnet software. Making it well known. It should be properly supported.

Riamus2:
The characters you're attempting to display that aren't displaying at all are not valid characters in Unicode, so they will not display. That's expected when dealing with Unicode. That being said, most (all?) of those characters should have alternatives in Unicode that you can use instead by replacing the character with the Unicode equivalent of it.
Alright, I'm learning. In deed, I see what you mean here -- 128-159 have no defined glyphs under Unicode, and are the C1 control codes.

But this brings back my previous question, only now in the inverse: is it a bug, then, that characters 129, 141, 143-144, and 157 do appear? (Refer again to my ASCII chart screen captures with the green <EOF>'s.)

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

And finally, to both of you:

Riamus2:
That being said, most (all?) of those characters should have alternatives in Unicode that you can use instead by replacing the character with the Unicode equivalent of it.
argv0:
All of the "defacto standard" glyphs in codepages should have Unicode equivalents, ultimately, this is the point of having a universal character encoding. For CP437, the list is here: http://en.wikipedia.org/wiki/Code_page_437

That said, $utfencode/$utfdecode should be able to perform conversion to and from codepage encoding to UTF-8, so you could use that, AFAIK.
The glyphs for CP437/CP1252 bytes 128-159 do in deed have Unicode points. So yeah, while 80h (128) may have no glyph under Unicode (and be invalid as a single byte by itself under UTF-8), that byte's glyph under CP437 (Ç) exists in Unicode as 00C7, encoded by UTF-8 as bytes C3 87 (195 135). And sure enough, $utfdecode($chr(195) $+ $chr(135)) causes Ç to be displayed (albeit not in the Terminal font in a window whose font is Terminal).

And the next four bytes (81h, 82h, 83h, 84h / 129, 130, 131, 132), which are ü, é, â, ä under CP437, exist in Unicode as 00FC, 00E9, 00E2, 00E4 -- encoded by UTF-8 as C3 BC (195 188), C3 A9 (195 169), C3 A2 (195 162), C3 A4 (195 164). And also sure enough, $utfdecode($chr(195) $+ $chr(188)), $utfdecode($chr(195) $+ $chr(169)), $utfdecode($chr(195) $+ $chr(162)), and $utfdecode($chr(195) $+ $chr(164)) do likewise properly display ü, é, â, and ä -- albeit again not in Terminal in a window whose font is Terminal.

But notice that in those cases, I'm decoding. Where everything is going to hell for me is when I attempt to encode. If I try to encode:

//echo Result: $utfdecode($utfencode($chr(128))) -> displays invisible glyph (window buffer save-to-file confirms it is C2 80, the UTF-8 encoding for 80h)
//echo Result: $utfdecode($utfencode($chr(129))) -> displays invisible glyph (window buffer save-to-file confirms it is C2 80, the UTF-8 encoding for 81h)
//echo Result: $utfdecode($utfencode($chr(130))) -> displays invisible glyph (window buffer save-to-file confirms it is C2 80, the UTF-8 encoding for 82h)
//echo Result: $utfdecode($utfencode($chr(131))) -> displays invisible glyph (window buffer save-to-file confirms it is C2 80, the UTF-8 encoding for 83h)
//echo Result: $utfdecode($utfencode($chr(132))) -> displays invisible glyph (window buffer save-to-file confirms it is C2 80, the UTF-8 encoding for 84h)
//echo Result: $utfdecode($utfencode($chr(128),437)) -> displays € in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(129),437)) -> displays ü in Terminal font if Terminal selected,  if any other font selected
//echo Result: $utfdecode($utfencode($chr(130),437)) -> displays ‚ in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(131),437)) -> displays ƒ in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(132),437)) -> displays „ in non-Terminal font even if selected font == Terminal

So:

1.     If I don't tell $utfencode which codepage to use, it produces what I believe is UTF-8 encoding of literal bytes 80h-84h, which seems right
But:
 2a.    If I do tell $utfencode which codepage's glyphs to encode for bytes 128-131 (437's), it instead encodes codepage 1252's glyphs for those bytes (bad!)
2b.    ...with the odd exception of 129, one of those "it appears anyway" bytes in my previous tests (again, see screen captures with all the green <EOF>'s)

In any case, I can't see where I'm going wrong with my use of $utfdecode/$utfencode. Yet the unexpected is happening.

*time passes*

Alright, I have discovered something strange:

I learned of $window(windowname).fontcs in the help file, and tested it in various windows. For some reason, it is returning nonsensical codepage values. In mIRC windows using Unicode fonts like Arial or Bitstream Vera Sans, it returns "0". But in a window using the non-unicode (256-character) Terminal font, it returns "255". It also returns "255" for the non-unicode (256-character) Roman font. Yet for several other non-unicode (256-character) fonts on my system -- CP437 9x16, MS Sans Serif, System, Courier -- it returns "0". Even more strangely, for MS LineDraw (also a 256-character non-unicode font), it returns "2", and for another 256-character non-unicode font I have, called "bright", it returns "44".

I don't understand any of that. Those aren't valid codepages. What I did discover, however, is that in a window using the Terminal font, I can now produce the Terminal's (CP437's) glyphs for bytes 128-132 if I tell $utfencode to use "codepage" 255 instead of 437:

//echo Result: $utfdecode($utfencode($chr(128),255)) -> displays Ç in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(129),255)) -> displays ü in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(130),255)) -> displays é in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(131),255)) -> displays â in non-Terminal font even if selected font == Terminal
//echo Result: $utfdecode($utfencode($chr(132),255)) -> displays ä in non-Terminal font even if selected font == Terminal

So with the wrong codepage number, I get the right results -- albeit still not in the correct fontface (not in Terminal). :cry: