[Cairo] Text APIs round 2

[Keith Packard]

Around 16 o'clock on Aug 14, Owen Taylor wrote:

> Is the lack of a 'scale_font' or a size in select_font intentional?

Hmm.  It seems like having scale_font/transform_font functions separate 
from select_font would avoid needing those varients of the os-dependent
functions.  If you can't change the scale of an existing font, then the 
scale should be supplied when the font is created, otherwise it should be 
supplied in a separate call.  I'd vote for making fonts unscalable; it 
makes using bitmap fonts much more practical and avoids issues with 
partially specified 'fonts' doing weird things when you start drawing.

> I think you might want to reduce the set of out parameters here
> with a judicious structure or two. E.g. the XGlyphInfo
> structure of XftTextExtents, or pango_*_extents() pair
> of &ink_rect, &logical_rect.

Ok, I think that will be cleaner.  However, I think we should have a
cairo_text_dx function that returns the X (and Y?) escapements for "dumb" 
applications that just want to do spacing.

> For Pango, my plan for vertical writing is that dy == 0 by
> definition, but I guess the convention for Postscript is
> that dx == 0 for vertical writing.

How does this work?  Does vertical writing perform no automatic layout?

Note that some fonts include both horizontal and vertical layout 
information which can be selected at load time (not that the trivial API 
will ever expose *that*...).

> I tend to agree with others that the inclusion of the font here
> is vaguely annoying. It's not necessary for efficiency, and
> not really necessary for correctness. 

It is an efficient win -- I can generate a single compositing call for
all of the glyphs.  For Render that's a single protocol request while for 
core X, it's a single get/put image.

Not having this varient eliminates this relatively modest performance 
improvement

> Pango uses the position-but-no-font variant of the Xft API.

That's a bit surprising.  Note that there is no affect in the wire protocol for 
using the font-per-glyph API; Xft merges sequences of glyphs using the 
same font into a single chunk.  We found it much easier in Mozilla to let 
Xft manage that task than to do it in the browser, but perhaps complex 
layout means you're already doing quite a bit of work every time the font 
shifts.

> But not really a huge deal, and a small API without a million
> premature variations is definitely good.

Yeah, that's the goal.  Xft definately suffers from a combinatorial 
explosion of rendering options.

> What's the relationship between the size in the FcPattern
> and the scale parameter?

I'm not really sure; we can either have it override any size found in the 
FcPattern or ammend it.  I'd vote for the former.

> If this a transform that is composed with the current user=>device
> transform, like in Postscript's makefont?

Yes, that's the intent -- this call should do pretty much what makefont 
does.  But, that requires a cairo_context_t, doesn't it...

> I'm not sure that the treatment of sizing here is coherent. 
> A FT_Face is tied to the pixel grid, So, I don't really see
> how we obtain one independent of a cairo_context_t.

Hmm.  Looks like cairo_font_t is going to be per-cairo_context_t; the 
alternative is to bind them very late in the process which seems like a 
pain (because you'll have to associate them before you can do
anything) and not very useful.

> I'd definitely have the feeling that scale/transform should
> be in the generic API. Since they are presumably relative
> to the current transform not to the pixel grid, I'm not sure
> it's even *possible* to implement them at the font-system
> specific layer.

Can you 'rescale' a font?  What does that mean?  What happens if you never 
scale a font?  If we can rescale fonts, then the binding between a font 
and the underlying os-dependent structure is going to change whenever this 
happens, so any previous fetches of that object will be invalidated.

> _destroy() as well. The toy API is going to need a generic
> way to destroy a cairo_font_t, so it might as well be part
> of the public API.

If we eliminate the os-dependent datatypes, then _destroy() can be generic.

> > Should we support bitmap fonts at all?

> I don't think there is any particular harm API-wise 

I'm concerned about the effect of needing to lazily bind names to fonts 
that this will cause.  If we support only outline fonts, then the scaling/
transformation really is independent of the font selection which realy 
does change how the internals would work.  This is visible because we can 
return the underlyin object.  Also, what does 'cairo_font_scale' mean when 
you hand an FT_Face to cairo which has only a single fixed size in it?

If we can say that bitmap fonts aren't supported, then we really can 
support rescaling/retransforming fonts after they've been selected.

-keith