Re: [Freetype] Strange behavior

[David Turner]

Hi Henry,

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

FT_Get_Kerning returns a value expressed either in font units or
26.6 pixels (i.e. 1/64th of pixels). You should probably try to
store it as a float instead of an integer..

There are several ways to solve your problem. One of them is to
compute floating point pen positions + advances + kerning distances,
then use the rounded pen pos to display each glyph.

Another is simply to disable kerning for small pixel sizes, if this
doesn't create shocking visual artefacts..


 
> 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?
>
I don't think your problem has anything to do with the FT_Vector
structure.
 
> 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.
>

It definitely looks like a bug, the values should be expressed in
font units independently of the format.. I'll have a look at the T1 font
drivers..

Regards,

- David