Re: [ft-devel] Upstreaming freetype diagnostics patches

[Hin-Tak Leung]

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