Hello all.
First, let me demonstrate quickly the problem:

gives a value of 535 for totalWidth (retrieved with the debugger), whilst (notice the ç in the text):

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.
This also happen with é, à and I suppose a lot of other foreign characters.

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:

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.
So, does Word has a way to infer foreign character from TTF font that Allegro doesn't use?
Or are foreign messing with Allegro internal way of handling text?
And finally, is there a way around, knowing that I'll someday want to translate the program in French and other langage?

Informations:
I'm using Allegro v5.0 with Code::Block and MinGW on a Window Xp up to date.

Note:
This remind me of a linked bug, less important: al_show_native_message_box() has the same problem: if the string contains any foreign character, it stop writing. I have overcome that by writing my error messages in English.

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.

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.
So I'll be using UTF-8, to make sure of the portability.

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.

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.

The entire Windows port needs to be updated to work with Unicode, from dialogs to file paths, etc.

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))?

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.

What is the purpose of ALLEGRO_USTR then if it's not to handle correctly utf8?

The ALLEGRO_USTR lets you easily manipulate multibyte strings. If your strings are read-only, you can just use utf8 c-strings.

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.

Say what?

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.

Ok, my questions have been answered. Thanks everybody!

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.