On Sat, Sep 16, 2017 at 6:52 AM, Hin-Tak Leung <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- behdad http://behdad.org/
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
