[Fontconfig] Re: [Cairo] Text API proposal

[Owen Taylor]

On Mon, 2003-08-11 at 19:13, Hans Breuer wrote:

> >We really have a number of somewhat orthogonal issues:
> I have a much more basic question:
> 
> How is Cairo spupposed to be used in the Gtk+ context and where
> are the benefits (not only on win32). 
> The only place I currently could imagine benfit from an advanced 
> rendering engine is between Gtk and Gdk (or between Gdk 'generic'
> and the platform specific backends) which would allow to do 
> fancy things like antialiased lines in widgets, rotated text (for 
> e.g. verical notebook tabs), etc.

The goal is that Cairo completely replaces the GDK rendering API,
so that all rendering goes through it. For standard widgets,
there may not be that big need for a better rendering API,
but:

 - When you do need more powerful capabilities you'll have them
 - We'll be able to use the same drawing API for printing
   as for display to the screen
 - We share our cross-platform displaay code with a much broader
   set of users. GDI+, OpenGL, Postscript, etc, backends are
   all possible.

> [
>   The (only a little outdated) dependency stack is show at
>   http://hans.breuer.org/dia/dia-devel.htm

404

>   It would be nice how Cairo would fit into the picture of
>   a high level vector application which tries to provide
>   much of the functionality I assume to be the core of Cairo.

The idea is that with Cairo dia won't have to have all it's
own code for drawing antialiased lines, zooming, etc. You'll
have a powerful, flexible drawing API already there for 
you.
> ]
> 
> If the place where Cairo should live in Gtk+ is as described
> above [probably replacing part of the current X11 backend code],
> wouldn't it be possible to simply have Cairo dependending on
> Pango for all its font issues.
> What's the use of inviting a new font abstraction when there 
> already is one (with well known and solvable limitations) ?

The problem is that Cairo as a rendering API is targetted at
a wider audience of programs than those using Pango... while
I wish Pango was the single universal solution to the worlds
text rendering problems, it isn't. The domain of use of
Pango is basically just GTK+ applications.

Cairo, among other things, is intended to replace the Xft library
that is used for text drawing for both Qt and GTK+ currently
on Unixlike platforms.

"Leth them use Pango" isn't going to work:

 - Pango text APIs require substantial rewriting of applications
   and couldn't be easily dropped underneath, say, the Qt
   text APIs.
 - Cross-platform constraints on the text APIs for things
   like OpenOffice and Mozilla. They won't be using 
   Pango/Cairo everywhere.
 - Use of GLib/GObject is not popular

> > A) Do we use native font objects and rasterization APIs when 
> >    possible?
> > B) Do we require using fontconfig for all font operations,
> >    or you can create a Cairo font object from a system
> >    font directly using system-specific API?
> > C) Do we export fontconfig-based APIs as a standard way
> >    of naming fonts.
> >
> >I think A) has to be "yes" if we want fontconfig to be useful
> >for real toolkits on multiple platforms. 
> >
> So the fontconfig api needs to be used for differnt backends, right ?
> I.e. for win32 it would be a wrapper over the EnumFontFamilies APIs.

Yes, that's what I was thinking of.
 
> >If you set up things  to allow A), B) comes naturally. If you 
> >have a CairoFontWin32 implementation of CairoFont, you  can have
> >cairo_font_win32_from_logfont(). 
> >
> See above. Wouldn't it be better to improve Pango (also for
> Cairo needs) ?

cairo_font_win32_from_logfont() would be something that 
the Win32 backend of Pango would use to avoid having to convert
a LOGFONT into a FontConfig pattern and then convert that back into
a LOGFONT.

> >C) is a little more of a tricky question - it would be nice to have a
> >consistent font listing and naming API, but I think it would be
> >premature to say that fontconfig can work as that API until
> >we have a working implementation on Windows that:
> >  
> > - Doesn't rely on direct file access
> > - Integrates with the native rasterizer rather than FreeType
> Currently it appears to me that it has to be integretable with
> both : FreeType and the native rasterizer.

My goal here is to get rid of the need for FreeType and have a 
rendering API that can use either it or the native rasterizer
in a way that is transparent to GTK+ and to applications.

>From history, I can't imagine you objecting to that goal :-)

> > - Has minimal overhead when not used (E.g. - I don't see
> >   fontconfig as useful in a GTK+/Pango/Cairo/Win32 situation,
> >   so I don't want to pay 200k per process and 100ms of startup 
> >   time)
> >
> Could my 233 Mhz notebook please be the machine to test the overhead ;-)
> But serious : wouldn't it be always used if the Pango/win32 backends
> works with a specialized fontconfig, too?

I don't really see any reason to stick fontconfig between 
EnumFontFamiliesEx and PangoWin32. I'm sure your 233 mhz notebook
appreciates that.

Regards,
					Owen