freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] discussion of truetype glyph loading code


From: Chia I Wu
Subject: [ft-devel] discussion of truetype glyph loading code
Date: Tue, 2 Aug 2005 14:46:42 +0800
User-agent: Mutt/1.5.9i

Hi,

I am reading ttgload.c and I have some questions I would like to discuss
with you all.  I present my thoughts along with diff snippets.

==================================================================
@@ -886,24 +886,13 @@
       }
     }
 
-    cur_to_org( n_points, zone );
 
+#ifdef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
     /* eventually hint the glyph */
     if ( IS_HINTED( load->load_flags ) )
     {
-      FT_Pos  x = zone->org[n_points-4].x;
+      cur_to_org( n_points, zone );
 
-
-      x = FT_PIX_ROUND( x ) - x;
-      translate_array( n_points, zone->org, x, 0 );
-
-      org_to_cur( n_points, zone );
-
-      zone->cur[n_points - 3].x = FT_PIX_ROUND( zone->cur[n_points - 3].x );
-      zone->cur[n_points - 1].y = FT_PIX_ROUND( zone->cur[n_points - 1].y );
==================================================================
This snippet is part of TT_Process_Simple_Glyph.  The original code
translates the points so that the origin (pp1) has integral coordinates
and rounds pp2 and pp4, before hinting.  I think the translation is not
necessary.  When bytecode interpreter is enabled, we move points
relative to reference point or to itself.  Thus the translation has no
effect.  When disabled, the translation doesn't help make other points
having integral coordinates.

And for rounding pp2 and pp4, doesn't it make the result of hinting
inaccurate?  Plus, pp2 and pp4 are rounded when calculating metrics
later.

I also make cur_to_org only be called when hinting is applied.

==================================================================
@@ -1406,15 +1395,12 @@
           {
             FT_Vector*  cur   = gloader->base.outline.points +
                                   num_base_points;
-            FT_Vector*  org   = gloader->base.extra_points +
-                                  num_base_points;
             FT_Vector*  limit = cur + num_new_points;
 
 
             for ( ; cur < limit; cur++, org++ )
             {
               FT_Vector_Transform( cur, &subglyph->transform );
-              FT_Vector_Transform( org, &subglyph->transform );
             }
           }
@@ -1528,10 +1514,6 @@
             translate_array( num_new_points,
                              gloader->base.outline.points + num_base_points,
                              x, y );
-
-            translate_array( num_new_points,
-                             gloader->base.extra_points + num_base_points,
-                             x, y );
           }
         }
==================================================================
This snippet is after each composite component is loaded.  zone->org is
overwritten later by cur_to_org so we don't have to do any
transformation to it here.
 
==================================================================
@@ -1479,7 +1465,7 @@
               int  n = c > d ? c : d;
 
 
-              if ( a - b <= 33 && a - b >= -33 )
+              if ( a - c <= 33 && a - c >= -33 )
                 m *= 2;
               if ( c - d <= 33 && c - d >= -33 )
                 n *= 2;
==================================================================
This snippet is in deciding the mac scale of component offsets.  It is
commented out because the result is bad.  But in this page
http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, the
algorithm described is slightly different (typo?) from what we use here.

-- 
Regards,
olv




reply via email to

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