[Cairo] Text API proposal
otaylor at redhat.com
Wed Jul 30 07:12:30 PDT 2003
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
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 at fontconfig.org since this mail is
largely about fontconfig; sorry for the wide distribution.
> So, I have two questions:
> 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,
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 =>
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
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
> 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
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
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.
More information about the cairo