From: Joaquín Cuenca Abela (cuenca@pacaterie.u-psud.fr)
Date: Sat Jun 22 2002 - 15:18:35 EDT
Hi Tomas!
On Sat, 2002-06-22 at 11:22, Tomas Frydrych wrote:
>
> > 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().
To be honest, I don't really know if these functions will do the work.
We have to position glyphs at exact positions (not extracted from
default scapements). PangoGlyphString has associated to each glyph a
PangoGlyphGeometry with:
PangoGlyphUnit width; // the logical width to use for the the
character.
PangoGlyphUnit x_offset; // horizontal offset from nominal character
position.
PangoGlyphUnit y_offset; // vertical offset from nominal character
position.
I don't understand the comments. What's the nominal character
position? And what's the logical width?
If these offsets are used to "glue" together glyphs in scripts as arabic
when using the Nastaliq style, I think that using them to fine
positioning the glyphs to match the printer output is not going to work
too well (it should leave holes between glyphs in scripts that expect
glyphs to be glued together). But I may be completely and absolutely
wrong here.
Anybody understands what these variables mean?
Anyway, we may need to get to freetype tables to get printer metrics.
So what do you think of the next plan:
Integrate entirely the patch in HEAD. While pango support takes shape,
fix abiword layout code to become WYSIWYG, and fix the horrible mess of
fonts that we have in the unix side.
If at the end we can do everything in pango, then nice. You just will
have to deal with the changes from XftDrawString to pango_*_render.
Here the changes between having Xft or not is not very important (if we
don't have Xft we still have to change from XDrawString to
pango_*_render).
So in short, Xft will solve some severe problems that we have now, and
if later pango proves to be a better way to solve some/all of these
problems, Xft code should not be more difficult to convert to pango than
the current X code (I hope that it will be easier). As a bonus, you
gain printer support of fonts on the fly, WYSIWYG, reduction of spirious
redraws, much cleaner X fonts handling etc (code that I guess it's going
to stay there with pango)
> 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
Once you have your PangoGlyphString, you can convert it to XftGlyphSpec,
and draw it using XftDrawGlyphSpec. But if pango_*_render is up to the
task, I'm all for using it.
> 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.
I have no problem integrating our PS code in pango, but that's going to
be *highly* non trivial. It will take even more time than just getting
pango integrated. Maybe it's the right way[TM], but it's an expensive
(in time) way, and maybe we should just leave that for the next version
(3.0?).
> > 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.
discussion follows in the next post, then :)
Cheers,
-- Joaquín Cuenca Abela cuenca@pacaterie.u-psud.fr
This archive was generated by hypermail 2.1.4 : Sat Jun 22 2002 - 15:21:24 EDT