Am 05.08.2010 18:30, schrieb Derek Fawcus: > I've been looking at the xlib backend, specifically the Xft > text rendering support. From looking at it, I believe the > parts intended to cope with fontconfig not existing should > simply be discarded. > > It has two effects, it allow Xft version 1 to be used, > (since it preceeds the existance of fontconfig), and it > uses the Xlfd matching part of Xft. The latter seems to > be pointless (since Xft 1 supported a built in prototype > fontconfig like matching facility), broken (the way the > xlfd list passed in is built depends upon local fonts), > and a waste (since the X core text support copes with > xlfd patterns). > > It would appear that these date from quite some time ago, > Xft version 1 is obsolete (version 2 has existed since > at least sometime in 2002), and I believe anyone using > Xft now will have version 2. > > So I propose that GSXftFontInfo.m be updated such that: > > all code protected by HAVE_FC be unconditional > the code in the #else part of -setupAttributes be removed > > and similarly in XGContext.m make the code protected by HAVE_FC be > unconditional. > > 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. 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) 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... _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
