Re: [Freetype] Strange behavior

[henry . maddocks]

>>I ve got an issue with char size in my freetype to opengl library
>>that is unrelated to freetype but when trying to resolve it, it has
>>highlited some unusual behavior.

>Which version of FT are you using?  This is essential information.

freetype 2.0.4

>>The glyphs overlapped or even advanced backwards. I changed the
>>kerning mode to be ft_kerning_unfitted but that hasn't helped.

>This shouldn't happen.  Can you provide a small C or C++ example with
>a specific font?

I've spent a bit more time on this problem and this is where I'm at.

The problem is related to integer values for kerning and advance and 
happens for all fonts (at least the 40 odd that i have tested). It 
actually affects glyphs that are loaded with hinting but the advance 
values are rounded up rather than down so the char spacing is too big 
rather than too small.  The glyphs don't advance backwards by the way, 
it's 0, 1, 2 etc. I have some screen grabs I can send if necessary.

This is what I'm doing. When I create openGL images I store the advance 
with the character. glyph advance is a 16.16 fixed float which I convert 
to a float.
Then my render function looks like this.

FT_Vector& FTGlyphContainer::render( unsigned int index, unsigned int 
next, FT_Vector pen)
{
     // FT_Vector       
     kernAdvance.x = 0; kernAdvance.y = 0;
        
    unsigned int left = face->CharIndex( index);
    unsigned int right = face->CharIndex( next);
        
    kernAdvance = face->KernAdvance( left, right);   
    if( !face->Error())
        advance = glyphs[left]->Render( pen);
        
    kernAdvance.x = advance + kernAdvance.x;
    return kernAdvance;
}

What happens is I get the kern advance for the left and right glyphs 
then add the advance width that is returned from the openGL character 
and return this so the calling function can advance the pen.

The problem is that the kearning FT_Vector is stored as integer (FT_pos) 
pixel units so for really small fonts this is 0 and my advance (which 
could be 0.9 for example) when converted to an integer is also 0. There 
doesn't seem to be much point in storing my advance and kearning in 
'native' format because they are incompatible, 16.16 against scaled font 
units. (more on that later)

Have got this completely wrong? I appreciate for most screen rendering 
rounding up or down(?) is fine but openGL is scaleless, I could have a 2 
point glyph fill the whole screen, so I need to keep precision. I'm 
using FT_Vector because it's available and consistant. I can get round 
this by providing my own Vector struct that uses floats, but would 
rather not if possible. What do you think?

About inconsistant formats...
In the docs it says for FT_Face->bbox that "The font bounding box. 
Coordinates are expressed in font units" This does not seem to be the 
case for some fonts which seem to be in 16.16 format. I've tested about 
40 fonts and so far it seems to be consistantly truetype in font units 
and type1 and postscript use 16.16 Is this correct. The only way I have 
managed to get round this at the moment is as below

// Get the maximal glyph height
if( FT_IS_SFNT((*ftFace)))
{
        // Font units
        height = (*ftFace)->bbox.yMax - (*ftFace)->bbox.yMin;
}
else
{
        // 16.16 fixed float
        height = (*ftFace)->bbox.yMax - (*ftFace)->bbox.yMin >> 16;
}

I'm not happy about doing this as it seems like a hack. What does SFNT 
have to do with bbox units? If you tell me this is OK I'll leave it in.

TIA

Henry


"I can run faster scared than you can angry"