On Sat, 2003-08-16 at 04:25, Hans Breuer wrote: > >> 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. How can that be? We're not generally worried about compatibility between application A on platform X and application B on platform Y - and we could only solve *that* problem if all apps switched to using Cairo+Pango+fontconfig. What we are interested in is application A on platform X application A on platform Y Currently it is PangoWin32 vs. PangoXft/fontconfig. With what I was proprosing it will be PangoCairo/Win32 vs. PangoCairo/fontconfig. So, it will be pretty much the same as before. Really, font name => font mapping isn't the problem. If you have a font called Arial Bold, it doesn't take much work to find it. The problem is when you *don't* have the same font. > 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. If you don't have the same fonts, it's inevitably going to be a mess. You can try to do CSS2-style font synthesis to match metrics, but I don't think it's a terribly good idea. If you do have the same fonts, I doubt there will be much of a problem. If you store the Pango names in the Dia file, you should be able to find the same font on any platform. [...] > >> >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 ;-) Basically, what you are asking me for is to add a simple rendering API to Pango. I don't think this is ever going to be as workable as having a more powerful rendering API (Cairo) that can be used cross-platform, and that supports operations like rendering to a local bitmap well. > >> > - 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. There would only one mapping ever used by Dia on Win32, the mapping used by the Cairo backend of Pango on Win32. Whether that mapping uses fontconfig/Win32 or a separate win32-specific codebase like the current PangoWin32 backend is, from Dia's point of view, a detail. However, using a separate codebase that sticks as closely to the Windows API as possible seems to have advantages for: - Consistency of rendering between GTK+-based and non-GTK+ based applications - Getting the right fonts for the right scripts when calling Uniscribe. - Avoiding extra unnecessary overhead. Even with a great deal of optimization, fontconfig takes up 100k or so for the font database, per app. Regards, Owen
