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 > [EMAIL PROTECTED] >
