[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ft] Glyph Advance when using the Image Cache
From: |
Moore, Thomas C1 |
Subject: |
RE: [ft] Glyph Advance when using the Image Cache |
Date: |
Fri, 14 Jul 2006 00:32:14 -0500 |
The following code snippet demonstrates the problem that I believe is
the root cause...
{
FT_Glyph newGlyph;
FT_Load_Glyph( face, glyph_index, FT_LOAD_DEFAULT |
FT_LOAD_TARGET_LCD );
FT_Get_Glyph( glyphSlot, &newGlyph );
/* the advance vector in the newGlyph is not the same as in the
glyphSlot... */
/* newGlyph->advance.x /= 1024 would also work...
*/
newGlyph->advance = glyphSlot->advance;
}
Thomas Moore
ADP - Software Engineer
Lockheed Martin Aeronautics Company - Fort Worth
-----Original Message-----
From: Werner LEMBERG [mailto:address@hidden
Sent: Friday, July 14, 2006 12:25 AM
To: Moore, Thomas C1
Cc: address@hidden
Subject: Re: [ft] Glyph Advance when using the Image Cache
> If I bypass the image cache and just use FT_Load_Glyph, then the
> glyphs are correctly loaded in the the GlyphSlot. However, when I use
> FTC_ImageCache_Lookup, the advance vector in the glyph does not appear
> to be set correctly. For example, when using a size 22 Arial font, the
> asvance.x = 917504, and advance.y = 0. When I use FT_Load_Glyph, I get
> a more reasonable value of advance.x = 896. If you look at these
> numbers, 917504 / 896 = 1024, so I've noticed that if I copy the glyph
> I get from FTC_ImageCache_Lookup, then divide its advance.x by 1024,
> then it seems to work.
Well, the former value looks like being in font units, while the latter
appears to be a 26.6 fractional pixel value. The question is how to
explain the difference.
Please provide a small (compilable) code snippet which shows the
problematic behaviour. Maybe there's a buglet, or the documentation
lacks a proper explanation.
Werner