freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] a cosmetic cut-and-paste bug in the new font var code, and an


From: Hin-Tak Leung
Subject: [ft-devel] a cosmetic cut-and-paste bug in the new font var code, and another issue
Date: Sun, 16 Apr 2017 02:31:01 +0000 (UTC)

Hi Werner,

I found a cut-and-paste bug in the new font var code, probably from Adobe 
folks? while tracing another issue. Here is the diff correction:

diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
index b1a093b..3a72fd4 100644
--- a/src/base/ftobjs.c
+++ b/src/base/ftobjs.c
@@ -3709,12 +3709,12 @@
 
         if ( charcode > 0xFFFFFFFFUL )
         {
-          FT_TRACE1(( "FT_Get_Char_Index: too large charcode" ));
+          FT_TRACE1(( "FT_Face_GetCharVariantIndex: too large charcode" ));
           FT_TRACE1(( " 0x%x is truncated\n", charcode ));
         }
         if ( variantSelector > 0xFFFFFFFFUL )
         {
-          FT_TRACE1(( "FT_Get_Char_Index: too large variantSelector" ));
+          FT_TRACE1(( "FT_Face_GetCharVariantIndex: too large variantSelector" 
));
           FT_TRACE1(( " 0x%x is truncated\n", variantSelector ));
         }
 
@@ -3750,12 +3750,12 @@
 
         if ( charcode > 0xFFFFFFFFUL )
         {
-          FT_TRACE1(( "FT_Get_Char_Index: too large charcode" ));
+          FT_TRACE1(( "FT_Face_GetCharVariantIsDefault: too large charcode" ));
           FT_TRACE1(( " 0x%x is truncated\n", charcode ));
         }
         if ( variantSelector > 0xFFFFFFFFUL )
         {
-          FT_TRACE1(( "FT_Get_Char_Index: too large variantSelector" ));
+          FT_TRACE1(( "FT_Face_GetCharVariantIsDefault: too large 
variantSelector" ));
           FT_TRACE1(( " 0x%x is truncated\n", variantSelector ));
         }
 
@@ -3818,7 +3818,7 @@
 
         if ( charcode > 0xFFFFFFFFUL )
         {
-          FT_TRACE1(( "FT_Get_Char_Index: too large charcode" ));
+          FT_TRACE1(( "FT_Face_GetVariantsOfChar: too large charcode" ));
           FT_TRACE1(( " 0x%x is truncated\n", charcode ));
         }
 

It is not too important as it is only visible in debug build while tracing...

The real issue I was looking at was a problem with freetype-py loading Apple's 
emoji font. The script was passing a wrong charcode (hence I saw and noticed 
the above while tracing ), so that does not exist in the font; so freetype goes 
and fetches glyph index 0, which seems to be either missig or malformed in 
Apple's emoji font. 

FT_Get_Char_Index: too large charcode 0xdd31bbc4 is truncated
TT_Load_Glyph: glyph index 0
  failed (error code 0x24)

I don't know why it should throw Invalid_Size_Handle, when it is really that 
glyph id 0 is missing/broken? In any case, the real problem is that the 
charcode I passed was wrong and garbage. I wish the non-debug error code is 
more informative than Invalid_Size_Handle . Invalid size handle was 
misleading,as I kept looking at FT_Set_Sizes/FT_Set_Pixel_Size instead of 
looking at what charcode are being passed in FT_Load_Char .

Hin-Tak




reply via email to

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