> I'm a bit confused, as I don't fully understand the goal of a font library
> in GGI. FreeType2 is a wonderful little framework and it it certainly a good
> idea to bridge it from GGI. However, I don't think that the right approach
> is to write a wrapper library. the FreeType2 API isn't fixed yet, and there
> is more to come (text processing, layout).
Sure. IMHO the idea is to build something that wraps around _any_ possible
font rendering backend and takes whatever that backend spits out and pushes
it to a LibGGI visual.
> FreeType2 uses a rasterizer to generate bitmaps from the glyph descriptions.
> I'm not sure how flexible that rasterizer is but I could imagine that this
> is the ideal entry point for a 'ggi target'. Providing that you could not
> only speed text rendering up by avoiding unnecessary blits (if the right
> pixel layout is known when the glyph is first drawn),
You can pretty much generically cache the bitmap or aliasmap, if you sacrifice
subpixel accuracy, which is rarely needed.
> but also by providing hooks into the hardware for glyph caching, if
> applicable.
Yes. That is why I suggested to make it an extension, as an extension knows
about the target it is running on. On the X target e.g. it might be as trivial
as hooking into the native X font support.
> Please consider that a font engine is a very complex project in its own
> right, especially if you want to provide features such as unicode support,
> kerning, hinting, etc.
I don't think anyone would want to fully reimplement freetype ...
> If you are seriously interested in professional font support for GGI, you
> might communicate with the freetype developers and see whether something
> long the above lines could be worked out.
I don't quite get your point right now ... maybe there is some misunderstanding
on one side:
As far as I get the proposal, he has made up a few calls for LibGGI that will
render a given font onto a visual. How those internally work isn't really
interesting to the user. However for the implementation, it is surely the
best idea to link to freetype and just use its rendering capabilities.
> Notice that this is the same argument I gave when we discussed a
> dvi/ps/pdf viewer for GGI. There are already very powerful tools,
Ah - now I seem to understand ... you are basically trying to say we should
put a GGI rendering module into freetype, not use freetype, get its result
back and draw that to a GGI visual - right ?
Well - I think that would complicate freetype very much for not much gain.
The point is, that for proper (i.e. accelerated) font caching it would have
to be an extension. That would put quite some code into Freetype ...
Font caching itself is rather trivial, and the amount of RAM required to
just cache a whole font at a common size is not that high. So I think in
this case, just asking freetype to render the whole font _once_ and then
convert it to a target friendly representation and cache that should be
just as efficient as putting all those target friendly blitting functions
into freetype, thus bloating it quite a bit.
> all that is needed is a GGI backend. You don't want to reinvent all that.
Right, but in that case I don't think it is worth the bother to dive into
the freetype internals for that.
It makes sense for stuff like a ps viewer, where all the output is used once
and then forgotten. In this case you have quite some overhead by the inter-
mediate representation (like sending pgm along a pipe). But with fonts it
is a "generate once - use often" relation ... I think we can tolerate the
slight impact on speed for the comfort of not having to mess with Freetype
internals too deeply.
How does Berlin handle that problem ? Do you tie into Freetype, or do you
ask it to render the fonts into a buffer and push that towards your
display ?
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
