On 12/11/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Hi Isaiah, > > after six hours of sleep I think that my mail really sounds to negative. > Sorry for that. Would it be possible for you to rewrite your code to be > a compile time option? Lets say use a switch --enable-FontConfig with > the default being YES, if that software is installed? That way your > change wont interrupt my own development, whereas it is still easy to > switch on and test.
Sure. I'll do that as soon as possible. > On the other hand you should also have a look at the FontConfig > configuration file and see, what options you are missing there and try > to lobby the developers to integrate them. To me these solutions look > very similar. I'll take a look. > And for the art backend your code would be a big improvement. You should > think about adding it there. Again perhaps as an option. It would be fairly simple to add it to the art backend. - Isaiah Beerbower > > Fred Kiefer wrote: > > 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. > > > -- www.ipaqah.com _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
