Hi Behdad, for my embedded project your proposal might be over the top :-) Werner, may I suggest to enhance the synopsis section of FTC documentation. cited from FTC documentation:
"Second, the cache calls, only when needed, a client-provided function to convert a FTC_FaceID into a new FT_Face object. The latter is then completely managed by the cache, including its termination through FT_Done_Face." Maybe this can be extended by: To monitor termination of face objects, the finalizer callback in FTC_Face generic can be used. In addition you might use generic data to store the FTC_FaceID of the face. br Gernot 2010/9/28 Behdad Esfahbod <[email protected]> > On 09/28/10 01:09, Werner LEMBERG wrote: > >>> >> You can register a callback by setting face->generic. > >> > > >> > perfekt solution for my problem. I was not aware of the finalizer > >> > callback. > > Could you suggest an addition to the documentation to improve it? > > Actually let me hijack the thread. While the face->generic is the perfect > solution for an application's needs, it's inadequate for use by other > libraries. The problem is that there is only one generic slot per face. > What's needed instead is something like the cairo_set_user_data() or > g_object_set_data_full() APIs that allow multiple generic slots. This can > be > implemented as a hash-table internally. I think it would be enough to just > add such API to FT_Face and perhaps FT_Library, but not other objects. > > Anyone feel like cooking such API? It probably needs a new type other than > FT_Generic since the callback to FT_Generic doesn't get passed the generic > itself, just the containing object. > > Thanks, > > behdad > > _______________________________________________ > Freetype-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/freetype-devel >
_______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
