Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics

[Hin-Tak Leung]

Thanks for reviewing and revising the patch. I'd likely just use your patch 
instead, when I do the win32/64 and mac os x binaries in the next couple of 
days. Right now I still have a few things to do on the C# side.

I thought about the enum vs string issue (FT_DIAG_XXX) a bit, as I mentioned at 
the beginning - the problem I am facing is that it is 6 out of 77 out of about 
800 of the master list. The master enum list will change when new 
opentype-table tests are added, so the raster test subset of enum will change. 
If I have it as a enum on the freetype side, that means I have to have another 
on the C# side to do a small enum to large enum look-up, and maintaining two 
additional tables, one on freetype side and one on C# side; and forever keeping 
them in sync...

I didn't think a FT_DIAGNOSTICS except the first one is necessary, as '#define 
DIAGNOSTICS( message, context )  do { } while ( 0 )' should kill off the whole 
patch to nothing. I didn't want to add #ifdef in the latter parts, for 
readability, like you just did; but if your like a few more #ifdef 
FT_DIAGNOSTICS I'm okay with that (when I add more things, in the future).

Sadly I know of no other linux/unix users of this code other than me :-(. So 
the issue of bundled patched freetype vs upstream/system freetype affects 
exactly one person... Speaking of which, I am a bit surprised that with 
freetype 2.6.4, subpixel hinting is enabled by default - are you sure about 
that? I have opted to revert that in my bundled patched freetype: I want 
subpixel hinting available and dynamically switchable between B/W, gray, 
cleartype testing, via property_set, but kept the older default of subpixel 
hinting off, for now. Just less surprising, as subpixel-hinting did affect 
HDMX/VDMX/LTSH calculations, from testing last year.

Hence I just filed two issues for SharpFont ( 
https://github.com/Robmaister/SharpFont/issues/82 , 
https://github.com/Robmaister/SharpFont/issues/83 ) - 
and supplied a patch pull to half of 1 issue. That's just for dynamically 
switching interpreter behavior via property_set not working :-(. Not looking 
forward to upstreaming the C# side of the diagnostic enhancement :-(.

--------------------------------------------
On Wed, 6/7/16, Werner LEMBERG <address@hidden> 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
 
 -----Inline Attachment Follows-----