[Cairo] Re: Text APIs round 2

graydon hoare graydon at redhat.com
Thu Aug 14 09:05:08 PDT 2003


Keith Packard <keithp at keithp.com> writes:

> I think we've converged on the class of acceptable solutions for cairo 
> text.  

This looks quite satisfactory, and dodges the overengineering I was
afraid we were getting into. I'd much rather have an if(win32) branch
in my code than live through the creation and stabilization of Yet
Another Abstract Interface To Fonts.

a couple tiny comments though:

> 	typedef struct cairo_glyph {
> 	    cairo_font_t *font;
> 	    FT_UInt      id;
            ^^^^^^^

this typename shouldn't be here, should it? FT_UInt might not have any
meaning on win32.

> 	cairo_font_t *
> 	cairo_font_from_ft_font (cairo_ft_font_t *ft_font);

how about also having a couple (maybe-NULL-returning) downcast
operators and a query function?

        cairo_ft_font_t *
        cairo_ft_font_from_font (cairo_font_t *);

        cairo_win32_font_t *
        cairo_win32_font_from_font (cairo_font_t *);

        typedef enum {cairo_win32_fonts, 
                      cairo_ft_fonts,
                      cairo_pdf_fonts, ...} 
        cairo_font_system_t;
        cairo_font_system_t cairo_current_font_system(cairo_t *);

these have a couple uses:

- someone wrapping a cairo_t GC, who wants to use platform-specific
  features, doesn't need to cache the "native" object outside the
  cairo_t. they can fetch the current font from the cairo_t and
  selectively downcast that. less opportunity for unsynchronized
  state.

- someone writing code which has font-system-specific branches can ask
  cairo for its opinion on which font system to use, freeing them from
  writing font-system-detection configury tests and also enabling say
  win32 to silently acquire a fontconfig implementation someday.

-graydon





More information about the cairo mailing list