[cairo] Font rendering options

[Keith Packard]

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
mechanism?

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
options.

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
created.

> 
>  - 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.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050707/cc1585d0/attachment.pgp