|
From: Eli Z. <el...@gn...> - 2013-02-15 16:08:27
|
> Date: Fri, 15 Feb 2013 16:54:34 +0100 > From: Erwin Waterlander <wat...@xs...> > > > To be able to use ANSI codepages in the cmd window, the fonts > > supported by that window must cover well the ANSI codepages. Since > > those fonts currently don't cover ANSI codepages, I suspect that this > > is at least one reason why console programs still default to OEM > > codepages. Heck, even Lucinda Console supports only a very small > > subset of the BMP, so even if you use WriteConsoleW, you cannot > > display quite a few blocks from the BMP (let alone characters outside > > of the BMP). > > I thought that for every Windows ANSI code page there is at least one > mono spaced true type font that covers the ANSI code page. And it also > covers the default OEM code page which is related to the same region. > And usually it covers some more. Is this not true? No, far from it. The fonts that you can use in the cmd window are all listed in the "Font" property sheet of that window. That is all you have to play with. The character coverage of those fonts can easily be displayed; you'd be surprised by how poor it is. Moreover, some OEM codepages don't have _any_ cmd window font at all. Just one example: codepage 972. > I think it is normal that the true type font doesn't cover all ANSI code > pages. If you want to be able to output Unicode text from a console application, you _must_ have at least one font with wide coverage. That's because console apps cannot switch fonts in the middle of their run, like GUI applications can. |