freetype
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]