Re: GTK+-2.x planning

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

> Around 0 o'clock on Mar 13, Havoc Pennington wrote:
> 
> > Probably overboard to call the function
> > pango_this_hoses_half_the_world_shape() isn't it ;-)
> 
> My thought was just to add a function that parallels the current font/
> fontset open function but takes a Fontconfig name (or XLFD if you want) and
> returns an GdkFont object that draws with Xft.  Easy as pie, and provides a
> trivial migration path.  The one trick is with font listing; I'm not sure 
> what functions Gdk provides for listing fonts, but it's probably not very 
> similar to Fontconfig...

GDK provides _no_ functions for listing fonts... you have to use Xlib
directly for GTK+-1.2. (Though a listing function would have used
XLFDs...)  This is just one of many breakages in GdkFont in
GTK+-1.2... the other major one is that all the functions have screwed
up assumptions about encoding

If we want to provide simple Xlib-like string functions, it's probably
still best to do them at the Pango level because:

 - They should share the same font listing and font naming as the
   real functions. 

 - Our portability setup for fonts lives at the Pango level.

 - It's much easier to share caching and so forth between real
   and fake text handling at the Pango level.

 - We need to keep GdkFont deprecated, because 90% of the interfaces
   using it have messed up encoding assumptions and we won't get
   people to fix them if they can just copy over code and it still
   works for ASCII.

I certainly would like to move toward the goal of using fontconfig / Xft2
as much as possible. 

Still, I think we are going to have to keep an reasonbaly thick
abstraction layer over it because of portability concerns to other
platforms.  I think using fontconfig / Xft2 on Windows would be
considerably suboptimal.

We'll have to do some thinking about how:

 - Direct outline access / rendering to application buffers (in the
   style of the FT2 backend)
 - OpenType support
 - Printing

Can be done in a way that is unified across the different "reasonable"
backends, while letting the core X backend slowly slip into oblivion.

(RENDER really needs to be finished before I would start feeling
comfortable saying: "you don't have RENDER? your fonts are slow? Well,
tough." Or does there need to be a defined RENDER subset that excludes
the unfinished parts?)

Regards,
                                        Owen