In Inkscape I recently encountered a problem with special characters.
When I want to type special characters like é, è, I get Cyrillic letters instead.
Even when I copy and paste from text (both from within the same doc as from another document) that is displayed correctly, the pasted letters convert into Cyrillic.
For instance the é turns into и.
I cannot find anything settings that could be the cause (or possible solution). Also my keyboard is not set to Russian/Cyrillic.
In the past I never had this problem. I am using Inkscape .48 on a Dutch Windows 8.1.
Some advise would be very welcome!
The problem seems to be in the font I am using, it seems to be a Cyrillic (ABengaly) font. Changing the font solves the problem
(I am surprised I did not face this problem before, apparently I managed to avoid the combo of this font and the French language up until now.)
Related
I am implementing a Python console application, which uses ANSI escape codes to colorize various things. I develop on Pop OS (an Ubuntu derivative), and colorization works as designed.
I just tried the app on a Centos machine, and while the colors come out correctly, there is additional text (tiny boxes containing digits, stacked vertically), surrounding the colorized text, that apparently corresponds to the escape codes.
The escape codes are all specified in this bit of Python:
style = ('\033[1m\033[3m' if bold and italic else
'\033[1m' if bold else
'\033[3m' if italic else
'\033[0m')
return f'\001{style}\002\001\033[38;5;{color.code}m\002{s}\001\033[0m\002'
(The project I'm working on is https://github.com/geophile/marcel, and the above code comes from marcel.util.colorize().)
What's really odd is that in some cases, the extra characters aren't there, in other cases they are. Also, if I ssh from my pop os machine to my centos machine, the text is colorized correctly in all cases.
What explains this difference in behavior -- something in .bashrc? Something about X configuration?
That \002 is not an "ANSI" escape code. Some programs (not terminals) may interpret it, and depending on how the string is used, that may bypass the programs which were intended to process the extra escapes. (Some terminals may of course provide their own interpretation for 002, etc., but you're unlikely to find that documented anywhere except for their source-code).
I'm using GDI+ Graphics.DrawString call to print a document with Chinese characters. All text are in Unicode (WCHAR). The problem is, on some computers (1% of all), all Chinese characters become garbage characters. It seems it tries to interpret the text in a difference code page.
I have found that only characters in regular style (FontStyleRegular) have problems. Characters in Bold style are OK.
I also tried to print to the "Microsoft XPS Document Writer" printer. The problem is the same. So it's not a problem with printer driver.
I have debugged the program and can assure the text parameter in the DrawString call is correct.
I have fixed the problem by copying the font file from a good computer to the problematic one.
When translating an app (MFC in this case) into Chinese, what do I do with Accelerators?
Is F1 still used for Help?
What about things like CTRL-A? Will the translator know what to do those?
Any advice or links appreciated.
From Wikipedia:
Chinese keyboards are usually in US layout with/without Chinese input
method labels printed on keys.
They also have F-Keys, so F1 for help is fine.
Don't translate accelerators, keep them in latin alphabet. Ampersand accelerators within text are usually moved to the right of the text, changed to uppercase and wrapped in parenthesis. For example "E&nter the text:" becomes "输入文字(&N):". There is no whitespace between Chinese text and the first parenthesis.
This is how the Windows "run" dialog looks in Chinese (simplified):
And this is Notepad's menu:
You can see for yourself by installing a Chinese language pack and changing the primary display language to Chinese via the Windows settings app.
Using the following code to create a Unicode string:
wchar_t HELLO[20];
wsprintf(HELLO, TEXT("%c"), 0x2074);
When I display this onto a Win32 Control like a Text box or a button it gets mapped to a [] Square.
How do I fix this ?
I tried compiling with both Eclipse(MinGW) and Microsoft Visual C++ (2010).
Also, UNICODE is defined at the top
Edit:
I think it might be something to do with my system, because when I visit: http://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
some of the unicode characters don't appear.
The font you are using does not contain a glyph for that character. You will likely need to install some new fonts to overcome this deficiency.
The character you have picked out is 'SAMARITAN MODIFIER LETTER EPENTHETIC YUT' (U+081A). Perhaps you were after U+2074, i.e. 'SUPERSCRIPT FOUR' (U+2074). You need hex for that: 0x2074.
Note you changed the question to read 0x2074 but the original version read 2074. Either way, if you see a box that indicates your font is missing that glyph.
The characters you are getting from Wikipedia are expressed in hexadecimal, so your code should be:
wchar_t HELLO[20];
wsprintf(HELLO, TEXT("%c"), (wchar_t)0x2074); // or TEXT('\x2074')
If it still doesn't work, it's a font problem; if you need a pan-Unicode font, it seems that Code2000 is one of the most complete out there.
Funny fact: the character that has the decimal code 2074 (i.e. hex 81a) seems to actually be a box (or it's such a strange beast that even the image outline at FileFormat.Info is wrong). :)
For the curious ones: it turns out that 0x081a is this thing:
I have a C++ program that was written by a Russian-speaking developer and so it contains Cyrillic characters. When I open the sources they are displayed as garbage. How do I solve this in windows ?
The actual problem is your IDE/editor doesn't display Cyrillic characters correctly. You solve this by changing the IDE/editor settings to use a font that contains Cyrillic characters - for example, Courier New if you're on Windows.
Well, assuming they've actually used ISO C and not some weird Russian variant, the language constructs and standard library calls will be in English (or its strange cousin, American).
The only thing you'll really need to convert are the strings (such as for user output or logging), code comments and variable names.
And even the comments and variable names may not have to change. They may make the code harder to understand to a non-Russian reader however.
If the code contains characters that your current editor doesn't understand, well, you need to get yourself an editor that does. Or get your Russian friends to turn it into English for you.
Don't think that there is another C++ programming language in russia. So you just need to replace the strings to the other language, i.e. English. Care must be taken when processing input since here you can find handling of single characters.
A better approach would be to prepare a localization. You can read all strings from a ressource or file. In that case you can select the resource that matches you target language.
If you mean that the strings of the program are written in Russian and you want to add English texts, you need to first internationalize (i18n) your program, using instead of static strings a library like Gettext; then you need to add support for the English locale.
If you mean that the variables and the comments are in Russian and you want them in English, well.. find a translator ;)
Find a translator and give him the code.