Andreas K. Foerster wrote:
For CRT, it would probably require using ncursesw instead of ncurses.
I don't think, that this is necessary.
Sorry, GPC doesn't support larger-than-8-bit chars yet at all.
Here is a small extract from my AKFQuiz project (qsys.pas). Maybe you want to use it for GPC. (GPLv2 or later)
I don't have a problem with conversion routines. The problem is that UTF-8 strings don't satisfy the requirements of Pascal "Char" and "String" types (e.g., that every sequence of valid "Char" values is a valid string value; as I said, see previous discussions.). Since GPC aims to support Pascal (plus extensions), not some language-more-or-less-similar-to-Pascal, I think we'll need a "Char" type larger than 8 bits for proper Unicode support. (And, BTW, processing on such a type is still easier that UTF-8. The main advantage of UTF-8 is reduces space requirement, so converting on I/O should also be the least work for the programmer. When implemented this way properly, most Pascal programs using strings should work without changes in Unicode, unless they specifically refer to ASCII, or ISO-8859-x, etc. properties.)
In the meantime, you can try to make things work with UTF-8. Of course, not everything will work, e.g. "Length" on a UTF-8 string will produce wrong results, and I suppose you know that and you already use workarounds in your code.
As for CRT, if you know what's necessary to work with such UTF-8 pseudo-strings, just make the required changes (it's free software ;-). I didn't think plain ncurses supports multibyte chars (think of counting chars for cursor position etc.), but if you know better, just do it (or describe what needs to be changed) ...
Frank