From: Joaquin Cuenca Abela (cuenca@pacaterie.u-psud.fr)
Date: Fri Jun 21 2002 - 20:14:20 EDT
Hi Dom,
well, I disagree :)
reasons below.
Dom wrote:
> On Fri, 2002-06-21 at 17:36, Martin Sevior wrote:
>
> > Is there any reason this should not be committed to HEAD Real Soon Now?
>
> I can think of one or 12 reasons off the top of my head, but the first
I hope that it was 2 reasons ;)
> one that jumps to mind is that we decided to use Pango and Freetype to
I agree with Pango. I'm still not entirely converted to Freetype XP. I
would still prefer to render using platform specific APIs.
> do our font dirty-work. Freetype is a *very* high quality XP solution.
> XFS and friends actually use freetype2 to do the majority of the work
yes, but here server fonts are off-topic. We're speaking about Xft, not
Xfs.
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). Nor gives you a
way to transport your nicely rendered glyphs from the X client to the X
server.
That's what Xft is all about. Freetype renders the glyph, if the X server
has the X render extension, then it serves freetype glyphs through the X
render extension, otherwise it uses the old X API (10 times slower, but
still acceptable). The fontconfig part (very basically) gives you a way to
list the fonts in the system.
Of course, you may very well want to redo your own way to configure the
fonts, but then I will (very) strongly disagree (and I think that also users
will strongly disagree).
> for them. Sure, parts of Cuenca's patch should be applied regardless
> (eg. spurious redraw code in the formatting engine), but this wasn't the
> direction we were going for in HEAD. At least not to the best of my
> knowledge.It's certainly not the direction I want HEAD to take. Feel
> free too disagree.
Once we pass the freetype only part of the discussion, we should center on
the pango part.
As Dom says, the plan was to use pango, so what's all that Xft stuff here?
Is it taking pango job?
Nope. Absolutely not.
Pango is all about changing contextually glyphs, finding line/word breaking
opportunities, knowing if a font covers a given glyph etc.
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.
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 (that we can keep anyway, and that I need right
now to get Insert Symbol working).
And the printing part is quickly becoming the bulk of my patch. For the
printing stuff I've been looking at Qt printing code (very nice API, btw),
and gnome-print. From what I see (caveat: I've only been looking at the
mailing-list of gnome-print, not at the code), the Qt code is much more
advanced than the gnome-print counterpart (it has subsetting and full
support of truetype fonts, both converting to type 42 and converting to
type1). But by now I've just taking the fastest path, I took Tomas code and
make it work on the fly, but in the future we may want to use the Qt work.
Now, I have some reasons to not commit the patch:
1) speed. Entirely related to not caching anything at all. You can see
that render speed is at least so high as the old backend doing a global
expose in the AbiWord window (you will see that it draws as fast as usual),
but everything that takes big relayouts starvs. You can also see it sucking
in the insert dialog.
2) type 1 fonts not yet working in the printer. When I have a bit of time
to code (instead of writing emails :) I will finish to fix it.
3) assuming "Times New Roman" exists. (Not true anymore if we plan to work
out-of-the-box on any X server without providing any fonts)
Of course, if you MS fonts installed, everything works smooth and dandy :)
If people is not concerned about these (technical) problems, I will start
committing, but first I want to double check that developpers have
Xft2/fontconf installed, or wait until I put them in peer libs.
Cheers,
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 20:12:05 EDT