[cairo] Font options patch, second draft
cworth at redhat.com
Wed Jul 20 23:09:43 PDT 2005
On Tue, 19 Jul 2005 21:13:12 -0400, Owen Taylor wrote:
> Here's a second version of the patch. Changes are a couple of things
> I mentioned in my first email:
I've read through it now and understand it much better.
> - cairo_ft_font_options_get_load_flags() is removed, and the
> for cairo_ft_font_face_create_for_ft_face() we take rendering
> options directly from the cairo_font_options_t structure.
That sounds like an improvement.
> - I've added code so that the default options are set for Xlib
> surfaces in the same way as they are for Xft. (Mostly from
> the Xft.* X resources; subpixel antialiasing is also turned
> on automatically when RENDER reports a subpixel display.)
> This is a reasonably big addition that adds a per-screen
> logically attached to the display: I wanted to avoid having
> to do a bunch of X resource database manipulation for every
> screen that is created.
The screen_info stuff should give us a fine way to fix a bug in the
xlib surface. It was already maintaining a similar list of
display-specific data, but in a thread-unsafe way. And the
close_display hook should also let us clean up the server-side
glyphset caches when the display closes.
> - I've made the basic adaptions to cairo-win32-font.c so it should
> compile, and even honor the antialiasing option. No testing.
Excellent. So reviewing the original caveats you mentioned:
>> * When working with FreeType backend specific fonts, the cairo_font_options_t
>> retrieved from the surface enters in two places:
As you explained and Keith has confirmed, there's really no other
choice here, (just blame the rushed design process of fontconfig API).
>> * I haven't tackled the Win32 backend for this. The easiest thing, to just take
>> a cairo_font_options_t and ignore it is a few minutes work.
As mentiond above, you've addressed this now. Thanks.
>> * This needs to be merged with the outstanding patch for RGBA support. While
>> there may be quite a bit of conflicts, they should be straightforward
>> to resolve.
This is still outstanding of course, but is something to do post
commit. I'm hopeful that it won't be too hard.
>> * There is a somewhat bad hack in cairo-ft-font.c to deal with getting options
>> through the glyph cache:
>> I'm guessing that the need for this will go away with the promised glyph cache
Yes, that will go away. And this hack is fine as it even makes the
merge mess for the glyph cache rewrite easier. So thanks.
>> * Still to be done is making the xlib backend pick up the Xft resources from
>> the display. This should be pretty straightforward.
This second revision takes care of this. Thanks!
>> * Yes, the cairo_font_options_t API is huge and baroque. I needed it all inside
>> for Pango: the hash, equals, copy, and merge functions are all used.
This was my initial reaction to the patch. But since it all is useful
for pango, (and that's one of the primary users of all this stuff) it
should be fine. Most users won't need any of these functions to just
set a simple font option, but it shouldn't hurt too much to have them
As far as I can tell, this patch is ready to land. Thanks again for
all the hard work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050721/ccc3e40d/attachment.pgp
More information about the cairo