Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4)

[Hin-Tak Leung]

I checked the FreeType code and also what FontVal 2.0 does. Yes, FreeType 
reserves +32 extra, and AFAIC FontVal 2.0 only tells you as FreeType reaches 
the hard limit. i.e. you should subtract 32 from what FontVal 2.0 starts to 
complain about stack overflow, as you decrease the number to see what it hits. 
Consider this a bug/inadequacy/limitation of FontVal 2.0 - it only tells you 
when FreeType reaches its hard limit, which is +32 higher than what the maxp in 
the font itself says.

You could check what FontVal 1.0 does for this. It should match VTT or the -32 
value; I'd be curious about what FontVal 1.0 does on this.

I added a  comment about this to
https://github.com/Microsoft/Font-Validator/issues/27#issuecomment-252446511

--------------------------------------------
On Sat, 8/10/16, Hin-Tak Leung <address@hidden> wrote:

 Hiya -
 
 My impression of this part of FreeType's code is that
 FreeType treats the numbers in maxp as advisory. It reserves
 an extra amount (?32 seems to come to my mind) on top of
 what maxp says, then during running as the value is
 exceeded, either just silently ignore discrepancies and
 revises the internal value, or if ->pedantic is on, throw
 an error and returns. So there are two values, a soft-limit
 (which can be exceeded unless in pedantic mode), and a
 hard-limit (which can't) in FreeType.
 
 Maybe VTT is doing effectively what the extra amount of
 reservation does.
 
 Also - maybe the microsoft rasterer assumes some of the
 structures/values from CVT or fpgm stays on the stack? This
 is really more a question to the author of VTT of how VTT or
 the microsoft rasterer works (if you can get an answer from
 Microsoft..).
 
 
  Message: 1
  Date: Sat, 8 Oct 2016 11:01:43 +0100
  From: Cosimo Lupo <address@hidden>
  To: address@hidden
  Subject: [ft-devel] how to compute maxp.maxStackElements?
  
  Hello list,
  
  I would like to use a debug hook with the truetype
 bytecode
  interpreter to
  calculate the maxp table's `maxStackElements` field, which
  is defined as
  the "maximum stack depth", including "Font and CVT
 Programs,
  as well as the
  instructions for each glyph".
  
  I'm trying to emulate what MS Visual TrueType (VTT) does
  when one runs the
  command "Recalc maxp values" from its graphical interface.
  
  I've looked at how the freetype2-demos' ttdebug, as well
 as
  FontForge's TT
  debugger work, and below is what I've got so far.
  Please note that my C is quite rudimentary -- I plan to
 move
  this code to
  Python at some point --, but I think you get the point:
  
  
  ```
  #define CUR  (*exc)
  
  struct debugger_context {
      FT_Long maxStackSize;
  };
  
  static struct debugger_context *global_debugger_context;
  
  static FT_Error test_debug_hook( TT_ExecContext exc ) {
      struct debugger_context *dc =
  global_debugger_context;
      FT_Error error = 0;
  
      CUR.instruction_trap = 1;
  
      while ( CUR.IP < CUR.codeSize ) {
          error = TT_RunIns( exc );
          if ( error != 0 )
              break;
          if ( CUR.top >
  dc->maxStackSize )
             
  dc->maxStackSize = CUR.top;
      }
  
      return error;
  }
  ```
  
  This seems to work, in the sense that the computed value
 is
  big enough for
  both FreeType and MS rasterizers to render the font. If I
  set it to
  anything less than that value, for example, the
 interpreter
  probably runs
  out of memory and rejects the instructions.
  
  I noticed however that the value as computed by VTT seems
 to
  be always a
  bit greater than the one I get from the code above,
 usually
  around 80-90
  bytes greater (it varies from font to font).
  I don't know why that is the case, and I wonder if someone
  else in this
  list could shed some light on this?
  
  Thank you for your support.
  All best,