From: Kenneth Christiansen (kenneth@gnu.org)
Date: Sun Jun 23 2002 - 12:53:21 EDT
Maybe we should cc: Owen on this? I am pretty sure he has somethink to say and is interested in how pango is going to be used in Abiword.
Just my two øre,
Kenneth
-----
> 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 : Sun Jun 23 2002 - 12:47:14 EDT