Felipe, > HinTak's patches simply benefit from those error-detection routines by > providing an API that informs a user application about those errors (so that > FontVal, for instance, can report them in a font testing log).
That's roughly correct between b06 up to b54. You should also bear in mind that a patch went into FreeType 2.6.1, on ComputeMetrics, and there was a whole year of thinking, between the ComputeMetrics patch, before b06. Things gets simple, if you spend a year thinking about it, before doing. The time span between b06 to b54 (FontVal 2.0) was about 2 weeks. The timespan between b54 and b70+15 (FontVal 2.1) is a whole year. It is quite wrong to apply your description to between b54 and b70+15. Beside the global variables, there is is a stylistic(?) issues about the list of error codes. C# enums are closer to python/perl associative arrays - i.e. they know their own names. Whereas C enums are plain numbers without knowledge of their own names. b06 communicates by the error code's name, not its value. That's because the name is unlikely to change on the C# side (but the value does). There is the issue of fixed values for C style enums vs flexible named C# enums. If you want to clamp the value to C enums, you need to work on the C# code to cope with the clamped values. That was discussed on freetype-devel too. These are the two main things about b06 (and up to b54), you can improve on. They were discussed on freetype-devel from time to time. I do feel that you are trying to monopolize others' time again to explain issues to you. If you feel that you want to contribute, you can just go and study the patches (quietly) and come up with something better, instead of keep asking people to explain it to you. There is also the freetype-devel archive to search for postings also. Also, Dave was CC'ed on almost all e-mails and you could ask him yourself. If this is considered a Google venture, I'd say Google is rich enough to commission me to improve on it. You'd be surprised how many times I have asked Dave. The last time was perhaps April when I announced the python interface, when he said "not this year, maybe 2018'. You are welcomed to spend time on it either way, but it should be your own time you spend, not others'. This was why the 'negative contribution' entry in the FAQ was written. It is definitely not confidence-inspiring having to hand-hold you on patch b06 ( http://lists.nongnu.org/archive/html/freetype-devel/2016-07/msg00016.html ), and having to spend about two days to explain to you that the message *is* the patch. It baffles me that you have never seen an inline patch in a e-mail before. I now realised the problem is that you have not used git before github, and you have never used 'git send-email', 'git format-patch' and 'git am' (to apply a series of patches from a mail box). It is a requirement for kernel development that patches are inlined in e-mails for review, *not* as attachements - see for example, https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html - , That was how git was used from day 1 with 'git format-patch', 'git send-email', 'git am', and it is still being used. Although others outside the kernel community takes the "patches must be inlined in emails" rule less strictly. You could read up a bit on git's documentation... Hin-Tak _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
