Re: [ft-devel] Left bearing in Dynalab DFHsm5.ttc true type font is not taken in account

[mpsuzuki]

Hi,

On Thu, 10 Jan 2008 17:33:47 +0900
address@hidden wrote:
>I will start the tracking of the changeset from freetype-2.1.9 
>that causes the wrong behaviour.

The change of src/truetype/ttgload.c on 2005-08-21
causes this behaviour. The change is following.
For detail, please check the changeset I downloaded
from CVS.

diff -u freetype2/src/truetype/ttgload.c:1.147 
freetype2/src/truetype/ttgload.c:1.148
--- freetype2/src/truetype/ttgload.c:1.147      Sat Aug 20 08:17:44 2005
+++ freetype2/src/truetype/ttgload.c    Mon Aug 22 07:11:31 2005
@@ -2057,8 +2057,9 @@
         glyph->outline        = loader.gloader->base.outline;
         glyph->outline.flags &= ~FT_OUTLINE_SINGLE_PASS;
 
-        /* translate array so that (0,0) is the glyph's origin */
-        if ( loader.pp1.x )
+        /* In case bit 1 of the `flags' field in the `head' table isn't */
+        /* set, translate array so that (0,0) is the glyph's origin.    */
+        if ( ( face->header.Flags & 2 ) == 0 && loader.pp1.x )
           FT_Outline_Translate( &glyph->outline, -loader.pp1.x, 0 );
       }
 
If I reverse the change on CVS HEAD, the behaviour will be
that Boris expected. Werner, could you inform us the buggy
fonts that the change was written for?

Regards,
mpsuzuki


>On Wed, 9 Jan 2008 22:16:03 +0100
>"Boris Letocha" <address@hidden> wrote:
>>Here are screenshots.
>>Some more information: Windows rasterizer has it correctly. In FreeType
>>it does not depend if you enable or disable bytecode interpretter. I
>>don't expect that problem will be in platform, but I will do tests on
>>Mac/Linux tommorow to be sure (We never found any platform dependent
>>problem in FreeType including obsolete MVS).

ttgload_c_20050821.patch
Description: Text Data