[Fontconfig] Text extent question - sum of advance not scaling exactly as Font Size * DPI

[mathog]

Can somebody suggest what I might be doing wrong to cause the 
cumulative
text extent to not scale linearly with font size * DPI?  Nothing is 
actually being
rendered, in this application what must be calculated is how long the 
string would
be if it were rendered (which it will be, much later).

Consider the Arial text string:  "First Second Third"
(not including the double quotes).  Using FontConfig and
FreeType the extent of the string was calculated for different font
sizes and dpi settings. The extent was the sum of the advances in X and 
also
included the kerning corrections, but in this string there was only one 
such correction,
affecting the second space.   These were the results:

Font   Dpi  Total Advance
16     75   8621
32     75   16985
16    150   16985
32    150   34995
16    300   34995
32    300   69478

As expected, let C = Font*Dpi, then total advance for any line
with the same C is the same. However, and this is the problem, the 
extent
should be simply proportional to C. Doubling C should double the 
extent.
It doesn't, not quite.  Look at the ratios for the successive advances, 
which
should be 2.0 plus a small amount of rounding error:

16985/8621  = 1.970189
34995/16985 = 2.060347
69478/34995 = 1.985369

Yes it is near 2, but not very near 2.  Where is the error coming from?
In every case the file selected was:

   /usr/share/fonts/truetype/msttcorefonts/Arial.ttf

so it wasn't using one font for one size, and another for another.
This was done on Linux and key parts of the code were:

...
   if(FT_New_Face( library, file, 0, &face )){
...
// fd is font size in points
   if(FT_Set_Char_Size(
       fsp->face,      /* handle to face object             */
       0,              /* char_width in 1/64th of points    */
       fd*64,          /* char_height in 1/64th of points   */
       300,           /* horizontal device resolution, DPI */
       300 )          /* vebrical   device resolution, DPI */
       ){ return(9); }
...
    glyph_index = FT_Get_Char_Index( fsp->face, wc);
    if (!FT_Load_Glyph( face, glyph_index, FT_LOAD_TARGET_NORMAL )){
       if ( !FT_Get_Glyph( face->glyph, &glyph ) ) {
          advance += face->glyph->advance.x;
          if(pc){
              prev_glyph_index = FT_Get_Char_Index( fsp->face, pc);
              if(!FT_Get_Kerning( face,
                  prev_glyph_index,
                  glyph_index,
                  FT_KERNING_UNFITTED,
                  &akerning )){
                  advance += akerning.x;
              }
          }
       }
    }
...

Tried FT_KERNING_DEFAULT instead of FT_KERNING_UNFITTED and that 
sequence of extents was
16960,35008,69504, with ratios: 2.064151 and 1.985375.  Those ratios 
are very close
to the ratios for the similar sizes with the different Kerning option.  
In fact,
I wish the extents were as close as these ratios:

2.064151/2.060347 = 1.001846
1.985375/1.985369 = 1.000003

Thank you,

David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech