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
