On Tue, 2003-07-29 at 23:36, Carl Worth wrote: [ I've cc'ed a couple of our Windows developers on this mail; Tor/Hans if you want to see the rest of this thread see http://cairographics.org/pipermail/cairo/2003-July/000273.html The issue here is font support for Cairo; which is likely to be the primary rendering API in future versions of GTK+. I've also Cc'ed fontconfig@xxxxxxxxxxxxxx since this mail is largely about fontconfig; sorry for the wide distribution. ] [...] > So, I have two questions: > > fontconfig > ---------- > Does anyone have a problem with Cairo exporting fontconfig as > proposed? fontconfig is quite portable and I, (speaking as a user), > would love to have a standard cross-platform means for naming fonts, > etc. I don't necessarily have a problem with using fontconfig on non-Unix systems, though I do have some concerns. - The set of fonts listed has to follow the system set of fonts pretty much exactly and automatically; any approach that requires separate user configuration of fontconfig isn't going to work. - The end result of fontconfig pattern resolution is currently a filename. This doesn't work on Windows, since you can't use the system font API's with a filename. So, that would need to more flexible. - It's important to be able to go from: system representation of a font [LOGFONT on windows] => fontconfig pattern matching => fontconfig pattern result => rendering And get a result that is consistent with the rendering going through the system directly. Otherwise, things like matching the default system font won't work. - There may be some concerns with interaction with interaction with system rendering API's like Uniscribe and ATSUI - Thorsten may know better there. I think it probably does work out for Uniscribe; in Pango, we already put Pango font matching ahead of Uniscribe. But my understanding of ATSUI is that it is higher level; more "paragraph" based, and it may want to do font matching itself. You could say that you are only using fontconfig for the "toy api"' and leave the low level API open, but the idea of requiring fontconfig for GTK+ on win32, then not using it, isn't all that attractive... > Freetype > -------- > Does anyone have concrete suggestions for what API to push down into > Cairo in order to abstract away Freetype? If someone smart can > convince me to do that, and tell me how, I might be able to overcome > my laziness. My suggestion is that you don't try to "abstract away FreeType" but rather you allow a font-system specific implementation of the Cairo toy API, which is going to be a much, much smaller API. The list of operations that I gave in my previous mail was meant to be (approximately) complete. For the toy API, you need: - Load a font from a name - Convert Unicode text to glyphs And for the real API, you need: - Scale/Apply a transformation matrix to a font - Render a glyph to a bitmap - Add a glyph to a cairo path And that's all Cairo needs to know about the font system. > Or, another option is to give in to my laziness, not invent a new > interface, but declare that the Freetype API is good as is. With that, > we would just require the abstraction to happen below Cairo. That is, > if someone wants to use a non-Freetype renderer below Cairo, they > would have to write a Freetype-style wrapper above it for Cairo to use > and export. Does that make sense? Do such wrappers perhaps exist > already? No, I don't think that makes sense: - The FreeType API is really large - The FreeType API is quit fluid; there are additions in almost every dot-release of FreeType. - The FreeType API is in not compatible with the font API's on other operating system.. it is far too detailed; the only way to implement the FreeType API on windows would be basically to dump out the contents of each font table and run FreeType on that. Regards, Owen
