Hi,
> > 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.
Hmm - I saw a large speed increase, but that might also have been because I
cached in a very blit-friendly-way.
> > 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.
Hmm - while it is an interesting idea, I think it would probably rarely be
needed. When you are messing with multiple national language pages at once,
automatically selecting a suitable font is probably one of the more trivial
problems ... you also have to take care of your screen layout, as the
direction of writing differs between languages.
I suppose it is already a headache to write a hebrew or arbian editor for
say a programming language: statements are english left->right, comments
go right->left, but it gets really messy, if you try this e.g. in japanese
...
I'd rather leave that to the programmer for the rare cases where it is needed
(*grin* I'm a strong advocate of unifying all languages ... :-) I'd rather
ditch my german mother tonge, with all its wonderful possibilities to build
really complex sentences, if I could talk the same language all over the
world.) or define a higher level function that would take care of it,
say gfrMagicFontSelPrintChars(...);.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
