Re: [ft-devel] FontVal 2.2 plan and the enums

[Behdad Esfahbod]

On Sat, Sep 16, 2017 at 6:52 AM, Hin-Tak Leung <address@hidden> wrote:

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.

Get over it.

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

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel

--

behdad
http://behdad.org/