freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Graham Asher
Subject: Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics
Date: Wed, 06 Jul 2016 08:29:30 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]