I have a use-case involving Arabic text in a game, with custom font. I am currently using the createWithTTF API call, and selecting the Font file that I would need.
However, since Arabic is a Right to Left(RTL) language instead of a Left to Right(LTR) language, the texts are getting printed incorrectly. Apparently, the best solution for this is to use the createWithSystemFont API call. However with this call, I would not be able to use a custom font and I would have to resort to a system font.
Is there any way that you guys know in Cocos2DX to use a custom font, with Arabic text? I did look into this Github issue. I tried the Arabic Writer out, but this gives glitchy output in certain cases. I know that editing the source JSON/Plist file is an option, and I have tried using reversed Arabic strings in the source. However, since Arabic is a language that has combined characters, the result that I get on my UI is not 1:1 with the expected result, and some characters are disjointed(which are supposed to form a special character after getting merged).
Looking for suggestions on how to tackle this. I have looked into almost all open threads related to this, and could not find anything conclusive. Thanks!
I wrote a fix for the Persian language. It works for Arabic as well but you may need some Arabic only characters to it. (Might need some editing)
https://github.com/MohammadFakhreddin/cocos2dx-persian-arabic-support
Related
I develop an application in Qt/C++ with Qt 5.12.12 on Windows 10.
I have some *.ui files including simple QLabel widgets to display text in Calibri font, with 16 points size.
Here is an example of what is displayed on screen when "tt" is present in a word:
This is only cosmetic issue, but I did not find anything on the web about this kind of issue. I really need to keep the Calibri font.
When I use Calibri font, 16 points, in Word or any other text editor, I do not see this issue. I am getting really crazy...
Can someone help me please ?
Maybe you find that it's actually a single character instead of two. It's called a ligature. If you don't like it, try deleting it and re-type the two Ts. But actually, typographists do that to make the font prettier, not uglier. So maybe it's something you may want to get used to and actually start liking.
There are a lot of other ligatures as well, not only for TT. Most of which I know are combinations with F:
You may not get ligatures in Word because the default seems to be "no ligatures". You can find it in the advanced text properties:
If someone wants to replace the German screnshot by an English one, please do so
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.
I am working on building spellchecking functionality into my app which currently uses MFC's CHtmlEditCtrl control.
Is there a way of drawing one of those "red squiggly lines" that you see under spelling errors on the HTML control, underneath the word that I detect to be a spelling error?
The only way I can think of is to use the actual HTML to apply this style, and then strip it out upon the email being sent. This seems rather messy, as if the user starts applying underline styles to the text they could interfere with it.
Is there a way of doing this with drawing?
Thanks in advance.
The interface you want is IHTMLRenderStyle. You pass this, once filled in, to the AddSegment method of the of the IHighlightRenderingServices interface. Here's an example in (gasp) VB. I've done it in C++, years ago now though, and it worked nicely.
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 working on a translation application in which users are allowed to give English input and I need to convert to a target language and display on a text box. I am facing problems in displaying unicode characters.
Complex characters are not rendering correctly. I know windows uses Uniscribe for rendering complex characters. So do I need to use that explicitly to get the correct rendering? What is the equivalent of Uniscribe in LINUX and MAC?
I am using C++ with wxWidgets framework and trying to display unicode characters on a text box. Any help would be great!
Considering that Uniscribe support in wxWidgets was merely a Google Summer of code idea this year, it seems unlikely that it's working today.
There's no trivial Linux or Mac equivalent for Uniscribe
Read up on Pango. It's the library that supports full OpenType rendering on Linux. Mac's another story.