On Tue, 9 Jun 2015, Allin Cottrell wrote:
Strings produced by the "print" command don't go
through the gettext
translation mechanism and so are not recoded automatically; in the Windows
console they will come out in whatever encoding was used on input.
I thought that perhaps the Windows function SetConsoleOutputCP() might help,
but I've now tested on Windows 8 and it doesn't.
Well, there's _one_ more attempt in CVS and snapshots. Via trial and
error I found that using SetConsoleOutputCP() with an argument of
UTF-8 does work (at least on my Windows 8) if (only if) the console
font is TrueType (as opposed to the default raster font).
I can't find a proper account of how to tell if the active console
font is TrueType but I'm trying a hackish heuristic. I'd be interested
to hear if this works for anyone else.
To set a TrueType font, right-click on the title bar of the cmd.exe
window, choose Properties and then the Font tab. In Windows 8 there's
a choice of Lucida Console or Consolas. I think that Lucida Console,
at least, may be available in earlier Windows versions.
For the record: if my heuristic suggests that a TrueType font is in
use, we ask Windows to switch to "code page 65001" (UTF-8) and bind
gretl's translations to produce UTF-8. In principle this should also
take care of strings passed to "print" and "printf" provided they are
in UTF-8. If the heuristic suggests that a raster font is in use we
detect the active console code page and bind gretl's translations to
emit text in that encoding -- in which case gretl's print and printf
are not handled properly.
Allin