From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Tue May 21 2002 - 05:33:00 EDT
On Mon, 20 May 2002, [ISO-8859-1] Joaquín Cuenca Abela wrote:
> I've added XFT support for AbiWord.
> In short, it means that AbiWord can now easily use:
>
> 1) global font configuration
> 2) detailed font metrics
> 3) antialiasing (using XRender if available)
>
> I still think that pango it's the way to go, but I guess that it will
> still take a bit of time to Tomas to finish the pango powered layout,
> and we have a lot of users that are suffering the font configuration
> problem.
>
> With this patch, you don't need anymore the abiword-fonts package to
> have abi running (you can even erase the fonts directory, and abiword
> will not complain). It will list all the fonts available through xft,
> and you will be able to use all them.
>
> Things that are still a problem (ie, it was already a problem with Abi
> 1.0):
>
> 1) Printing. (You still need to run ttftool in the truetype fonts, you
> still need adobe-full.u2g, etc.)
>
> 2) Non wysiwyg. (Now it's a more easily solvable problem)
>
> New problems:
>
> 1) It's slower.
>
> 2) Symbol font it's not working (say bye bye to the insert symbol dialog
> box).
>
> 3) It crashes when you select a big enough font. I get a:
> Gdk-ERROR **: BadLength (poly request too large or internal Xlib length
> erro
> serial 16567 error_code 16 request_code 153 minor_code 20
>
This is probabally attempting to allocate too much memory. We actually
layout text at around 1000 dpi. If you actually try to allocate fonts this
big to get metrics for layout, your wasting huge amounts of memory and
bogging down the system. Eventually it just bails out. The current logic
in xap_UnixFonts uses gdkfonts at low resolutions to calculate font
metrics. At the high resolution we use for layout I actually use the
postscript afm's descriptions to calculate the metrics we need.
This gives us a huge decrease in memory usage and a big boost in
speed. I haven't looked at your patch yet but I suspect you do not use
these. Is this true?
> The i18n support is still not finished. I don't test for the coverage
> of a given glyph in the current font, so if the glyph is not in the
> font, it just displays a void carret.
>
> If we solve problems 2 and 3, I think that we can make a release with
> these changes, but honestly I don't known what number should have this
> release. This change is not small, nor trivial, nor stable, so it
> doesn't fits for the 1.0.x series.
>
> This change is not needed in its current form for the HEAD version,
> because there we have pango that will be using the xft backend. Still,
> the HEAD version can take several months to became stable, and it will
> be a pity to leave our users without these changes all that time...
>
> Any idea? Maybe HEAD should be used to do a 2.0 release, and we can do
> a 1.2 release based on the 1.0 stuff...
>
I like the idea of giving users features they need and especially
anti-aliased text and a solution to the fonts bug. However I think the
right solution would be to use pango and fontconfig.
I definately like the idea of leaving AbiWord 1.0.x lean and mean with
it's lean warts showing. It fullfills a role in the spectrum of
WordProcessors. In particular it is the only viable word processor on
underpowered Linux systems. Ideal for PDA's and old hardware ( think
schools and 3rd world).
> Btw, some of the code in this patch should go to the 1.0 and HEAD (the
> code out of #ifdef USE_XFT).
>
> If you want to test the patch, you will need a system with XRender and
> XFT (you will need XRender because I look for it in the configure.ac,
> but it's not really a must...)
>
> Cheers,
>
> P.S.: screenshot here: www.ie2.u-psud.fr/~cuenca/abi_xft.png
>
I'll try to take a look at the patch over the next day or so.
I must admit I haven't got a clear idea of what will happen to our Unix
font code which really needs to be fixed regardless of the XP Pango
solution Tomas is working on. Can someone enlighten me?
Perhaps a better solution would be to finish the port to gtk 2.0?
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Tue May 21 2002 - 05:37:13 EDT