> 1) Extension library
> This is all an extension library I modeled after libXMI.
Ah good. This allows to tie into native rendering capabilities in targets
and to do target specific acceleration.
> 2) Global wrapper lib
> I gave this a try and I'm not sure this is the way to go. I think
> adding a wrapper doesn't add much functionality and could ultimately
> limit what the user can accomplish rather than enhance it because
> everything has to go through the wrapper. The wrapper might be
> incomplete or fit poorly with different libraries. No doubt that it
> would seem "cleaner", but I couldn't get this to work to my
> satisfaction.
Freetype (1 or 2 BTW ?) is a good starting point I think. Given your API I
think it would fit well with most font renderers. Only font selection
would need to be worked out.
> 3) SetFontFace routine
> This is a thought. Hmm... a font as a property of a visual. I'm
> starting to grok some possibilities. I think this may be a good idea, it
> could help with caching and such. The more I think about this the more I
> like it.
Yeah. The active font would receive higher precedence for caching, and
actually one could cache the font as SetFontFace-time.
> 4) PrintGlyph vs PrintChar
> Yes. A font has two ways of looking up the character. a)(PrintChar)
> the character code (ascii, unicode...), b) (PrintGlyph)the index of
> the array of characters.
I see.
> 6) Thanks.
> Yes there's more to making an API than it appears at first. Your
> comments are very helpful.
You're welcome. Commenting is the very least I can do. If you have any
questions on extensions, API design and such, feel free to ask - I had some
practice with that in the past :-).
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
