Around 20 o'clock on Aug 1, Bradley T Hughes wrote:
> Also, Qt doesn't use Xft unless the RENDER extension is present. Yes, I know. There's no longer any reason for this restriction. Client side fonts are a big enough win for applications that allowing apps to use them without regard to the capabilities of the X server is very nice. Irrespective of the improved display quality, the direct access to font files means you can display text correctly and also print precisely what appears on the screeen. > This is because Qt has always done it's own core font loading/matching etc > (especially since it will compose several fonts together to cover as many > unicode ranges as needed). You're welcome to continue to support core fonts in this way, but fontconfig can perform this matching more precisely using client-side fonts. I use this interface for both Mozilla and Pango today; we should get it integrated into Qt. Fontconfig knows the precise Unicode coverage of every font on the system, so this kind of matching is fast and accurate. > So how does this work? Rendering the glyphs into 1bit pixmaps, and then > drawing them somehow? For TrueColor visuals, Xft will actually do GetImage/PutImage to perform compositing just as if Render were present. On PseudoColor visuals, Xft draws non-antialiased glyphs. Of course, you can disable the AA stuff on TrueColor visuals as well to improve performance. AA performance is acceptable for local displays, non-AA performance is acceptable for remote displays. > We will have to evaluate this more later. Tying youself to Xft1 compatibility will make integrating the advanced fontconfig features quite difficult, but at least for now, let's make sure Qt can draw AA text without an artificial restriction to servers with Render. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
