Please consider calling it ftdiagnostics.h, which is more explanatory. To my native-English-speaking mind, 'diag' looks as if it stands for 'diagonal' or 'diagram'.

I think the enumeration values should be FT_DIAGNOSTIC_XXX too. Sometimes it's a good idea to spell things out.

- Graham

On 06/07/2016 07:59, Werner LEMBERG wrote:
Here is the updated patch for 2.6.4 - there are some minor
collisions with the new subpixel hinting mode.
Attached is something that would fit better into FreeType
w.r.t. formatting, macro definitions, and function names.  I suggest
to provide a public header file `ftdiag.h' that defines, similar to
`fterrdef.h', enumeration values `FT_DIAG_XXX' instead of the
currently used strings, together with proper declarations for
`TT_Diagnostics_{Unset,Set}' (which probably should use an `FT_'
prefix instead).

while updating the diff I looked into the global variable issue.
Putting the diagnostic messaging pointer inside TT_Face is fairly
straight forward, and it isn't too hard to do it per TT_Face, which
is even better than per FT_Library.
OK.

However

- diagnostics on parallel threads seem a bit of over-design - most
   people are unlikely ever to test multiple faces in parallel.
   Testing on single face is demanding enough - did I mention that it
   took about 5 days of CPU time to run the MS 2003 binary through
   the MS shipped fonts in win 8.1?
It's not about running the diagnostics in parallel but simply avoiding
global variables in general in case you want to have it integrated
into upstream FreeType.  Right now, your changes are very small and
non-invasive, so I could easily add them.

- extracting the face handle and passing it back increases the
   complexity of the C<->C# interface. Before implementing the
   rasterization test, I have relied on SharpFont (
   https://github.com/Robmaister/SharpFont ) to handle the C<->C#
   interaction.  And I have enhanced SharpFont on the way as needed.
   The current change by-passes SharpFont.  I do not want to spend
   time increasing the complexity of what's really a temporary
   by-pass.
Well, I can't comment on this.


     Werner


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

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

Reply via email to