[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freetype] Strange behavior
From: |
henry . maddocks |
Subject: |
Re: [Freetype] Strange behavior |
Date: |
Wed, 22 Aug 2001 09:58:55 +1200 |
>>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"