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,
