On 12/11/07, Isaiah Beerbower <[EMAIL PROTECTED]> wrote: > 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.
I've reverted back to using fontconfig only for now. I can add my code as a compile time option later (when I have time). > > 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. Actually, I like this solution much better. If fontconfig cached just a few more things it would make the reason behind writing my code more or less obsolete. - Isaiah Beerbower > > 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. > > > > > 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 > -- www.ipaqah.com _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
