[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