[ft-devel] FontVal 2.2 plan and the enums

[Hin-Tak Leung]

Hi Werner and others,

I am going to just say it once - I am not happy that somebody tries to create a 
incompatable fork of Font Validator''s backend code, breaking it up, while 
contributing nothing code wise or resource wise.

The FontVal freetype-backend patch set has never been posted in full, mostly 
because it has always been a work-in-progress and was never considered complete 
. It was only considered feature-complete with FontVal 2.1.1 (not even 2.1) 3 
weeks ago, to do more or less everything the legacy backend does, plus more. 
There is honestly nothing much in it that should be in upstream freetype. If I 
think there is, I'd extract that part, and send it upstream, and shrinking what 
it is, a gigantic 3000-line patch. A few patches in the past happen that way.

Unfortunately when somebody tries to break your 2-year work up and making an 
incompatable fork, the only reaction one can have is (1) stop feeding it - i.e. 
no more posting of the more interesting parts, (2) standardize the interfaces 
so that nobody has any incentives to create an incompatible fork in the future.

For (2), that means unfortunately, work needs to be done to make it possible to 
run FontVal against the desktop's copy of (modified-)FreeType. I don't run it 
that way, and I don't considered it a good idea to run it that way. There is 
also no need to run it that way with FontVal 2.1.1 - I have added this 
paragraph to the FAQ:
https://github.com/HinTak/Font-Validator/wiki/FAQ#when-will-the-full-patch-set-be-posted

<quote>
Note: Apple announced they will stop LD*/DYLD* overrides to stop people hacking 
their system binaries with custom library overrides. The Mono people came up 
with a new and clever way of bundling host-native libraries to cope, without 
depending on these variables. The FontVal 2.1.1 binaries (Mac OS X and Unbuntu) 
were built in the new way, and fully operational without a visible custom 
freetype hanging around. It was a very rough ride to try out the new 
technology, and Christian Demmer offered his help to try my Mac OS X binaries 
seven times before I did it correctly. He deserves honorary mention in the 
2.1.1 release notes. I am offended that people won't even give it a try and 
insist that they need to build freetype themselves on Linux. They do not.
</quote>

i.e. It is more or less a waste of time, just because somebody wants to break 
up your work.

I think I have got a handle on the global variable situation - It is simply 
that thinking doing it for more than a year, somebody else tries to do it 
quickly in front of you. It gets quite obvious which parts are good and which 
parts are bad/disastrous, and also what else is missing. There is not much else 
there.

So we have got the enum situation left. The current FontVal code has about 92 
enums of the form _rast_[WPIEA]_{stuff}. I am thinking of getting an entire 
block of 256 - e.g. something like this:

<quote>
  FT_ERRORDEF_( _rast_[WPIEA]_XXXXXXXX,                       0x1XX,
                "Description" )
</quote>

Between the backend and the front end, I am thinking of sending both the value 
and the name, and let the client chooses which one to process. The 
communication macro will be changed to this form:

<quote>
#define DIAGNOSTICS( message, context ) ...
@@ -158,7 +159,7 @@
           do                                                               \
           {                                                                \
             if ( diagnostics )                                             \
-              (*diagnostics)( message,                                     \
+              (*diagnostics)( message, #message,                           \
                               opcode_name[(context)->opcode] + 2,          \
                               ( (context)->callTop                         \
                                 ? (context)->callStack->Caller_Range       \
</quote>

and calling with the bare unquoted enum, and let the macro quotes it.

i.e.

<quote>
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index e6680c5fb..e5ed500e8 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -1826,7 +1826,7 @@
       if ( FT_ABS( F_dot_P ) < 0x400L )
       {
         if ( ( moved_x == 0 || moved_y == 0 ) && distance != 0 )
-          DIAGNOSTICS( "_rast_W_PF_VECTORS_AT_OR_NEAR_PERP", exc );
+          DIAGNOSTICS( _rast_W_PF_VECTORS_AT_OR_NEAR_PERP, exc );
       }
     }
</quote>


This also has the advantage that the compiler checks for spelling mistakes in 
the enums, compared to it being a string - yes, this has been a local/temporary 
modification for a while, for exactly this reason: check for my own typos.

So I think mostly this message is about asking for a block of 256 enums in 
FT_ERRORDEF_( _rast_[WPIEA]_XXXXXXXX, 0x1XX, "Description") , or something 
similiar.

And as for FontVal 2.2 - I am thinking of making the switch (the global 
variable and the enums) in 18 month's time, and Font Val 2.2 will be tested 
against desktop (modified-)freetype before release, against the entire font set 
of fedora 29. I don't want to spend time in that direction, I think it is a 
waste of time, but it needs to be done to stop people trying to break it up.

Hin-Tak