Quoting Andreas Beck <[EMAIL PROTECTED]>:
> > It looks like you have to use the freetype library.
>
> Ah - I see. But that somewhat defeats glyph caching - right ?
I haven't looked at freetype internal but I strongly suspect that they
do glyph caching.
> rendering engine. We might want to add other renderers (e.g. pixel
> fonts,
> Type1, etc.) later.
>
> > Just a comment on the api: since all functions require a font
> argument,
> > wouldn't it be more convenient to keep a font context for each visual,
> > accessed via Set/GetFont calls?
>
> Then you would have to make it a LibGGI extension. A good thing to do
> anyway IMHO. I will gladly give guidance on that point.
>
> Having it as an extension might as well enable us to make use of native
> font rendering abilities of the target, like in X ...
>
> And as usually switching the font is relatively rare, yes, I'd think it
> would be a good idea to have some notion of the "current font".
yet another idea:
Instead of having a single ggi_font as a context, we could define
a 'ggi_font_set' that would map unicode chars to different fonts (face?)
for rendering, like you want to use Helvetiva for latin1 chars,
another font for cyrillic, yet another one for kanji/kana
and so on. When you render a string, each glyph is automagically rendered
with the proper font.
