Around 23 o'clock on Aug 11, Owen Taylor wrote: > I guess I'm pretty set on an OO mindset these days. :-) I definitely > see "a few extra win32 methods" as being inheritance rather than just > some extra code we compile in on Windows. Ok, so I guess the plan should be to always expose the native fonts as the "normal" API; you get cairo_font_win32 functions on the Win32 version of cairo and cairo_font_freetype functions in the Linux version of cairo. Code which can't deal with that isn't portable. I can live with that, especially if we can provide the FreeType functions in Win32 as a bag-on-the side separate library for weird apps that want it. > I'd tend to say that if we are going to have multiple font > implementations, especially on the same platform, but even if not > on the same platform, virtualization makes a lot more sense than a > bunch of #ifdef's and switches. Certainly there should be abstract datatypes which are independent of the underlying font system; otherwise we'll all go insane. The question is how much functionality should exist at that level. I'd like to make sure enough exists so that most of the output code can be system independent, even if the fancy font selection and layout code is heavily system dependent. > If you mean "an application that can handle Arabic and Hindi and Thai > and all the other languages of the world that anybody wants to display", > then there are two routes: No, I plan on leaving cairo at the glyph level; anything else is clearly a bad idea at this point. When layout libraries are better defined, we may be able to standardize on a single one on top of cairo, but that's not the right thing to do at this point. I guess I'd like to see the actual rendering code able to use system-independent functions; once the fonts and glyphs are selected and positioned, it would be nice to have everything else use just cairo_font_t. It would also be nice to provide system independent functions to deal with font selection, but I'm not sure that's a great plan given the differences between the various systems. Perhaps we really do just want a cairo_freetype and cairo_win32 library for all of that and force applications to choose which underlying font selection mechanism is to be used. > I don't think there is anything wrong with having an API at the > approximate level of Xft in Cairo, but Mozilla has all sorts of > ad-hoc FreeType and TrueType table access in it where it goes beyond > Xft Yeah, Xft is about the highest level I'd consider doing; something that takes unicode and maps each codepoint to a single glyph and sticks them adjacent on the screen. > I'm not quite sure what the underlying mechanism is but the XP font > selector knows the scripts supported for each font. I wouldn't be surprised if it was just using the OS/2 codepage range bits. > You probably could also compute language coverage information and cache it > much as we do with font files. I'd rather just bail on fontconfig for win32 and make you suffer there by providing cairo functions that took preselected win32 fonts instead. Having us design a Win32 API seems like a really bad idea... > And if Cairo allows replacing the font system at runtime, it will be easy > to hook it up. We'll have to be careful in designing the internal interfaces that implement font stuff so that we can plug in separate datatypes and have them work, but I don't think it's impossible. Stick the FreeType stuff in a separate library and just make applications link against it explicitly. We could do the same with the Win32 font stuff; that way the core cairo library would be the same and the differences would be isolated to external libraries. I think we're converging on a reasonable direction here; don't pretend to be os-independent when applications are explicitly interested in os dependence. -keith
