On Sun, Aug 08, 2010 at 04:52:28PM +0200, Fred Kiefer wrote: > > This then eases some other clean ups and fixes I spotted. > > Removing some unused, broken or just left over code is always a good > idea and the xlib backend is surely the place where we have the most of > this still lying around. But we must also make sure that we don't force > people to use technology that isn't available on their system. > > In this specific case you failed to explain the benefit we would be able > to gain by your clean ups that currently aren't possible.
True; but then I thought that the clean up of the Xft using code stood on its own merits, and did not need my subsequent suggestions. Anyway, the extra stuff is: The other bits of code in setupAttributes querying FC params for the pixel sized font are unnecessary (all of the bits related to traits and weight), and seem to be a consequence of a simple bug in the initial FC scan code. They can be removed when the other (one line fix) bug is dealt with. The FC enumerator is almost identical between the Xft and the cairo backends - it can be shared (not suprising giving that it looks like that bit of the cairo code was simply copied from the Xft code). I split it out in to a pair of classes: FcFontEnumerator and FcFaceInfo; then a specialisation of the FcFaceInfo for Cairo use. I have managed to make the Xft font code do more than simple pixel scaling, by using the font matrix. So more of the output with my Matrix.app test program is correct - or at least more closely matches the results seen with the cairo and art backends. See the attached xft image. > Still you are surely right that who ever is still using Xft 1 could as > well update to Xft 2 or fall back to standard xlib fonts without losing > much. (Even Riccardo is using Xft 2 and that says a lot) Well; I seriously doubt that anyone is using xft-1. > I even wouldn't mind to drop support for XGFontSetFontInfo, which is > broken anyway. What I would like to keep is the ability to not require > Xft. I hope that nobody is using XGFontInfo, but it should still be > around when somebody needs it. At least for a bit more time. I still > expect that we all be able to make the move over to a backend based on > Eric's Opal code. Which just reminds me to check out this code... I'd say leave both of XGFontSetFontInfo and XGFontInfo in the xlib code. However, I'm tempted to create an X render backend that depends on the use of the render extension. Just for the simplicity, I've been finding playing with the xlib backend to be a useful/simple was of testing behaviour. In which case I'd suggest renaming the xlib backend to xcore (or corex)... As far as I can see, said render backend could be generated by relatively simple mapping from the existing art backend code. The only bit that the render extension seems to lack is native bezier code, so it'd have to 'steal' it from some of the existing code - possibly the xlib code. This should the have the behaviour of the art backend, but with similar advantages to using the xlib backend. DF _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
