NewFontTool Linux support

[kornerr]

I'd like to make it use FreeType2, but I really don't get all this win32 api, so I want to know what it does.

Charsets.

There's no such thing in FreeType2. What you get in FreeType2 are glyph images from TTFont in UTF-16.
That is, suppose you get 0x0067 index, it's "g"
Suppose you get 0x0430 index, it's russian "a".
TTF contains Unicode ranges. So you get glyphs of a char from index.
I've looked at results of several charsets, and it's really just a windows mess, because Unicode ranges don't follow each other, i.e., if it's russian charset, you don't first have all lating Unicode range, then all russian Unicode range. They're grouped in some stupid order.

But this has to do with how char images are taken when font is used.
I was thinking of making resulting rectangle texture of chars consisting of :
1) Latin Unicode range;
2) Latin extended Unicode range;
3) Specific range, like Russian Unicode range;
But best of all to "checkbox" those charsets that you want to have in your rectangle char texture.
So that you can compile English, Deutsch, Russian into single texture. Or any combination you want.

So it really depends on how chars are taken from rectangle texture.

Kerning.

I don't get how it stores kerning at all. FreeType gets kerning between to adjacent chars. Is this the same for current XML font representation?
Because then each char must contain kerning info about all the rest chars.

Also, I don't get what is underhang and overhang.
Thanks.

[bitplane]

I'd like to make it use FreeType2, but I really don't get all this win32 api, so I want to know what it does.

cool, glad someone is looking into this

Charsets.

There's no such thing in FreeType2. What you get in FreeType2 are glyph images from TTFont in UTF-16.
That is, suppose you get 0x0067 index, it's "g"
Suppose you get 0x0430 index, it's russian "a".
TTF contains Unicode ranges. So you get glyphs of a char from index.
I've looked at results of several charsets, and it's really just a windows mess, because Unicode ranges don't follow each other, i.e., if it's russian charset, you don't first have all lating Unicode range, then all russian Unicode range. They're grouped in some stupid order.

But this has to do with how char images are taken when font is used.
I was thinking of making resulting rectangle texture of chars consisting of :
1) Latin Unicode range;
2) Latin extended Unicode range;
3) Specific range, like Russian Unicode range;
But best of all to "checkbox" those charsets that you want to have in your rectangle char texture.
So that you can compile English, Deutsch, Russian into single texture. Or any combination you want.

So it really depends on how chars are taken from rectangle texture.

hmm yes, maybe the GUI needs to be different for windows and linux/osx. feel free to make the appropriate changes and ifdef out the windows gui.

Anothing thing is that only UCS16 is supported at present - multi-byte characters aren't supported in the tool, CGUIFont, or most of the GUI. This will need to change too. I was thinking of making the character map convert from many UTF16 bytes to a u64 as the undex. This will be a pain though, as wchar_t is 32-bits on some platforms. irrTypes and irrString will need to be updated at some point, so for the moment we can ignore multi-byte characters.

Kerning.

I don't get how it stores kerning at all. FreeType gets kerning between to adjacent chars. Is this the same for current XML font representation?
Because then each char must contain kerning info about all the rest chars.

Also, I don't get what is underhang and overhang.
Thanks.

The 'overhang/underhang' things are A and C in windows "ABC widths", they give kerning information for characters in fonts which don't support kerning pairs. I'm not sure if kerning pair information is added to the ABC widths or if it replaces it.
For the moment I suggest ignoring kerning in FreeType fonts, and add kerning pair information to the XML font formats at a later time. IGUIFontBitmap supports kerning pairs at the moment, but it isn't implemented in CGUIFont or the tool yet.