[Cairo] Text API proposal

[Owen Taylor]

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 at fontconfig.org 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