[ft-devel] Fontval enum's revisited

[Hin-Tak Leung]

With freetype 2.7, I re-based the diagnostics patch set. Patch 1
(the updated one from Werner)
http://lists.nongnu.org/archive/html/freetype-devel/2016-07/msg00016.html
continues to apply as is, so there is not much to say about that.

FontVal 2.0 was shipped with 54 of those enum's. I thought a bit more about
the enum-as-string and enum-as-number issue, and beyond 54.

It seems to be possible to do both string and number at the macro-expansion 
stage using
the #arg stringification directive, i.e.

===
+#define DIAGNOSTICS( message, context )                                    \
+          do                                                               \
+          {                                                                \
+            if ( diagnostics )                                             \
+              (*diagnostics)( message, #message,                               
      \
...

DIAGNOSTICS(_rast_E_INSTR_DEFD_BY_FS, exc );
===

and let the C preprocessor expands _rast_E_INSTR_DEFD_BY_FS into
 _rast_E_INSTR_DEFD_BY_FS, " _rast_E_INSTR_DEFD_BY_FS"
(via 
message, #message
) ,

Future clients to this API can then use either the enum-as-number or 
enum-as-string
as they see fit, and ignore the other argument. This is assuming there is 
incentive
for another client to happen :-). FreeType will need to have another public 
header
listing the enum (as numbers). That's somewhat easier and more agreeable than
enums as struct of both number and string, or enum-as-string.

Beyond b54 and towards b59 (I have a b55, and "ELSE found without IF" is 
related to
"EIF found without IF" so will be added together "blindly" without a test file)

3 have test files:

EIF found without IF
Twilight zone point not set
Loop variable not 1 at end of program. This means it was set but not used

I have had a look at the nIFs usage in Ins_IF(), etc. I don't think I can re-use
that, as the current usage seems to go to zero to terminate the inner-most
if/then/else.

a few questions:

- why is 2nd-level if/then/else seems to be treated differently - without
going back to the main loop, and just keeps on with Skip_Code()?

- if I add my own exec->nIFs_levels to track the current IF-nested levels,
is there a preferred location to add it within the TT_Execution_Context ?
For ABI-compatibility, or aesthestic reasons...

- along the same line, I'd eventually want to put the messaging function 
pointer inside
TT_Execution_Context->TT_Face->... - is there a preferred place for it? The end,
middle somewhere, etc?

- about "Twilight zone point not set" - I didn't want to add it in a rush
since the freetype code seems to pre-define the 4 corners as zone points?
Or there is a comment in the code which suggests so. So this
is a question about assumed pre-defined twilight zone points, or whether
they exist.

I think I am okay with "Loop variable not 1 at end of program. This means it 
was set but not used"
if when I get round to look at that glyph in detail... it should be obvious 
when I see it...