[cairo] UserFontFace vs FtFontFace management (cairomm)

[Behdad Esfahbod]

Jonathon Jongsma wrote:
> The problem is that the
> implementation relies on the assumption that some of your callbacks will be NULL.  If I 
> recall correctly, there are at least two callbacks that are mutually exclusive, so the 
> internal logic is something like:
> if (foo_callback != NULL)
>    foo_callback();
> else if (bar_callback != NULL)
>    bar_callback();
> 
> So as you can see, if you implement the callbacks as virtual functions and install 
> callbacks in the underlying C object that will call your virtual function, you'll never be 
> able to call bar_callback(), since foo_callback will always be non-null.  Did that 
> explanation make any sense?  My memory is a little bit rusty regarding all of the details 
> at the moment, but I know that the user-font implementation is quite C-specific and 
> difficult to wrap in a natural way for object-oriented languages.  There may still be ways 
> to improve the cairomm UserFont interface though, and I'd appreciate any ideas you may have.


What you describe is very close to how it is perceived, but I think I was
careful enough to not make that mistake.  The two methods that have
interdependencies are text_to_glyphs and unicode_to_glyphs.  However, the docs
for text_to_glyphs give you a way to essentially say "unimplemented":

[snip tens of lines of docs]
 *
 * The callback is optional.  If @num_glyphs is negative upon
 * the callback returning, the unicode_to_glyph callback
 * is tried.  See #cairo_user_scaled_font_unicode_to_glyph_func_t.
 *

So all you need to do is to make sure your default implementation sets
num_glyphs to -1.

Being able to implement user fonts in, say, Python is quite a nice feature and
I expect one to simply subclass cairo.UserFontFace for that indeed.  At some
point I'll update the binding chapter and clarify this, but so far my plans to
tackle that part of the cairo tree have failed miserably.

Cheers,

behdad