Behdad Esfahbod
Behdad Esfahbod
Thanks @dscorbett. As you said, we might not be able to do differently without a lot of hassle anyway.
> The nicest (and for me, easiest) would be if we had > > ``` > cairo_font_face_t *cairo_hb_font_face_create_for_hb_face (hb_font_face_t *face) > ``` > > it looks like that would work...
@matthiasclasen see if #3686 helps?
Let's figure out what behavior we want and code that. In all of hb-ft, hb-directwrite, and hb-coretext, one can create an hb object (face, font) from a native one. HB...
Another question is: in the `_get_` API: if the font was NOT created with a native object, but we already have created a native object internally, should we return that?...
> Another question is: in the `_get_` API: if the font was NOT created with a native object, but we already have created a native object internally, should we return...
> But for CoreText shaper this becomes an issue the way we currently do things... Nothing that cannot be fixed...
> What will happen in cross-api scenarios ? Create a face with hb_coretext_face_create, then call hb_ft_font_lock_face Right now it returns null. In the `or_create` version, which we won't add for...
> Can you always create a native object matching an arbitrary hb_face_t? Yes, because hb-face always have a get-table callback, and all systems can create a native object using just...
> If I create two fonts, once this way: > > ``` > font1 = hb_ft_font_create (ft_face); > font2 = hb_ft_font_create (ft_face); > ``` > > and then this way:...