Re: [ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?
I've reduced my code to the attached program (which is still a bit convoluted - sorry!). [...] Thanks. There was a serious bug in FT_Get_Advance which has been fixed in version 2.4.9: According to the documentation, the returned advance value is either in 16.16 format or in font units. Before the fix this was true only if it was possible to quickly retrieve the advance value, which is not the case for hinted TT fonts. You probably hadn't noticed that you circumvented the bug by using the 26.6 format, together with undoing the wrong double scaling, right? :-) The fix is rather simple (see below) if you want to stay with computing everything in 26.6 format. Werner == --- textlayouttext.cpp.orig 2013-06-03 08:59:04.0 +0200 +++ textlayouttext.cpp 2013-06-03 08:59:28.0 +0200 @@ -148,7 +148,7 @@ // get character width of current character _TL_ActivateFontSize(glyphs[i].font,glyphs[i].size); FT_Get_Advance(TL_Globals.fonts[glyphs[i].font].face,glyphs[i].glyph,FT_LOAD_DEFAULT,advance); - advance=(FT_Fixed)(64*advance/(float)TL_Globals.fonts[glyphs[i].font].face-size-metrics.x_scale); + advance=10; width+=advance; // check whether this is the first character in the string/line ___ Freetype mailing list Freetype@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?
On 6/3/2013 9:05 AM, Werner LEMBERG wrote: I've reduced my code to the attached program (which is still a bit convoluted - sorry!). [...] Thanks. There was a serious bug in FT_Get_Advance which has been fixed in version 2.4.9: According to the documentation, the returned advance value is either in 16.16 format or in font units. Before the fix this was true only if it was possible to quickly retrieve the advance value, which is not the case for hinted TT fonts. You probably hadn't noticed that you circumvented the bug by using the 26.6 format, together with undoing the wrong double scaling, right? :-) The fix is rather simple (see below) if you want to stay with computing everything in 26.6 format. Werner Thank you very much for looking into this! The suggested fix works nicely. I vaguely recall that I was fiddling with this scaling when I originally wrote this code because it was behaving wrong in *some* way. But I must have been very tired to not figure out that something was amiss here :). I looked at the documentation for FT_Get_Advance again. I'm using FT_LOAD_DEFAULT as flags, but the return value is in a 16.16 scaling. Yet, the documentation states: By default, the unhinted advance is returned in font units. To me, this reads like a (probably unwanted) contradiction to the actual behaviour. I suggest something like the following instead: The returned advance depends on whether scaling is performed (based on the value of flags). If scaling is performed, the advance is in 16.16 format. Otherwise, it is in font units. Regards, Gregor ___ Freetype mailing list Freetype@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype
[ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?
Hi!
I've upgraded a project of mine from using freetype 2.4.4 to freetype
2.4.12 and now I experience totally broken text layouting (the layouting
code is my own). Horizontal spacings between characters are now either
far too large or far too small, depending on the font. In one case the
glyph distances are at least double what they should be. None of the
tested fonts give anything close to believable reasults. Linking against
the old version of freetype without any further code changes fixes this
issue.
I seem to get vastly different values for the horizontal advance. If I
uncommend the if block around FT_HAS_KERNING in the code below, the
result does not change noticably. This is the code I use to compute the
horizontal layout of a string of glyphs:
typedef struct {
unsigned int glyph;
float posX;
float posY;
int lineNumber;
int font;
int size;
} TL_GlyphPosition;
void _TL_ActivateFontSize(int font, int size)
{
if(TL_Globals.fonts[font].currentSize==size) {
return;
}
FT_Set_Pixel_Sizes(TL_Globals.fonts[font].face,0,size);
TL_Globals.fonts[font].currentSize=size;
int height=TL_Globals.fonts[font].face-size-metrics.height;
if(heightTL_Globals.fonts[font].face-size-metrics.ascender+TL_Globals.fonts[font].face-size-metrics.descender)
{
height=TL_Globals.fonts[font].face-size-metrics.ascender+TL_Globals.fonts[font].face-size-metrics.descender;
}
TL_Globals.fonts[font].currentLineHeight=height;
}
int _TL_CalculateRunWidth(TL_GlyphPosition *glyphs, int length, bool
firstInLine)
{
int width=0;
FT_Vector kerning;
FT_Fixed advance;
int i;
for(i=0;ilength;i++) {
glyphs[i].posX=(float)width;
glyphs[i].posY=0;
// get character width of current character
_TL_ActivateFontSize(glyphs[i].font,glyphs[i].size);
FT_Get_Advance(TL_Globals.fonts[glyphs[i].font].face,glyphs[i].glyph,FT_LOAD_DEFAULT,advance);
advance=(FT_Fixed)(64*advance/(float)TL_Globals.fonts[glyphs[i].font].face-size-metrics.x_scale);
width+=advance;
// check whether this is the first character in the string/line
if((i==0 !firstInLine) || i!=0) {
// respect proper kerning (if possible, i.e. both glyphs are from the
same font and size)
if(FT_HAS_KERNING(TL_Globals.fonts[glyphs[i].font].face)
glyphs[i-1].font==glyphs[i].font glyphs[i-1].size==glyphs[i].size) {
// Note: glyphs[i-1] may point beyond start of
passed glyphs array,
// but it's only a section of a larger string, so this unchecked i-1
is fine
FT_Get_Kerning(TL_Globals.fonts[glyphs[i].font].face,glyphs[i-1].glyph,glyphs[i].glyph,FT_KERNING_UNFITTED,kerning);
width+=kerning.x;
}
}
}
return width;
}
Am I doing something obviously wrong in this snippet? Was there an
interface change in freetype that I should be aware of?
Regards,
Gregor
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Freetype 2.4.4 - freetype 2.4.12: FT_Get_Advance changed behaviour?
I've upgraded a project of mine from using freetype 2.4.4 to freetype 2.4.12 and now I experience totally broken text layouting (the layouting code is my own). Horizontal spacings between characters are now either far too large or far too small, depending on the font. In one case the glyph distances are at least double what they should be. None of the tested fonts give anything close to believable reasults. Linking against the old version of freetype without any further code changes fixes this issue. [...] Maybe a bug. I can't see anything strange within your code. Can you provide a minimum stand-alone example written in C which exhibits the problem, and which I can compile and debug on my GNU/Linux box? If necessary, please send the offending font privately to me. Werner ___ Freetype mailing list Freetype@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype
