Isaiah Beerbower wrote: > On 12/10/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: >> Isaiah Beerbower wrote: >>> On 12/10/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: >>>> Isaiah Beerbower wrote: >>>>> I have an almost complete implementation working with the cairo back >>>>> end. Should I create a new branch for it under /libs/back/branches? >>>>> This is my first contribution to GNUstep, which is why I ask. >>>> The first thing you need to do is of course to assign the copyright to >>>> the FSF :-) >>>> After that you should be able to get write access to the SVN repository. >>> I've already done both. >>> >>>> Whether we need a separate branch for this change depends on the amount >>>> of code that changes and on how stable the change is in the beginning. I >>>> prefer to work on the trunk, so that people will actually test the >>>> changes I make. But this is only advisable if you are willing to correct >>>> any problems very fast. >>> Currently I have made changes in only three classes >>> (CairoFontEnumerator, CairoFaceInfo, & CairoFontInfo) and I've tested >>> it in several situations already and consider it stable. >>> >>> The reason I asked is because you said "I would prefer to see code, >>> before I judge on it". Shall I put it in trunk then? >>> >> Fine for me. > > Ok, its in trunk now.
Now I have to admit that I completely misunderstood what you were about to do. I expected that you upgrade the art backend to be able to work together with FontConfig. But what you did was downgrade the cairo backend to work without FontConfig. I should have noticed from your last mail, but I really way to busy to look into the detail. My fault. Does this mean that I will have to set the full path to my fonts to get all the fonts back that I am currently able to use with cairo? And even then all the bitmap fonts will be missing? If this is that case, I would like to ask you to add a compile time switch to go back to the old behaviour. For the xlib backend we are currently supporting three different implementations of the font management, just to keep everybody happy. GNUstep is about choice, not about forcing people to use things in the one and only way. I don't mind if there are other ways to get the a list of usable fonts beside the FontConfig way. If you want nfont support in parallel, fine. If you want to force me to use nfont only, no way. GNUstep is also about standards. We try to use the standards that are already available. FontConfig is one of them. It is used in a variety of environments, by divers applications. Why isn't it good enough for GNUstep? What you implemented looks to me like a stripped down version of FontConfig. If we need to work with font cache files, then why not on the FontConfig ones? I don't want to keep yet another cache and configuration up to date when I move on to a different release of my base system. Sorry for sounding that negative. I know it was me how said you should go ahead, but this is just not what I expected and it looks like it is making live harder for me and other users of GNUstep. Fred _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
