Author Topic: wstring in Window title, unicode strings, String baseline (Read 27447 times)

dewyatt · « **on:** July 09, 2008, 05:21:23 am »

I think sf::Window::Create should be able to take a std::wstring for the Title.
I understand it's easy to convert the title and then call Create.
But I'm binding some of SFML to a scripting language which requires wchar_t*/wstrings.

Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.

Lastly, I believe sf::String should draw on/above the baseline, not below it.
In other words I think this:

Should be like this:

Where the yellow line is the Position specified.

Laurent · « **Reply #1 on:** July 09, 2008, 05:48:21 am »

Quote

I think sf::Window::Create should be able to take a std::wstring for the Title.

Yep.

Quote

Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.

Improving all the unicode stuff is in the roadmap.

Quote

Lastly, I believe sf::String should draw on/above the baseline, not below it.

That wuold probably need some thinking

dewyatt · « **Reply #2 on:** July 09, 2008, 06:25:48 am »

Quote from: "Laurent"

Quote
I think sf::Window::Create should be able to take a std::wstring for the Title.

Yep.

Great!

Quote from: "Laurent"

Quote
Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.

Improving all the unicode stuff is in the roadmap.

Ah. I feel a little stupid as I forgot about the roadmap.

Quote from: "Laurent"

Quote
Lastly, I believe sf::String should draw on/above the baseline, not below it.

That wuold probably need some thinking

hah. I just thought it seems weird the way it draws now.
I don't use sf::String but I was using it as a reference when working on my sfmlTTF library and noticed this oddity.
Changing that would mean users will have to change all of their positions.
But I think it would be more intuitive and standard.

Haze · « **Reply #3 on:** July 09, 2008, 07:16:58 am »

Quote from: "Laurent"

Quote from: "dewyatt"
I think sf::Window::Create should be able to take a std::wstring for the Title.

Yep.

I was about to ask for that too, great.

Quote from: "dewyatt"

Lastly, I believe sf::String should draw on/above the baseline, not below it.

In my opinion, it would confuse a lot of users (including me), because sf::String is like sf::Sprite and GetPosition should give the upper left corner.

dewyatt · « **Reply #4 on:** July 09, 2008, 10:42:24 am »

Quote from: "Haze"

Quote from: "dewyatt"
Lastly, I believe sf::String should draw on/above the baseline, not below it.

In my opinion, it would confuse a lot of users (including me), because sf::String is like sf::Sprite and GetPosition should give the upper left corner.

It may confuse users at first, but it really should be done.
Users coming from other libraries may find it confusing that it doesn't stick to this standard.
See http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-3.html

dewyatt · « **Reply #5 on:** July 28, 2008, 05:06:21 pm »

I ran into another problem with all this Unicode stuff.

I need to bind sf::Image to Squirrel (in Unicode mode).
But LoadFromFile takes a std::string not a std::wstring.
I see that SFML uses SOIL which does not seem to support Unicode filenames.
Looking through SOILs code, it looks like these two functions would need to be overloaded/changed:
SOIL_load_image
stbi_load

It's a quick change.
But this would mean whenever SFML updates to a new release of SOIL, the SOIL code would have to be patched each time.

I was wondering if SOIL is the best choice for the image library behind SFML.
I don't know how heavily it is used but there are certainly alternatives that directly support Unicode filenames.
FreeImage supports it.
DevIL has it on the TODO list I believe.

Laurent · « **Reply #6 on:** July 28, 2008, 05:27:08 pm »

Well, as you said it's a quick change and if I do it the author will certainly integrate it into SOIL next release.

I'm not going to change the underlying image library, because SOIL is lightweight and do almost all the job (with the help of stb_image) in only 3 source files which can be included directly into SFML source code. All other libraries need to link with libjpeg, libpng, libtga, ligtiff, etc... for which I need to get the libraries for every version of every target compiler for static link.

Anyway, just for my personal information, who's using Unicode filenames ?

dewyatt · « **Reply #7 on:** July 28, 2008, 07:12:56 pm »

Quote from: "Laurent"

Well, as you said it's a quick change and if I do it the author will certainly integrate it into SOIL next release.

I'm not going to change the underlying image library, because SOIL is lightweight and do almost all the job (with the help of stb_image) in only 3 source files which can be included directly into SFML source code. All other libraries need to link with libjpeg, libpng, libtga, ligtiff, etc... for which I need to get the libraries for every version of every target compiler for static link.

Anyway, just for my personal information, who's using Unicode filenames ?

I figured you wouldn't want to change the library, just thought I'd suggest it.
I do like that SOIL is lightweight.
I'll just make the necessary changes to SOIL.

As far as who's using Unicode filenames...
People with a non-english OS really expect support for it (and they have every right to).
I probably won't use it personally but my game is extensible and will allow for it.

Avency · « **Reply #8 on:** July 28, 2008, 08:34:14 pm »

If it's only for the binding purpose you could load the file into memory and then use sf::Image::LoadFromMemory.

dewyatt · « **Reply #9 on:** July 29, 2008, 12:30:06 am »

Quote from: "Avency"

If it's only for the binding purpose you could load the file into memory and then use sf::Image::LoadFromMemory.

I realize that, but thank you anyways.

I didn't want to work around the problem like that.
I've already changed SFML+SOIL to allow Unicode Image::LoadFromFile though, so all is working now.
I love Squirrel. Such fun

Avency · « **Reply #10 on:** July 29, 2008, 10:49:30 am »

Quote

I love Squirrel. Such fun

I agree. Squirrel is quite nice.
I started to embed it just a few days ago. :wink:
It lacks documentation though.

dewyatt · « **Reply #11 on:** July 29, 2008, 11:48:19 am »

Quote from: "Avency"

Quote
I love Squirrel. Such fun

I agree. Squirrel is quite nice.
I started to embed it just a few days ago. :wink:
It lacks documentation though.

Yeah I really wish it had more documentation/tutorials.
It even says on the front page "The documentation has to be improoved." (improved...).
I'm using SqPlus but I'm considering just using straight Squirrel.
If I do switch, I found Ogre3D bindings (OgreSq) that could serve as documentation a little.

Avency · « **Reply #12 on:** July 29, 2008, 12:14:14 pm »

If you decide to switch, the source of the Squirrel standard library also turned out to be helpful (+ some japanese site

).

dewyatt · « **Reply #13 on:** July 29, 2008, 12:31:22 pm »

Quote from: "Avency"

If you decide to switch, the source of the Squirrel standard library also turned out to be helpful (+ some japanese site ).

Oh nice! I hadn't thought of looking through that!
Oh and do you have a link for this Japanese site?

Avency · « **Reply #14 on:** July 29, 2008, 03:02:54 pm »

http://muffin.cias.osakafu-u.ac.jp/~matumoto/cgi-bin/xt.cgi?prog/squirrel
It seems to be down at random times. If there is nothing on that site, try again later...

That + Squirrel source code provides pretty much all information I need for the system I intend to create.