Currently for any font, we get some useful information if we ask about a character code leq than \MAXFATCHAR=65535, whose charset is leq \MAXCHARSET=255. We may get the slug character if the code's charset exists (because it contains at least one real character) but the code itself doesn't exist, or if the code's charset is the font's slug charset and thus indicates that that charset's range of codes is completely empty. So what we get may show up as a black box on the display or some special character on other devices, but we don't get an error either for a missing character in a charset or for an entirely empty charset, within the \MAXFATCHAR range.
If we ask for a character beyond \MAXFATCHAR, we currently get an invalid charset error, because of the assumption that fonts never contain information for larger character codes.
But we are now admitting the possibility of fonts whose MAXCHARSET is greater than 255, even though currently our strings and atoms can't represent those characters without a further transformation of the fonts and codes into 16-bit MCCS.
It is clear what to do for any code whose charset is below a given font's MAXCHARSET--assume a noninstantiated charset is empty and return a slug without error.
For consistency, I propose the same behavior for codes that are beyond the MAXCHARSET of every font. That is, redefine \MAXCHARSET to be 65535, allowing for 24 bit characters in every font, and use the font's slug charset to interpret any code above a font's MAXCHARSET. And in particular, cause an error only for codes beyond 24 bits.
Currently for any font, we get some useful information if we ask about a character code leq than \MAXFATCHAR=65535, whose charset is leq \MAXCHARSET=255. We may get the slug character if the code's charset exists (because it contains at least one real character) but the code itself doesn't exist, or if the code's charset is the font's slug charset and thus indicates that that charset's range of codes is completely empty. So what we get may show up as a black box on the display or some special character on other devices, but we don't get an error either for a missing character in a charset or for an entirely empty charset, within the \MAXFATCHAR range.
If we ask for a character beyond \MAXFATCHAR, we currently get an invalid charset error, because of the assumption that fonts never contain information for larger character codes.
But we are now admitting the possibility of fonts whose MAXCHARSET is greater than 255, even though currently our strings and atoms can't represent those characters without a further transformation of the fonts and codes into 16-bit MCCS.
It is clear what to do for any code whose charset is below a given font's MAXCHARSET--assume a noninstantiated charset is empty and return a slug without error.
For consistency, I propose the same behavior for codes that are beyond the MAXCHARSET of every font. That is, redefine \MAXCHARSET to be 65535, allowing for 24 bit characters in every font, and use the font's slug charset to interpret any code above a font's MAXCHARSET. And in particular, cause an error only for codes beyond 24 bits.