|
|
|
This thread is locked; no one can reply to it.
|
| Allegro text and foreign characters |
|
URB753
Member #14,260
May 2012
|
Hello all. 1std::string texte("La diffraction'1234567890123456789 0123456789012345678901234567890.123");
2int totalWidth = al_get_text_width(font, texte.c_str());
gives a value of 535 for totalWidth (retrieved with the debugger), whilst (notice the ç in the text): 1std::string texte("La diffraction'123ç4567890123456789 0123456789012345678901234567890.123");
2int totalWidth = al_get_text_width(font, texte.c_str());
gives a value of 127. So the problem here is that Allegro seems to stumble on the awkward ç (it's a French character, I don't think you have it on English keyboard) and stop computing the string. I can put whatever I want after it, it won't change the value. After finding this, I tried to just use al_draw_text with a ç in it: same problem, the drawing stop and the ç and whatever is after is lost. So I think to myself "OK, Allegro is English, it's normal he don't like foreign character. I'll try with ALLEGRO_USTR". But: 1std::string texte("La diffraction'123ç4567890123456789 0123456789012345678901234567890.123");
2ALLEGRO_USTR* ustr = al_ustr_new(texte.c_str());
3int totalWidth = al_get_ustr_width(font, ustr);
4al_ustr_free(ustr);
still gives a 127 result. And it won't draw either. This is becoming troublesome. So I wondered "Does that symbol even exist in this font?". I'm using ATNQUAB.TTF (Book Antiqua Bold, found within Windows Xp default fonts). When I launch Microsoft Word and try to write in this font, he write ç without problems. Informations: Note: |
|
SiegeLord
Member #7,827
October 2006
 |
Are you saving the file with the correct encoding? Check Edit->File Encoding and make sure it's UTF-8. It works fine on Linux, incidentally. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
URB753
Member #14,260
May 2012
|
How could I not think of that? And why doesn't Code::Blocks (or the compiler) yell that there is a foreign character he'll have trouble with? Anyway, thanks it seems to work. Surprisingly, it works even with al_draw_text. But I suppose it would go wild on another machine, since the value would be used for another character. Just to be sure: if I have extern document, like .txt, and make sure I save them in UTF-8 using Notepad++, I should have no problem opening them with std::fstream in binary mode and copy it in a string, will I? I'll just have to then use this string to create an ALLEGRO_USTR and it should be correctly interpreted. |
|
Elias
Member #358
May 2000
|
Yes. Don't even need an USTR as long as it is utf8. al_set_window_title also is supposed to work, there just is a bug in the windows implementation right now I think. -- |
|
Matthew Leverton
Supreme Loser
January 1999
 |
The entire Windows port needs to be updated to work with Unicode, from dialogs to file paths, etc. |
|
Elias
Member #358
May 2000
|
I forgot again, was there some difficult problem to solve (like dropping XP support entirely) - or would it be a matter of replacing a few SetWindowTitleA(title) calls with SetWindowTitleW(al_utf8_to_utf16(title))? -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
Just set the UNICODE define (_UNICODE?) and compile Allegro. It immediately crashes due to the file system being 404. That's as far as I looked into it. I think to be proper it should support both via ifdefs, but I really don't know what I'm talking about. |
|
URB753
Member #14,260
May 2012
|
Elias said: Yes. Don't even need an USTR as long as it is utf8. What is the purpose of ALLEGRO_USTR then if it's not to handle correctly utf8? |
|
Matthew Leverton
Supreme Loser
January 1999
|
The ALLEGRO_USTR lets you easily manipulate multibyte strings. If your strings are read-only, you can just use utf8 c-strings. |
|
Elias
Member #358
May 2000
|
String manipulation. Using strcpy/strcat and so on is very error prone and there is no way to for example get a sub-string (with UTF8). And the wide char versions don't allow enforcing UTF8 (they require some archaic concept of querying "locales" first) so they can't be used either. Which means yes, in all likelihood you will use ALLEGRO_USTR. I just meant for simply reading a string from a file and displaying it you don't need it. std::string text; read from stream into text; al_draw_text(text.c_str()); will work. -- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Matthew Leverton said: It immediately crashes due to the file system being 404. Say what? -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
Once you switch on Unicode in the Windows build, it crashes because Allegro tries to stuff 8-bit strings into 16-bit Windows functions. So no files can be opened because the paths are invalid. Technically, I think al_init() fails (or some similar function) and then subsequent functions crash. It's been months since I tried it. All I'm really getting at is that if somebody does try to fix it, it should just be done properly (whatever that looks like) as opposed to just throwing in some calls to W functions. |
|
URB753
Member #14,260
May 2012
|
Ok, my questions have been answered. Thanks everybody! |
|
Thomas Fjellstrom
Member #476
June 2000
|
Matthew Leverton said: It's been months since I tried it. All I'm really getting at is that if somebody does try to fix it, it should just be done properly (whatever that looks like) as opposed to just throwing in some calls to W functions. Ah. Yeah, looks like it'd take some doing. All of the windows interface code will have to up convert all input to 16bit unicode. -- |
|
|
