> Date: Fri, 5 Jun 2020 23:04:59 +0530
> From: Priyesh kumar <[email protected]>
> To: Werner LEMBERG <[email protected]>, [email protected]
> Subject: Re: Logging Library-GSOC
> So, I was thinking to use something like this in ftdebug.h to print the
> tracing component:
> #define FT_COMPONENT( x ) FT_COMPONENT_TAG_( x )
> #define FT_COMPONENT_TAG_ #x
> #define FT_TRACE( level, varformat )
> do
> \
> {
> \
> if ( ft_trace_levels[FT_TRACE_COMP( FT_COMPONENT )] >= level )
> { \
> set_tag( FT_COMPONENT_TAG( FT_COMPONENT ) );
> \
> FT_Log varformat;
> \
> } while( 0 )
> \
On Sun, May 24, 2020 at 3:22 PM <[email protected]> wrote:
<snipped>> ```c
> FT_Trace_Set_Level( FT_Trace_Level level );
>
> typedef void
> (*FT_Trace_Callback)( FT_Trace_Level level,
> const char* fmt,
> va_list args );
>
> FT_Trace_Set_Callback( FT_Trace_Callback callback );
>
> FT_Trace_Set_Default_Callback( void );
> ```
>
> Note this is just a quick sketch and the actual callback function might
> have a forth parameter for the module ... or this can be part of `fmt` and
> `args` ... tbd :)
This is basically the first version of the FontVal patch: a macro to expand
DIAGNOSTICS() with more local details, a function callback prototype for
emitting messages elsewhere, and two new routines to set and unset the callback.
That first patch was posted to the list and should be in the list archive -
July 2016. I don't think either of you were subscribed in 2016? Anyway, the
FontVal patch is an enhancement to get diagnostic information out of freetype's
TrueType hinting instruction interpreter, in a form to make it imitate the
older Microsoft diagnostic backend, which was not open-sourced.
I am not going to get drawn into another flame war about it... Anyway, the two
major changes since then was to move the global variable which stores the set
function pointer, into FT_Face, so it becomes a face-instance variable (and the
set/unset function gain an additional first FT_Face argument). The 2nd major
change was to the callback itself, which adds a last "arbitrary payload"
argument, because it is easier to do that on the C side than on the Perl side
of trying to recurse inside a C struct in perl, I think.
I imagine for your FT_TRACE, you want to store the callback info in a library
instance variable - ie you need FT_Library as an argument to set/unset.
Anyway, as I said, the patch is in the list archive in July 2016. The client
side code are all under my github account ("HinTak") - C# in
FontVal/Compat/Compat.cs (named because it was a compatibility layer to make
freetype works like Microsoft's renderer...), python bindings under my
Freetype-py fork on the font-diag branch, and similar for perl on
p5-Font-Freetype . All 3 language bindings are maintained, though the main one
getting attention is the C# one.
The prebuilt freetype binaries are all under FontVal/bin for various arches -
linux, windows , Mac os x, the latest is Raspbian 32-bit arm.
You are welcomed to play with the 3 language bindings to hook them into a
different /logging library instead of the FontVal GUI html browser front end
(or stderr as the python/perl examples do). This might give you some idea how
your external tracing interface should work.
The 64-bit windows binary is not compatible with 64-bit windows python. Use
32-bit python if you want to play with it on windows.
Flames > /dev/null
