At 19:56 11.08.03 -0400, Owen Taylor wrote: >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. > This would mean to write Cairo backends based on GDI+ (which IMO is only a half baked C++/C# wrapper around GDI), OpenGL etc. And almost throw away all the current Gdk backends ? Still the question arises what would be the benefit for cross platform application developers to use Cairo instead of the current implementations? >> [ >> The (only a little outdated) dependency stack is show at >> http://hans.breuer.org/dia/dia-devel.htm > >404 > Yeah, I shouldn't assume my local tree is in sync with the public one. Now fixed. >> 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. Given the number of current output facilities of Dia (gdk, libart, svg, wmf, hpgl, gdi to printer (via wmf), two PostScript - one with embedded outlines, xfig, cgm, dxf, wpg) this would either mean to write a bunch of new backends for Cairo or keep much of Dia's rendering code around. >> ] >> >> 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. > I still fail to see how Pango and Cairo should play together. If both do their own independent name to font mapping things will get worse than now in respect to applications which try to have cross platform file interchangeability. One of the font related problems of Dia is that the diagram layout depends on the correct font sizes (string width is more important than height here). It was a mess in the pre Pango time - where the win32 fonts were mapped through gdk_font_list_new() which emulated xlfd font names to be compatible with XListFonts usage. Though IIRC the mess was bigger on X11 based Dia with Xft on display and trying to map that to PostScript names. >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 > Yeah, it appears to be more popular to solve the same problems (here : X11 and other OS's graphic subsystem design clashes) over and over again ... [...] >> >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 >> > - Integranjhmtes 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 :-) > My goal is not to get rid of FreeType but to only use it if it really needs to be used. If there can be a generic api in Pango to abstract away the backend specifics (implement such simple things as rendering to a bitmap or getting the glyph outlines) I'd much prefer to implement such instead of having the same (or similar) platform specific code in all applications which need them - or worse : being forced to use two font rendering machines with huge overlap in capabilities but independent configurations in one application. But to me this looks like a small gap in the current Pango api which can and should be fixed to become historical ;-) >> > - 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. > What I meant was : there should be only one master list of available fonts presented to the application. This one could be provided by a win32 specific fontconfig. If there is more than one such list the mapping between font description and real font will get out of sync sooner or later an impose the same problem as with two font rasterizers with independent configurations. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
