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

_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel