[cairo] Font rendering options
keithp at keithp.com
Thu Jul 7 17:00:27 PDT 2005
On Thu, 2005-07-07 at 18:57 -0400, Owen Taylor wrote:
> So, what would the API look like? The simplest thing to do would
> be to make cairo_render_options_t a bitfield
When I did the same thinking for fontconfig (which has all of the same
issues; fonts are selected without regard to the target surface and
rendering options carried through this API), I used a name/values
mechanism which seems more general and extensible than a bitfield. Is
there some reason to prefer the fixed datatype over an extensible
It handles all of the 'default' mechanisms, and permits non-enumerated
values if we need them at some point.
> cairo_scaled_font_t *
> cairo_scaled_font_create (cairo_font_face_t *font_face,
> const cairo_matrix_t *font_matrix,
> const cairo_matrix_t *ctm,
> cairo_render_options_t options);
Yes, I think this the right place to break the abstract/specific font
notion. Carl and I chatted about this in regard to the internals of the
metrics and image caching and decided that a cairo_scaled_font_t should
be expected to be used with a single backend; in the case of X, with a
single Screen. From an internals perspective, it would be nice in some
ways to require this, but from an API perspective, that's messy.
> - It's easy to implement for both the X11 and Win32 font backends
> - It satisfies the needs of the toy API
> - It satisfies the needs of Pango
> - It's fundamentally a whole lot simpler than anything else I've
> come up with
> Bad things about this proposed API:
> - It puts some stuff into the generic cairo API which is not
> very generic: the hint style options, for example, are something
> that is pretty unique to the fontconfig/FreeType stack.
Using general purpose name/value pairs allows each surface type to
define new rendering options here instead of having to specify all of
the possible rendering options right away.
> - It doesn't allow for surface and font backends to interact in
> new ways without extending the enumeration
> - The use of a bitfield means that we can't extend the approach
> to rendering options that aren't boolean or enum-valued.
> - The use of a bitfield isn't language binding friendly (though we
> could encourage people to bind it as an object with setters
> and getters for the different subfields)
> Open questions:
> - How should render options from a FcPattern interact with the
> options from the bitfeld?
What Fontconfig expects is for the application to place all of the
rendering options into the FcPattern; those are then run through the
match/edit steps which allows the user to modify the final rendering
We could do the same by having a function that constructed a
cairo_render_options_t from an FcPattern and let the application run
FontConfig until it hits the cairo interface at which point it converts
to a cairo_render_options_t.
> - Should we in fact have something like
> cairo_set_font_render_options() in the toy API? Disabling
> metrics and outline hinting is something people will frequently
> want to do, especially with cairo_text_path().
This would be a cairo_scaled_font_t operation? I don't like that as we
currently have immutable cairo_scaled_font_t objects. Alternatively, we
could have cairo_render_options_t associated with the cairo_font_face_t
which are applied to new cairo_scaled_font_t objects as they are
> - Naming specifics - cairo_render_options_t is a bit too
> generic, but cairo_font_render_options_t is too long.
Could be cairo_font_options_t; I don't think that's too misleading.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050707/cc1585d0/attachment.pgp
More information about the cairo