[Fontconfig] Re: [Cairo] Text API proposal

[Hans Breuer]

At 14:29 11.08.03 -0400, Owen Taylor wrote:
>On Mon, 2003-08-11 at 12:24, Keith Packard wrote:
>> Can I use Windows (or OS X) apis to get the outline of each glyph?  
>
>Both of these are certainly possible with the Windows API; you
>can get the outlines and you can get the contents of individual
>TrueType tables. On the other hand, it's really hard (possibly
>impossible?) to get the filename for font located through the
>the Win32 APIs.
>
Cause it is possible to embed font data in process resources
you are probably right that there is no sane way to always 
get on the font file.

>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 (only a little outdated) dependency stack is show at
  http://hans.breuer.org/dia/dia-devel.htm
  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.
]

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) ?

>
> 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.
 
>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) ?

>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.

> - 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?

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert