[cairo] font lifetime

[Owen Taylor]

On Thu, 2005-01-27 at 09:17 +0100, Alexander Larsson wrote:
> On Wed, 2005-01-26 at 10:44 -0500, Owen Taylor wrote:
> > On Wed, 2005-01-26 at 16:17 +0100, Alexander Larsson wrote:
> > > 
> > > Its a bit sucky to use actually. You can create a cairo_font_t using it,
> > > and then set it using cairo_set_font(). However, any time you change any
> > > state in the cairo_t "_cairo_gstate_unset_font (gstate)" will be called,
> > > and the next time you render text cairo_gstate_ensure_font() will try
> > > create a new font using _cairo_font_create() instead of your own font.
> > 
> > The expectation with the new API is that you'll set a font just before
> > using it.... we could remove the unsetting, but then you get silent
> > metric screwiness rather than the wrong font. What sort of gstate
> > changes are you making that are unsetting the font? It should just
> > be transform and target surface that unset the font.
> 
> Given the way xpdf works internally this is not a real problem for me.
> xpdf tracks all state changes and knows when it has to update the font.
> 
> However, it does seem to make using the cairo-ft.h interface a lot
> harder to use in general.

Well, the cairo_ft_* functionality wasn't really designed for mixing
with toy API, which seems to be your concern. Given an abitrary 
FT_Face, I can't necessarily implement _cairo_ft_font_text_to_glyphs,
so cairo_show_text() might not work.

Basically, the intent was for low-level usages like the xpdf backend
or Pango. 

It should be noted that the FreeType backend ft_unscaled_font_t is
*not* an appropriate object for a "cairo_set_unscaled_font" because
it corresponds to a file/id and doesn't contain information about
things like hinting and anti-aliasing. In fact, for the FcPattern
case, different scale factors can give you *different* file/id pairs.

Could things be reworked to support the mixed toy/low-level usage.
Probably. It would get pretty complicated, however.

[...]

> > > What you really want is a way to create a cairo_unscaled_font_t from the
> > > face, and then scaled versions from that. I think.
> > 
> > That's certainly possible, all the bits are there internally, they'd
> > just have to be exported.
> > 
> > There's a bit of a problem in that there isn't necessarily and
> > "unscaled font" for every backend. The Win32 font backend, for example,
> > probably won't have one. So, you can't have
> > 
> >  cairo_font_create_for_unscaled_font()
> >  cairo_font_get_unscaled_font()
> > 
> > Just:
> > 
> >  cairo_ft_font_create_for_unscaled_font()
> >  cairo_ft_font_get_unscaled_font()
> 
> That sounds good enough for me. In fact, given an API like this cairo
> could even generate a new custon FT_Face cairo_font_t in
> _cairo_gstate_ensure_font().

Not easily. But I'll try to get something in for the memory management
part.

Regards,
						Owen

-------------- 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/20050127/af48473c/attachment.pgp