My application allows users to customize UI by selecting a user preferred language. It usually works great, except that on Windows 10, say, if a user locale is picked as, say, Cambodian in Windows Control Panel:
But then if the user in my app's UI picks US English, I can't seem to find a way to render it with "US English numbers." On Windows 8.1 it used to end up looking as such, no matter what locale is picked:
As my assumption was that one doesn't need to translate numbers. But on Windows 10, that same control ends up looking as such:
Note that its text is set up using just this call:
::SetWindowText(m_hWnd, L"1000");
So I am curious, is there any way to keep numbers rendered as the arabic numerals:
This issue goes much deeper than basic controls, it happens inside GDI and also affects DrawText and TextOut. The only documented way around it is to call ExtTextOut with the ETO_NUMERICSLATIN flag (or use Uniscribe to render text).
This behavior is completely by design
these flags only modify U+0030 -- U+0039, as needed
Becsause the truth is that GDI doesn't give a crap about formatting or really anything related to locales, with one signle exception: Digit Substitution
Any time you go to render text it will grab those digit substitution settings in the user locale (including the user override information) and use the info to decide how to display numbers.
Another thing that seems to work is to force a custom font with the GREEK_CHARSET charset. That charset triggers a font association magic feature. (EE_CHARSET also seems to work for English text). You would probably have to try to pick the best charset for each of your languages if you are going to do this but you cannot use ANSI_CHARSET nor DEFAULT_CHARSET.
If don't know why this only happens in Windows 10 but it really seems like a bug in certain places. In Explorer for example it will display "7-Zip" as "៧-Zip" etc.
Related
My goto font for code text editing, in my own editor, has, for years, been Consolas.
I thought its coverage was good but then I discovered that W10 was adding an automatic fallback so even my Ancient Egyptian hieroglyphics font (U+13000 et al) would appear.
Now my editor (internally UTF-8 multi-byte but switching to WCHAR for display including packing two part 21 bit Unicode which the SDK handles nicely) has offered a pop-up box that provided a quick and easy access to characters not on my keyboard and that used GetFontUnicodeRanges() to determine the coverage.
This is obviously now woefully inadequate. I've searched but not found a way to determine what character codes will result in a character on the display and yet Windows is doing it effortlessly at runtime. I can ask about any individual font I want to load but not what will happen.
I must be missing something. I really don't want to resort to writing whole blocks of text to an HDC to a bitmap and then pattern matching on that for the old rectangle or the ? in a box we all know so well.
Has somebody already done this?
Is there a magic trick I am missing?
I am retired now so I have time to delve but I've run out of ideas.
We need our application to be able to accept languages such as Korean/Japanese etc. as input.
However, if I have my Keyboard language set to Korean then in the bottom right of the task bar I get this:
and if I try to input anything, It's just regular english characters.
In any other windows application (including stack overflow) I can input these characters (ex ㅔㄹㅎ), and this is what the taskbar looks like:
I'm using Qt and C++, is there any way I can get the same behaviour as any other application?
We are using custom text edits rendered with OpenGL/DirectX. On the Gl/Dx widget I needed to add setAttribute(Qt::WA_InputMethodEnabled); in order to enable the IME.
Try changing the default locale of your Qt application to the language you are targeting.
QLocate::setDefault(QLocale("ko_KR"));
I have software originally developed 20 years ago in Visual C++ using MFC without UNICODE. Currently strings are held either in char[] or CString, and it works on English and Japanese Windows PCs until Japanese characters are used, as these tend to get converted to strange characters or empty boxes.
Setting UNICODE is presumably the way forward but will require a massive code change, whereas quite a lot seems to work simply by setting System Locale to Japan (in “Window’s Language for non-Unicode programs” setting). I have no idea how Windows does this, but some Japanese character things now work on my English Windows PC, e.g. I can open and save Japanese filenames with no code changes. And in Japan they set System Locale to English and again much works, but not everything.
I get the impression the problems are due to using a font that doesn’t include Japanese characters. Currently I am using Arial / MS Sans Serif and charset set to ANSI_CHARSET or DEFAULT_CHARSET. Is there a different font I should be using, or can I extend these fonts to include Japanese characters? Or am I barking up the wrong tree in which case what do I do next? Am very new to all this unfortunately …
That's a common question (OK I guess not so common any more in 2015, as MBCS programs luckily are a dying breed - I still maintain several though...)
Either way, I'm afraid that, depending on your definition of 'working', to get this working you'll have to bite the bullet and convert to a Unicode build. If you can't make a business case for that, then you'll have to set the right locale (well, worse, have the user set the 'right' one) and test what works and what doesn't, and ask more specific questions on what doesn't.
If your goal is to make one application that correctly displays strings in various encodings in the 'right' way regardless of the locale settings on the computer, and compatible with every input data set / database content without the user having to be aware of encoding issues, then you're out of luck with an MBCS build.
The font missing characters is most likely not the problem. Before you go any further and/or ask further questions, you should read http://www.joelonsoftware.com/articles/Unicode.html, read it again, sleep on it, read it again, explain to somebody else what the relationship is between 'encoding', 'locale', 'character set', 'font' and 'Unicode code point', because only after you can do that, you can decide on how to progress with your application. Sorry, it's not what you want to hear, but it's the reality if you've been tasked with handling internationalization.
Title says pretty much everything. Once upon a time when I was under 13, my older bro did in BorlandPascal a thing which amazed me. He defined kind of table [8][8] with values of 1 and 0, meaning respectively foreground and background. Having several of such tables he could somehow redefine default ASCII characters to look like in these tables. I have no idea how it was done, but it worked.
My question is: can I do similar thing in ncurses, and if I can then how to do it?
The short answer is no. What ncurses does is generating ANSI escape codes which are interpreted by the terminal. There are no codes for altering the font. (Althou there have been extensions propesed no commonly used terminal supports them, neither does ncurses.) And there is no generic way of communicating with the terminal through some kind of side channel for changing the font. But there might ways in some specific situations.
If you have direct access to a Linux console for example you could could do all sorts of things, much like in Borland Pascal. But it will likely be more messy and less impressive.
As the selected answer explains, this is not possible for NCurses to render custom glyphs. ncurses only manipulates the terminal screen state via escape codes (Clearing and rewriting lines to achieve interactivity).
However it should be noted that's very possible to use custom glyphs in the terminal via custom fonts.
This is what Powerline does (a popular terminal UI status line for vim, tmux and friends): https://github.com/powerline/fonts
By patching the fonts, you can inject your glyphs into the existing font being used by the terminal, which then you can access and render via ncurses as any other character.
Of course this is not ideal solution, but with some auto patching of the fonts, and careful testing, it makes it possible to build an app that uses custom glyphs—when your really in a pinch for more expressive UI tools than ncurses can offer.
Further reading: https://apw-bash-settings.readthedocs.io/en/latest/fontpatching.html
I am making a win32 application using c++. When using the default font, the system takes care of displaying non English symbols, such as characters in Hindi. However, for some special symbols, such as the Indian Rupee symbol (₹), it only displays a square (which I think indicates that the current symbol cannot be displayed). I have installed the Rupakara font, which is capable of displaying the symbol.
I wanted to know is there any way by which I can mention that if the symbol is from the currency Range, I wish to use the Rupakara font, else the default system font. Thus, the appearance will be that whatever the user types, he gets the correct symbol for the same. I know I can individually check the values are within that range, but I want to have an API call that will set it to use this font for this range, as I can use this later for setting other fonts for different ranges as well.
Please let me know if any further details are required, or is there some other way to do the same without explicitly checking each character which range it belongs to and setting the font for the same.
Thanks
Microsoft Windows does not substitute fonts.
Your options are:
Edit the font you currently use and merge this character there (e.g. using FontForge). Make sure the licenses of the fonts in question permit you doing this.
Use a text rendering engine that does font substitution. It means that you won't be able to use the built-in Windows functionality though, like default text boxes and text rendering functions.