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

[Hin-Tak Leung]

Argh - correction - MPPEM can overflow; as can any instructions which push 
results onto the stack, besides [N]PUSH[BW]. What confused me was that FreeType 
checks stack overflow twice! - once generically for any instructions, and also 
specifically for explicit [N]PUSH[BW] . So for the non-variable PUSH[BW], you 
are doubly protected, but in terms of diagnostics, if one tries to distinguish 
the soft/hard limit (i.e. without the 32-extra), since going over the 
soft-limit does not actually fail, I need to not-emit the diagnostic message in 
the 2nd check to avoid having duplicate messages.

Also, since going over the soft-limit does not actually fail in FreeType, one 
gets a few more stack overflow messages after the point at which it would have 
failed as further instruction processing continues, compared to FontVal 1.0. 
This describes how FontVal 2.1 (? whenever that might be) will work.

For FontVal 2.0, there is just the hard-limit - i.e. you see a message if your 
value is more than 32 lower than it should be. If if you want to check your 
calculations of  maxp.maxStackElements against what I implemented in FontVal 
2.0, put in -32 and -33; it should pass in the former and fail in the latter.


--------------------------------------------
On Sun, 9/10/16, Hin-Tak Leung <address@hidden> wrote:
 
 Slight correction, s/fpgm/fpgm or
 cvt/ .
 
 I can get FontVal 2.0 to match the behavior of FontVal 1.0
 regarding maxStackElements and stack overflow errors, on all
 the fonts I mentioned below - or if you wish, get freetype
 to match that of MS rasterer's, by taking the +32 off, with
 the following differences:
 
 - I can't see how the MPPEM instruction can overflow in
 FreeType, but it can with the MS rasterer (according to
 FontVal 1.0 against font-mfizz.ttf ). So it looks like that
 instruction is implemented differently.
 
 - FreeType won't load 'Apple Color Emoji.ttf' at 10pt, and
 does not overflow at 40pt.
 
 - FreeType seems to load the cvt twice, so all messages from
 overflow in cvt happens twice. This is annoying, but not
 IMHO a big issue since well-behaving fonts don't get them,
 and if you as a font designer getting every error message
 twice, it might be stronger incentive to fix it :-).
 
 Given the first issue - that some instructions are
 implemented differently - it is probably wise that one
 should add a few on top just to allow one's font to work on
 different rasterers... (assuming some rasterer actually take
 the font's value as is, on trust...)