Am 08.08.2010 21:10, schrieb Derek Fawcus: > 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.
Could you please provide this bug fix as well :-) > 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. The problem with sharing that code is that only even one of these directories will be compiled at a time. We could of course copy the file at compile time (I think we already do something like this for the font cache). > 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. Great. At the moment we aren't putting much effort in to any other backend than cairo, but if somebody contributes code to the other backends or even a new one this is fine for me. >> 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. I don't see the big advantage of such a backend over a cairo based backend that wont just use xrender but also all other available extensions of a specific system. But as I said, I wont stop you from contributing this code, as long as it doesn't break other stuff too badly. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
