Around 18 o'clock on Aug 11, Owen Taylor wrote: > I don't think even linking to FreeType on, say, Windows is right; for > various reasons: Hmm. I'm thinking of applications that want to generate identical results on every system; using different font mechanisms makes that very difficult. One obvious such application is a cairo test suite... > - Having cairo_font_t be polymorphic on a single system is going > to be confusing and lead to problems where people assume that > a font *must* be a cairo_font_win32_t. Hmm. Perhaps we don't need a 'cairo_font_win32_t'; all we really need is the ability to convert from an FcPattern to a windows font handle (HFONT?) or FT_Face. > It isn't a bad idea to allow people to plug in a new font > system on the fly if they are doing something really custom, but > having two font systems always there is rather peculiar. Hmm. That means that cairo applications will only be portable if they use the trivial interface; those using lower level interfaces will need system specific code. I think this means we should build an intermediate interface that provides enough flexibility for "reasonable" applications to succeed without needing operating-system specific code. I think it should be possible to have an application like Mozilla run on top of the cairo API. > This is an appealing choice, as long as the goals mentioned in my last > mail are possible: consistent list of fonts with the system, and minimal > overhead when not used. I believe we can map fontconfig patterns to windows font selection structures. Some functionality may be lost; I don't believe Windows has any notion of language support in the font infrastructure. > Does this intermediate state of caring make sense? You shouldn't get one > rasterization if you "don't care" or "really care", and a different > rasterization if you "kind of care". Instead of 'kinda care'/'really care', I should have said 'prefer portability'/ 'prefer native fonts' -- it's a question of whether applications should be forced to support win32 fonts when freetype could just as easily be provided. > What do you mean by an "abstract interface"? Do you mean a generic > interface that goes beyond being useful for don't-care applications? Yes. I don't want to provide a complete interface that masks the differences between FreeType and Win32. That seems like a bad plan... -keith
