From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sat Jun 22 2002 - 05:22:17 EDT
Hi Joaquin,
> I agree with Pango. I'm still not entirely converted to Freetype XP.
> I would still prefer to render using platform specific APIs.
There is nothing stoping us from using platform-specific API's
eventually, except that these are only properly working on *nix, and
partially on win32. Until someone ports Pango to all our platforms,
we have to have XP FreeType code to use Pango; there is, of
course, no reason, why someone could not implement *nix and
win32 specific code alongside it, but for purposes of debugging the
Pango code, it might be easier to get the XP FreeType version
working first.
> Xft don't uses Freetype2 to do the majority of the work. Xft uses
> Freetype2 to do *all* the work. *BUT* freetype2 don't gives you a way
> to get the font files in your system (because it works even in systems
> without harddrive, I've been said, so that would be too platform
> specific).
True, but Pango manages fonts for us, using reduced version of xft
if xft is not available. This means that with Pango, we will have a
single XP font manager and do not need to talk to xft directly.
> Once you have the right glyphs and you know how to layout your text,
> you still need to... draw it (and print it)! and believe me here,
> pango is not yet usable by us to draw the text on the screen (and even
> if it becomes usable to do that, the only change is from
> XftDrawString32 to pango_xft_render), and it has 0 support for print
> (its metrics are a bad joke...). You can look at it like you want,
> but there is no way we can do our job without using at the very least
> freetype API (so we should get from pango to the underlining XftFont,
> and from there to the freetype face), and in the current state of the
> code, we even need access to the real metrics files.
As far as screen is concerned, I do not think this is true Joaquin.
We have to process our text with pango_shape() and then draw it
with pango_*_render(), in the XP code pango_ft2_render(). We do
not need to interface with FT at all for this (we have to patch
Pangoft2 slightly to be able to do transforms, but we do not need to
talk to FT). Also, there is no easy way to draw the text preprocessed
by pango_shape() with anything else than pango_*_render(); you
cannot just replace XftDrawString32 with pango_*_render() -- I think
if we find Pango capabilities inadequate, the answer is to patch
Pango, whether PangoXft or PangoFt2, not to mix Pango code with
direct access to xft withing AW.
As far as printing is concerned, you are right, there is no support in
Pango. The thing is though, that once you start shaping with
pango_shape(), you might just as well write the PS code as a patch
for Pango rather than a PS code for AW, since to use FT directly
for this you will have to translate the internal Pango structures to
something you can feed FT, and the logical place for this is Pango,
not AW.
> Now, if you look at my code, the *only* overlapping part between the
> Xft support and the pango plan (at least as I see it) is the
> getCoverage function in GR_UnixGraphics
I do not see direct access to xft/X/win32 drawing API as easilly co-
existing with using Pango at all. We either use xft directly or access
it via Pango, but preferably not both (just as we do not want to mix
gtk and direct X calls). So, I would be inclined to have your code to
go to stable once it is stable, because it deals with some serious
problems and gets rid of the *nix font mess we are in. I am
somewhat reluctant to have it go to head, because I do not think it
will live easily with Pango. This raises questions of further
development strategy for which see my next post.
all the best
Tomas
This archive was generated by hypermail 2.1.4 : Sat Jun 22 2002 - 05:26:34 EDT