[cairo] User font feature
behdad at cs.toronto.edu
Sun Apr 9 22:36:06 PDT 2006
On Mon, 10 Apr 2006, Kristian Høgsberg wrote:
> On 4/9/06, Behdad Esfahbod <behdad at cs.toronto.edu> wrote:
> > On Fri, 7 Apr 2006, Kristian Høgsberg wrote:
> > > cairo_public cairo_font_face_t *
> > > cairo_user_font_face_create (cairo_ucs4_to_index_func_t ucs4_to_index,
> > > cairo_get_glyph_metrics_func_t get_glyph_metrics,
> > > cairo_render_glyph_func_t render_glyph,
> > > cairo_get_glyph_path_func_t get_glyph_path);
> > >
> > > Using this API the application can create a font face given a set of
> > > call backs. The font face can be used as any other font face and
> > > works with cairo_show_text() and cairo_show_glyphs() etc. The idea is
> > > that when cairo needs metrics or the glyph bitmap it calls out to the
> > > application provided callbacks. The glyphs bitmaps are cached and
> > > evicted as needed etc. behind the scenes as for the other cairo font
> > > face types.
> > >
> > > While this API is sufficient to fix the poppler performance problem,
> > > there's a few other issues to consider:
> > Is it? I don't think so. It doesn't get any data, so you end up
> > needing one set of functions per font!
> I was thinking that you'd set any data you need as user data on the
> cairo_font_face_t object. We've preferred this approach before to
> adding callback specific data and corresponding destroy funcs.
I like to reserve them for the user of the font, not the backend.
Even if we decide to use them, it will be really hard, unless you
do add a font_face_create callback to set the user_data in it,
but leaving it to the caller of cairo_user_font_face_create to
know he should attach this data to this key after getting a
font_face doesn't sound right to me. Moreover, user_data keys
are plain integers. That makes it painful to choose keys without
risking clashes with other users of the user_data. Not sure what
the original intention for adding them was. No current backend
users them I suppose.
More information about the cairo