Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Allows one to, for example, get that pretty Terminal OEM/DOS font you may have learned to love.
Attached patch honors bCharSet (Script) font selection and limits the font choice dialog to fixed pitch fonts.
Logged In: YES
CF_EFFECTS should be removed as well as it is currently unused (and not likely to ever be used)
File Added: script_select_and_fixed.patch
Allow script selection and only show fixed pitch fonts
Joel 'Jaykul' Bennett
Logged In: YES
This REALLY needs to be adopted.
Logged In: YES
For some reason I didn't see this patch...
What is the use of font charset setting when Console2 is a Unicode app?
The current code allows you to select a font that doesn't support Unicode. This patch allows it to look better if that is actually what you want.
Basic Latin will map correctly, I have code here that actually does the necessary conversion to handle wide -> OEM -> wide character conversion (though I thought I'd save that until this was accepted/rejected).
Hm, I still don't get it. Can you give me an example?
Console reads Unicode character codes from a Windows console. For output, it TextOut's the same character codes. If a font in use is Unicode-capable, it will render appropriate Unicode characters. If not, it will show something like a box if the character doesn't exist, no matter which charset was used when creating a font.
My understanding is that font charset is important in non-unicode applications, when a character code like 0xBC maps in different characters depending on which charset you're using, but Unicode character codes are unique and the character rendered for a code like 0x0106 is always the same.
Are you saying that specifying a codepage when creating a non-Unicode, non-Latin font will improve character rendering because the system will use the appropriate codepage to convert character codes? If yes, do you have such a font for testing? I have only non-Unicode fonts with Western encoding.
And what's the use of wide->OEM->wide conversion?
An example using Terminal DOS/OEM codepage:
An example character: 0xFD the superscript 2 in the DOS/OEM codepage is 0xB2 in the Unicode world. What happens currently is that the 0xB2 is written as is, even if the display font does not support Unicode characters.
Using the Terminal font with the DOS/OEM script, perl -e "print(chr(253))" will show correctly (superscript 2) outside Console, inside it will show as a shaded block (the character at 0xB2).
The point of the wide->OEM->wide is to force the Unicode characters through the OEM map, currently the Unicode characters are used directly, leading to the wrong characters once you step out of Basic Latin.
Ideally, the hook DLL would be making calls to GetConsoleOutputCP and doing the conversion there. If a patch like that would be accepted I'll make one (but for my own use just assuming OEM is ok).
Hm, I think we're looking at the wrong place. I did some testing using Windows console.
Try changing language for non-Unicode programs in the Advanced tab in the regional settings.
When I set the language to Croatian (Central/Eastern Europe charset), typing ALT+253 on the numpad gives me 'ř' (r with a caret). When I set the language to English (Western charset), ALT+253 gives me '²' (superscript 2)
My guess is that the non-Unicode language Regional settings are used as codepage used to convert characters to Unicode.
This works as expected in Console2 when using Unicode fonts. However, when using non-Unicode fonts (like 'Terminal' font) and print characters in the range 33-255, I don't get the same table as shown in Charmap program no matter which charset I use when creating the font in Console2.
Also, when I use the 'Terminal' font in a text editor, I get yet another set of characters.
I also tested another thing: setting console CP using SetConsoleCP/SetConsoleOutputCP seems to have the same effect as changing the non-Unicode language in the Regional settings.
Non-Unicode fonts still confuse me, but I think that your proposed wide->OEM->wide conversion would just be an additional step that can be controlled using Regional settings.